Is your Bolt.new app secure, and who really owns it?

Bolt is an AI builder for websites, web apps and mobile apps, made by StackBlitz, Inc. of San Francisco. Its help centre says it’s for everyone, whether or not you’ve ever written a line of code.

By default, a Bolt app runs on Bolt Cloud, with hosting, domains and a Bolt database all in one place. If you’re on a Pro or Teams plan, you can use your own Supabase project instead. We aren’t connected with Bolt, and everything below comes from its public help centre and terms, as we read them on 6 November 2026.

What Bolt says is your job

Bolt provides a good deal. It turns on row-level security for the tables it creates, offers a database security check on all plans and a full project security audit on paid plans, and keeps secrets out of your code and the browser. Its terms still put the responsibility with you:

Its help pages also contain a sentence every owner should read: “If you haven’t asked Bolt to add sign-in to your site, Bolt might write policies that allow any visitor to view, add, change, and delete the data in your database.” So having security rules isn’t the same as having the right ones. Here’s why that matters.

Who holds the keys

This is the bigger concern for a business, and it depends heavily on the plan you’re on.

• On a personal plan, there’s one owner. Bolt says the Co-owner role only appears when everyone you’re inviting is a member of your team, so a personal plan offers only Viewer and Editor.
• Some things only the owner can do. On an individual account, only the project owner can manage secrets and advanced database settings, connect GitHub, or connect outside tools.
• The code backup can stall. When a collaborator makes changes, they sync to GitHub “the next time the project owner opens the project”. If the owner has gone, your backup may be quietly falling behind.
• Sharing the password isn’t a good plan. Bolt’s terms require each person to use a separate account, and they prohibit credential sharing to get around limits.
• We found no documented route for an owner who has gone, nor a way to transfer ownership of a team. Paid support is by email from the address on the paid account, which is no help if that mailbox has gone too.
• Deleting a team deletes its projects, permanently, for everyone in it.

The sensible step for a business is a team workspace in the company’s name, with more than one admin. How to work out who owns what.

Handing a project over

You can transfer a project, but read this first:

• The old owner loses all access once the new owner accepts.
• Bolt removes the GitHub link, so the new owner has to connect their own.
• Your Supabase settings move with the project, but the Supabase account doesn’t.
• If you bought your domain through Bolt, you can’t reconnect it until it expires. Bolt advises against transferring a project with a Bolt-purchased domain, so that’s worth checking early on.

Transferring to a workspace is gentler, as integrations stay connected.

Getting your things out

Bolt says the code you create is yours, and you can download it as a zip or sync it to GitHub. Data is a different matter:

• Rolling back doesn’t restore data. Bolt says that restoring an earlier version “will not change your current Bolt or Supabase databases”. Version history covers your code.
• We found no documented full backup of a Bolt database. You can export selected rows as CSV or JSON, and on Pro and Teams plans you can claim a database into your own Supabase organisation. If your data matters, ask Bolt how it’s backed up, and don’t assume.
• Your terms have a say. They make you responsible for your own independent backups.

What has gone wrong publicly

As of November 2026 we found no major reported breach of the Bolt platform itself, though our search was limited, and that isn’t proof there hasn’t been one. The risk that has been discussed lies in individual apps, usually tables without proper rules. You’ll see percentages quoted for this, mostly from firms selling scanners, and they don’t agree with each other, so we wouldn’t rely on them. Bolt’s own sentence above tells you what you need to know.

What you can check today

These are the menu names in Bolt’s help centre, which can change.

1. Is it a personal account or a team?

   Click your account name, top left. If it’s personal, one person holds the keys.

2. Whose login is it?

   Bolt accounts live at StackBlitz. On stackblitz.com, see Settings, Credentials and Settings, Profile, Emails. Is it a personal Gmail, and does someone in the business still control it?

3. Who’s on the project?

   The Share button, top right. Who has which role? If it says anyone with the link can view or edit, click Turn off.

4. Run the database check

   Database icon, then Security. Look in particular for “RLS Policy Always True”. If your app holds private data and has no login, that deserves attention.

5. Run the full audit, on a paid plan

   Publish, then Run security audit. Look for anything marked “Needs your action”.

6. Is the site public?

   The Publish menu. The default is public, and search engines list public sites.

7. Is your code really backed up?

   The GitHub icon. Is it connected, to whose account, and do you see “Your changes won’t sync”? Then use Download on the project title, and keep the zip safe.

8. Where did the domain come from?

   Check the project’s Domains & Hosting settings. If it was bought through Bolt, that affects any handover.

How we can help

Our audit checks whether your rules really do what your business needs, tests that from outside the app, and maps every login and service your Bolt project relies on. See an example report.

Questions

By Selwyn Doling, VibeTend. Last updated 6 November 2026.