To take a Bolt.new app to production, a developer usually fixes six things: database rules and auth, exposed secrets, server rendering for SEO, hosting setup, error handling and monitoring, and who owns the code and accounts. Most Bolt.new apps don't need a rebuild. They need the parts the AI skipped, so the demo doesn't fall over once it's public. Published market prices run from about $299 for one fix to $1,500 to $5,000 for a full audit and cleanup.
Is a Bolt.new app ready for production as it is?
Usually not. Bolt is built to get you a working app fast. It often scaffolds a Vite + React + TypeScript app, wires in a database and publishes in one click. That's great for a demo. But "it works when I click through it" is a different test from "it holds up when strangers, bots and search engines hit it".
Bolt now has its own security audit, and you should run it. Just know that its database Security Audit page only checks the database, and either way it's the tool marking its own homework.
The wider numbers aren't reassuring. Veracode's spring 2026 update found AI models wrote code with a known security flaw in 45% of its test tasks. And when AxonBuild audited 21 AI-built apps, as summarized by Inferya, this is what it found:
18 of 21
Apps with no working automated test
17 of 21
Apps with at least one critical finding
17 of 21
Apps that recorded errors nowhere
What does a developer actually fix in a Bolt.new app?
Six areas: auth and database rules, secrets, SSR and SEO, hosting, error handling and code ownership. This is the list I'd work through before real users or payments touch an AI-built app. The table is the short version. Each section after it goes into one row.
| Area | What's usually wrong | What the fix looks like |
|---|---|---|
| Auth and database rules | Tables without row-level security, or policies that allow everyone | Turn RLS on for every table, write per-user policies, test as a logged-out and a wrong user |
| Secrets | Third-party API keys sitting in frontend code | Move calls to a server function or edge function, rotate the leaked keys |
| SSR and SEO | Client-rendered pages that ship an empty HTML shell | Prerender public pages or move them to a server-rendered framework like Next.js |
| Hosting | One-click publish with no staging, headers or redirects | Separate staging and production, security headers, custom domain, SPA routing rules |
| Error handling | Blank screens, no logging, every change goes straight live | Error boundaries, server-side logging, uptime alerts, a basic test suite |
| Code ownership | Repo, database and domain sit in the builder's or a freelancer's account | GitHub repo, database and domain moved into accounts the business owns |
How do you lock down auth and database rules in a Bolt.new app?
Switch on row-level security for every table, tie each policy to the logged-in user, and run admin-only actions on the server. Start here, because this is where user data leaks.
Most Bolt apps use Supabase or Bolt's own database, and both work the same way: the browser talks to the database directly using a public key. That key is meant to be public, but only if row-level security is set up on every table. Without it, anyone who opens dev tools can read or edit rows that aren't theirs.
I'd go table by table and ask three questions. Is RLS on? Do the policies tie rows to the logged-in user, not just "any authenticated user"? Do admin-only actions run on the server? Watch for policies that are always true: they exist on paper but let everyone in.
Then test it yourself. Log in as user A, copy a request for user B's data from the network tab and replay it. If it returns data, your rules are broken, whatever the scanner says.
Then auth itself. Password reset links and OAuth redirects should point at the live domain, not the preview URL. Leaked password protection should be on. Bolt's docs say that setting is on by default for Bolt databases but isn't available on a free Supabase plan.
Are your Bolt.new app's API keys and secrets exposed?
Often, yes. Ask an AI builder to add OpenAI, Stripe or an email service and it may put the key straight into frontend code, where anyone can read it. In a Vite app, any environment variable starting with VITE_ gets bundled into the JavaScript the browser downloads. Putting it in a .env file doesn't hide it.
The fix is to move every secret call behind a server: a Supabase or Bolt edge function, a serverless function on your host, or an API route in Next.js. Then rotate every key that was ever in the bundle, because old builds and caches can still hold it. The chat on my own AI portfolio runs on the Claude API, and that's exactly the kind of key that has to live on the server. Never in the browser.
Why doesn't my Bolt.new app show up on Google?
Because the default Vite + React setup renders in the browser. The first HTML a crawler gets is an empty div and a script tag. Google can run JavaScript, but it does it in a later rendering step, and Vercel's study of AI crawlers found many of them don't run it at all. So your landing and pricing pages may be invisible to them.
The fixes, lightest first:
- Keep the app as it is, but prerender the public marketing pages at build time with proper titles, meta descriptions and Open Graph tags.
- Split the site: a server-rendered marketing site on its own, with the Bolt app behind login on a subdomain.
- Move the whole thing to a server-rendered framework. I've covered that route for Lovable in a separate post on Lovable to Next.js migration, and the same logic applies to Bolt.
If you're already live and missing from search, my post on Lovable app not showing on Google walks through the same diagnosis. Different builder, same problem. Also check your robots.txt with my free AI Crawler Checker. It tells you whether 14 AI crawlers may fetch your home page and whether you have an llms.txt.
Where should a Bolt.new app be hosted?
It can stay on Bolt Cloud, move to Netlify as a static Vite build, or go to Vercel or Cloudflare once it's on Next.js. It comes down to how much control you need. Bolt Cloud keeps hosting and the database in one place, and for plenty of apps that's enough.
| Hosting option | Good for | Watch out for |
|---|---|---|
| Bolt Cloud | Staying in the builder, quick changes by prompt | Less control over headers, staging and build steps; tied to Bolt |
| Netlify | Static Vite builds exported from Bolt | SPA redirect rules, env vars set per environment |
| Vercel or Cloudflare | Next.js after a move to server rendering | Server function limits and pricing at scale |
| Your own server or container | Apps with a custom backend or data rules | You own patching, backups and uptime |
Whichever you pick, production needs a staging copy, separate environment variables, security headers and HTTPS on a custom domain. If you're choosing between Next.js hosts, I've compared Vercel vs Cloudflare in a separate post.
Then run your live URL through my free Security Headers Checker. It grades the page from A+ to F and gives you the value to set for Content-Security-Policy, HSTS and the rest. This is an area I know well: my HTTP Security Header plugin for WordPress has 1,000+ active installs.
What happens when a Bolt.new app breaks in production?
In most AI-built apps, nothing tells you. The user sees a blank screen and leaves, and you never hear about it. The fix is error handling, logging and alerts, so you find out before your users do. In practice that means:
- React error boundaries, so one broken component doesn't blank the whole page
- Logging on server functions and the frontend
- Uptime checks and alerts on the pages that make money
- A few automated tests on sign-up, login and payment
- A staging step before production for every change
If you hit an error you don't understand, my free Error Message Explainer reads the stack trace and suggests the likely cause.
Do you own your Bolt.new code?
You should, but check. The code, database, domain and accounts often end up in the builder's account or a freelancer's. Make sure the business, not a person, owns each of these:
- The GitHub repository, synced or exported from Bolt
- The database project (Bolt Cloud or your own Supabase organization) and its backups
- The domain registrar and DNS
- Stripe, email, analytics and every third-party API account
- The environment variables, written down somewhere safe
A GitHub repo you control turns a Bolt project into something any developer can pick up. It also stops you paying in tokens for every small change. Bolt's plans start at $25 a month for 10M tokens on Pro, and a long debugging loop by prompt can burn through that quickly.
How much does it cost to take a Bolt.new app to production?
Published market prices run from $299 for a single fix to $1,500 to $5,000 for a typical audit plus remediation. Full rebuilds are quoted at $20,000 to $60,000. These figures come from people who sell this work, so treat them as asking prices.
| Type of work | Published price (USD) | Source |
|---|---|---|
| Single quick fix on Upwork | From $299 | vibecoding.app |
| Config and deploy issues (env vars, CORS, OAuth redirects) | Usually under $600 | KodingKlouds |
| Isolated bugs, such as one RLS policy or a webhook | $600 to $1,500 | KodingKlouds |
| Security audit | $500 to $3,000 | vibecoding.app |
| Architecture refactoring | $2,000 to $8,000 | vibecoding.app |
| Full rebuild | $20,000 to $60,000 | InApps Technology, via Inferya |
| Ongoing maintenance | $500 to $2,000 a month | vibecoding.app |
vibecoding.app puts most indie projects at $1,500 to $5,000 for a full audit plus remediation. What pushes a job up the range: real user data already in the system, payments and auth logic, no access to the original accounts, and an app that can't go offline while it's being fixed.
Should you fix the Bolt.new app or rebuild it in Next.js?
Fix it in place unless search traffic is part of the plan or nobody can change the code safely. In those two cases, move to Next.js. Fixing in place is the right call when the data model fits the product, most of the app sits behind a login and SEO doesn't matter much.
A move to Next.js doesn't have to happen all at once. The public pages can go first while the app stays where it is. That's the kind of work I do through my Next.js and React websites service. For a bigger product, with a mobile app or internal tools, it fits my web and mobile apps service, where my team builds with me and I stay your single point of contact.
Can you run a quick audit of a Bolt.new app yourself first?
Yes. Five checks, about twenty minutes, and you'll have a fair idea how big the job is.
- 1
Run Bolt's own audit
Run the security audit described in Bolt's support docs, then open the database Security Audit page. Note anything it couldn't fix.
- 2
Search the bundle for keys
Open your live site, view the JS files in dev tools and search for sk_, api_key and secret. Anything you find needs moving and rotating.
- 3
Check your headers
Paste your live URL into the Security Headers Checker and note the grade and missing headers.
- 4
Check what crawlers see
Run the AI Crawler Checker, then view the page source. If the body is an empty div, search engines see very little.
- 5
List your accounts
Write down who owns the repo, database, domain and payment accounts. Anything in someone else's name goes first on the fix list.
What should you ask a developer before hiring them to fix a Bolt.new app?
These five questions cover most of it:
- Will you test the database rules as a logged-out user and as a different user?
- Which secrets will you move to the server, and will you rotate them?
- Where will I see errors after launch?
- Will the repo, database and domain sit in my accounts when you're done?
- Is your quote fixed after an audit, or open-ended?
If your Bolt app works but you're nervous about putting real users on it, book a 20-minute call and tell me what it does and where it's hosted. I'll tell you which of these fixes it actually needs, and which it doesn't. Or send the details through the contact page.
