Introduction
You described the app. Bolt.new built it. A few hours later you had a working prototype. Auth, a database, a UI that looked shippable. Then your first real user signed up and something broke. Maybe the login flow. Maybe a form that failed without a peep. Maybe you watched $300 in tokens evaporate trying to chase it down.
You are not the only one. Bolt.new hit $40 million in ARR within 4.5 months of launch, and Bolt v2 now bills itself as "enterprise-grade." Here is the catch. The distance between what Bolt.new ships and what production actually demands is wider than any of that marketing lets on. In our experience most Bolt.new prototypes need about 12 specific hardening steps before they belong in front of real users.
This guide walks through every gap we have run into auditing Bolt.new projects for clients. The token drain that makes debugging painful. The CSRF and input-validation holes that nearly every AI-generated app seems to share. Built a SaaS dashboard? An internal tool? A marketplace MVP? Same checklist either way. For the full cross-platform view, read our vibe coding to production pillar guide. And if you want the math on fixing versus rebuilding, our real cost of vibe coding analysis has it.
● QUICK ANSWER
Is Bolt.new production ready? No, not without hardening first. Tenzai's December 2025 study found 100% of vibe-coded apps lacked CSRF protection. In our work, a Bolt.new app usually needs around 12 specific fixes before launch.
- Security gaps: No CSRF protection at all. Missing security headers. Exposed API keys. Nothing validating input on the server.
- Token drain: Token use roughly doubles once you start debugging. One developer spent $1,000+ on a single auth fix.
- Fix cost: $8,000-$20,000 for a professional Bolt.new hardening pass, which runs 60-70% cheaper than a rebuild.
> Tenzai's December 2025 study turned up 69 vulnerabilities across 15 vibe-coded apps. Every one lacked CSRF protection. Not a single one set security headers (CSO Online). Below is the 12-point checklist that closes those gaps, how to break out of the token-drain spiral, and how to get your project onto real hosting.
Why Aren't Bolt.new Apps Production Ready by Default?
A December 2025 study by Tenzai (reported by CSO Online) audited 15 apps built by the top 5 AI coding tools and counted 69 distinct vulnerabilities. Every app lacked CSRF protection. None of them set security headers. So this is not some Bolt.new-specific bug. It is a basic gap in how AI code generators decide what matters when they spit out code.
Bolt.new optimizes for working demos. That is what the benchmark rewards. Did the prompt produce something that runs? Production hardening asks for a completely different set of priorities. Defense in depth. Failing gracefully instead of crashing. Stopping abuse. Code you can still maintain a year from now. The AI ignores all of that, because none of it shows up in the demo loop.
What Bolt.new skips by default: CSRF tokens on state-changing endpoints. Content Security Policy headers. Server-side input validation. Rate limiting on API routes. Real error boundaries. Environment variable isolation. Automated tests. A CI/CD pipeline. Structured logging. Sensible session expiration. None of it ships out of the box.
We have audited dozens of Bolt.new projects for clients by now, and three patterns turn up in almost every one. API keys hardcoded into client-side code, sitting there for anyone with DevTools to grab. Auth flows that trust a client-side role check instead of verifying on the backend. And forms that happily submit with no server-side validation beyond whatever the database schema happens to enforce.
The wider numbers back this up. Veracode's 2025 GenAI Code Security Report found 45% of AI-generated code fails standard security tests, and Java apps failed at a brutal 72%. CodeRabbit looked at 470 GitHub pull requests in December 2025 and found AI-written code produces 1.7x more issues, 75% more logic errors, and 8x more performance issues than code a human wrote.
None of this makes Bolt.new a bad tool. It builds the easy 80% fast and leaves the 20% that actually matters as the hard part. For the sister article, read our Lovable to production guide. The security issues there are almost identical, platform to platform. And our AI code audit guide has the full security checklist.
What Does Your Bolt.new App Need Before Going Live?
The 2025 Stack Overflow Developer Survey found 84% of developers now use AI coding tools, yet only 29% trust the output (Stack Overflow). That gap between using it and trusting it exists for a simple reason. Checklists like this one do not run themselves. So here are the 12 items our team works through on every Bolt.new handoff.
1. Export to GitHub first. The Bolt.new sandbox is built for iteration, not production. Pull your code out right away. Now you have version control, branches, and no token meter ticking in the background.
2. Move every secret to environment variables. Search your codebase for strings like 'sk_', 'pk_', database connection URLs, and third-party API keys. Bolt.new frequently embeds these in client-side code during development.
3. Add CSRF protection. Every state-changing endpoint needs a CSRF token. Libraries like
csrf-csrf for Node or the built-in CSRF support in Next.js middleware make this a one-hour fix.4. Set security headers. Add Content Security Policy, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers. In Next.js, this goes in
next.config.js under the headers function.5. Implement server-side input validation. Never trust the client. Use Zod, Yup, or Valibot to define schemas, then validate every incoming request on the backend. This prevents both malicious input and accidental data corruption.
6. Add rate limiting. A single script can flood an unprotected API. Use Upstash Redis, Vercel Rate Limit, or a middleware layer to cap requests per IP and per user.
7. Write proper error boundaries. A user should never hit a blank white screen or a raw stack trace. Wrap your route components in error boundaries with a fallback UI that actually helps.
8. Configure session management. Review token expiration windows. Bolt.new's defaults sometimes extend session lifetimes to avoid re-auth during development. Tighten these for production.
9. Set up monitoring. Install Sentry for error tracking. Add Axiom or Logtail for logs. Throw in basic uptime checks. You want eyes on the app before your users turn into your error-reporting team.
10. Configure database backups. If you're using Supabase, enable Pro tier backups. If you're on a self-hosted database, schedule pg_dump. Losing user data is not recoverable with an apology.
11. Set up a CI/CD pipeline. GitHub Actions works. Run tests, linting, and security scans on every commit. Deploy through a pipeline, not through a dashboard button.
12. Add structured logging. Swap every
console.log for a structured logger like Pino or Winston. Future you, debugging a production incident at 2 AM, will be grateful.Short on time? If you only do three of these before launch, make them items 1, 2, and 3. Export to GitHub, move your secrets into env vars, add CSRF protection. Across our client audits, those three alone head off roughly 70% of the incidents we see in vibe-coded apps.
How Does Bolt.new Compare to Lovable for Production Apps?
Both platforms hit big ARR milestones in 2025. Bolt.new reached $40M in 4.5 months. Lovable hit $400M with 8 million users. Both carry the same production readiness gaps too. Still, a few real differences matter once you are deciding whether to fix what you have or migrate.
Framework support. Bolt.new supports Next.js, React, Vue, Svelte, Astro, and Remix. Lovable is React plus Next.js only. If you built in Vue or Svelte on Bolt.new, you can't migrate to Lovable without a full rewrite.
Backend approach. Lovable is tightly integrated with Supabase. Bolt.new supports multiple backend options including Supabase, custom Node APIs, and edge functions. This gives Bolt.new more flexibility but also more places to mess up.
Context retention. Bolt.new's AI starts losing the thread somewhere around 15 to 20 components. Ask it to tweak a component that pulls state from 10 other files and it will often rewrite unrelated code, dragging in regressions. Lovable hits the same wall, though in our testing it holds up a little better on larger codebases.
Token economics. Bolt.new's token costs climb fast the moment you start debugging. One developer documented spending over $1,000 chasing a single authentication issue through prompt after prompt. Lovable's credit system carries the same risk, just with different failure modes.
Export flexibility. Both platforms let you export to GitHub. Bolt.new generally produces cleaner exports because it's been supporting this workflow longer. Lovable exports work but sometimes need cleanup around imports and configuration.
For production migration: the hardening steps barely change no matter which tool built the app. CSRF, input validation, rate limiting, monitoring, CI/CD. All of it applies equally. Starting a fresh project? Bolt.new's framework flexibility is a genuine edge. Fixing one you already have? The toolchain stops mattering. The checklist is what counts.
How Do You Escape Bolt.new's Token Drain and Debug Loops?
Token use on Bolt.new roughly doubles once you are in a debugging cycle. Why? When the AI cannot fix a bug, it starts regenerating bigger and bigger chunks of the codebase, hoping one of them lands. Every regeneration burns tokens and tends to plant fresh bugs in code that was working fine a minute ago. One developer reported spending over $1,000 trying to fix a single auth issue this way, prompt after prompt.
The debug loop pattern: You spot a bug. You describe it to Bolt.new. It regenerates the component. The bug is still there. Or worse, a new one pops up somewhere else entirely. You describe that one too. More regeneration. The token counter keeps climbing. Three hours later you are out $200 and the app still does not work.
How to escape the loop: Stop prompting. Export the project to GitHub. Open it in Cursor or VS Code. Then debug it the way you would any real codebase. Read the code. Set breakpoints. Inspect the state. Most auth bugs in vibe-coded apps turn out to be 10-line fixes once you can actually see what is going on.
Use Bolt.new for generation, not debugging. This is the cheapest pattern we have landed on. Let Bolt.new scaffold the new stuff. Features, pages, components, database schemas. Then pull the code out and fix the bugs in a proper IDE. The AI is genuinely good at generating happy-path code. It is genuinely bad at debugging its own mistakes.
Set hard spending limits. Both Bolt.new and the LLM APIs underneath it let you set monthly caps. Actually use them. Treat prompt tokens the way you treat cloud compute and put a real number in the budget.
Know when to switch tools. Spent more than 4 hours wrestling Bolt.new over one bug? Stop. Fix it by hand in an IDE, or bring in help. At Geminate Solutions we have seen more than one project where the debugging spend quietly passed what a professional fix would have cost from the start.
What Security Gaps Does Bolt.new Leave in Your App?
The Tenzai study tested 15 apps built by the top AI coding tools and found 69 distinct vulnerabilities. Every app lacked CSRF protection. None set security headers. Every single one shipped Server Side Request Forgery vulnerabilities. These are not edge cases. This is the default output of every mainstream vibe coding platform.
CSRF gaps. Cross-Site Request Forgery tricks a logged-in user into firing requests they never meant to send. With no CSRF tokens in place, a malicious site can post forms to your app riding on the victim's session cookie. The fix is not complicated. Add
csrf-csrf middleware or lean on Next.js's built-in CSRF support.Missing security headers. Content Security Policy shuts down XSS by limiting which scripts can run. HSTS forces HTTPS. X-Frame-Options blocks clickjacking. Bolt.new apps usually ship with none of these. Wiring them up is a 15-minute job in
next.config.js.SSRF vulnerabilities. Does your Bolt.new app fetch URLs a user supplied, say for link previews, webhooks, or third-party integrations? The naive version of that lets an attacker probe your internal network. So validate URLs against an allowlist. Block private IP ranges. Route user-provided URLs through a dedicated fetch proxy.
Client-side API key exposure. This is the worst one, mostly because it is everywhere. Your OpenAI key, Stripe key, or Supabase service-role key ends up baked into a client-side bundle. Anyone with browser DevTools pulls it out in about 30 seconds. Every production engagement we run finds at least one key sitting there exposed.
Weak password policies. Bolt.new's default auth often waves through 6-character passwords with no complexity rules at all. In production, require at least 10 characters with mixed types. And check entries against known breached password lists via the HaveIBeenPwned API.
Past the checklist, our team at Geminate Solutions runs a full audit against the OWASP Top 10 and the CWE database. A typical Bolt.new app turns up 8 to 12 distinct findings. None of them catastrophic on its own, but stacked together they are plenty to take the app down under a serious attack. Our AI integration services handle exactly this kind of hardening for AI-generated applications.
Should You Export and Self-Host Your Bolt.new App?
For most production apps, yes. The Bolt.new hosted environment is tuned for iteration, not scale. Once you have real users, the token costs plus the limited control plus the performance ceiling add up, and self-hosting becomes both cheaper and more reliable.
Vercel deployment. If your Bolt.new app runs on Next.js (most do), Vercel is the smoothest path. Push the GitHub repo, connect it in Vercel, set your environment variables, and you are live in under an hour. The free tier handles small apps fine. The $20/month Pro tier covers most production workloads.
Netlify deployment. For static or JAMstack apps, Netlify does roughly what Vercel does at slightly different pricing. Both hand you SSL automatically. Both run edge functions. Both hook straight into GitHub.
Self-hosting on DigitalOcean, AWS, or Railway. Need custom server-side logic, WebSocket support, or specific compliance requirements? A managed VPS or container host hands you full control. Budget $5 to $25 per month for a basic droplet. The tradeoff is that SSL renewal, monitoring, and deployment are now yours to handle (or to automate through a CI pipeline).
Cost comparison for 5,000 monthly active users: a Bolt.new subscription runs $20 to $50 per month, plus token costs that can spike whenever you are debugging. Vercel Pro is a flat $20 per month. DigitalOcean starts at $12 but eats DevOps time. For most production apps, Vercel wins on total cost of ownership.
The migration process usually runs 2 to 6 hours for a clean Bolt.new export. Most of that goes into getting environment variables right, swapping out hardcoded URLs, and patching any imports that did not carry over cleanly. It is not hard work. It is just tedious work.
When Should You Bring in a Professional Development Team?
Technical debt climbs 30 to 41 percent after teams adopt AI tools (InfoQ, November 2025). And that debt compounds quickly. The cheapest moment to fix a Bolt.new app is before it has users. The most expensive moment is right after a security incident.
You can probably handle it yourself if: your app has fewer than 5 database tables, serves a single user role, takes no payments, and you are comfortable reading code in an IDE. The checklist above gets you about 80% of the way there over a weekend.
You should think about bringing in help if: you handle money or sensitive user data. You have several user roles with different permission levels. You need to pass a security audit for enterprise customers. You have been fighting token drain for more than a week. Or, plainly, if your Bolt.new spend is creeping toward what a professional hardening engagement would have cost anyway.
The most cost-effective pattern is what we at Geminate Solutions call the "vibe-then-harden" workflow. Build the prototype fast with Bolt.new. Put it in front of real users and see if the idea holds. Then bring in experienced developers for the production pass. Done this way it runs 60 to 70 percent below a rebuild and still lands at the same production quality.
What a professional hardening engagement covers: a full security audit against the OWASP Top 10, input-validation hardening, CSRF and security headers wired in, rate limiting set up, monitoring configured, a CI/CD pipeline, an environment-variable cleanup, and a proper handover so you know exactly what changed and why. Typical timeline is 2 to 4 weeks for a standard Bolt.new project.
Why this work lands cleanly: shipping 50+ products globally has given our team a sharp sense of what actually breaks in vibe-coded apps. Launching 8 SaaS platforms to paying customers means we have hardened production code under real traffic, not just inside a demo. Every engagement opens with a free scoping call to work out whether your Bolt.new app needs fixing or rebuilding.
The gap between a Bolt.new prototype and a production app is real, but it is bounded. You built something worth keeping in a weekend. The right team helps you protect that without throwing it away and starting over. Our custom development team takes Bolt.new hardening engagements end to end. Need extra hands on the build? Work with our React developers on the implementation.
Next step: Book a free 30-minute Bolt.new production readiness call with our team at Geminate Solutions. We will go through your project live, flag the highest-risk security gaps, and hand you a clear hardening scope. No sales pitch. No commitment. Start here →
Frequently Asked Questions
Is Bolt.new ready for production apps?
Not without hardening first. A December 2025 Tenzai study found 69 vulnerabilities across 15 vibe-coded apps. Every one lacked CSRF protection. None set security headers (CSO Online). Bolt.new gives you a working prototype, but it skips most of the production essentials.
Why does Bolt.new cost so much during debugging?
Token use roughly doubles once you are in a debug cycle. When the AI cannot fix a bug, it regenerates bigger chunks of the codebase hoping one of them works. One developer documented spending over $1,000 on a single auth issue. The fix is simple. Export to GitHub and debug in a real IDE.
Can I export my Bolt.new app and self-host it?
Yes. Bolt.new supports GitHub export, and the generated code runs on Vercel, Netlify, Railway, or any Node-compatible host. Self-hosting drops the token limits and hands you full environment control. Most exports deploy cleanly in 2 to 6 hours.
How does Bolt.new compare to Lovable for production?
Their production readiness gaps are nearly identical. Bolt.new supports more frameworks (Next.js, React, Vue, Svelte, Astro, Remix). Lovable is React plus Supabase only. The security and architecture challenges land about the same across both.
How much does it cost to make a Bolt.new app production-ready?
A typical Bolt.new hardening engagement runs $8,000 to $20,000 depending on complexity. That is 60 to 70 percent cheaper than a rebuild, which averages $50,000 to $100,000 for a comparable SaaS app.
Does Bolt.new code pass security audits?
Not out of the box. Veracode's 2025 research found 45% of AI-generated code fails standard security tests. A Bolt.new app usually needs manual hardening before it clears an enterprise security review.
What frameworks does Bolt.new support?
Next.js, React, Vue, Svelte, Astro, and Remix. More flexible than Lovable (React plus Next.js only), though that range does cost you some consistency and a rougher debugging experience across frameworks.
How long does it take to make a Bolt.new app production-ready?
Professional hardening runs 2 to 4 weeks for a typical Bolt.new project. Complex apps with payments, multiple roles, or real-time features can stretch to 4 to 8 weeks. Doing it yourself usually takes 3 to 6 weeks, depending on your backend experience.
