A Replit app is ready for production once a developer has fixed five things: hosting, secrets, server-side authorisation, search engine rendering and security headers. In practice that means picking the right hosting (or moving off it), splitting development and production secrets and databases, checking permissions on the server, making public pages render as HTML Google can read, and adding HTTP security headers. Most apps built with Replit Agent need all five. If the code is tangled and the app has to rank on Google, rebuilding it in Next.js is often quicker than patching it.
I've written the same checklist for Bolt.new and v0, and a guide to moving a Lovable app to Next.js. This is the Replit one. The gap between "works in preview" and "customers can trust it" barely changes from tool to tool.
$2
Replit Autoscale base fee per month
15 min
Idle time before an Autoscale app sleeps
$15
Cheapest always-on Reserved VM per month
30 days
Lifetime of a free Starter plan deployment
The $2, $15 and 30-day figures are from Replit's publishing costs page. The 15-minute idle time is from Replit's Autoscale deployment docs.
What does a developer fix to take a Replit app to production?
A developer fixes six areas to take a Replit app to production: hosting, secrets, authorisation, database separation, SEO rendering and security headers. The database gets its own line because that's where the worst accidents happen. Replit Agent is very good at getting a full-stack app running fast: a React front end, a Node server and a database in one workspace. What it aims for is a working demo. Production asks harder questions. Who can see which data? What happens when the server sleeps? What does Google actually see when it loads the page?
| Area | What Replit Agent usually gives you | What a developer fixes |
|---|---|---|
| Hosting | An Autoscale deployment on a .replit.app address | The right deployment type, or a move to Vercel, Cloudflare or a VPS, plus a custom domain and monitoring |
| Secrets | Keys in the Secrets panel, often shared by preview and live | Separate production keys, nothing secret in the browser bundle, rotation of anything exposed |
| Auth | A login that works on the happy path | Permission checks on every server route, secure cookies, rate limits |
| Database | One database the Agent can change | Separate development and production data, tested backups, reviewed migrations |
| SEO | Client-side React that ships a near-empty page | Server rendering or prerendering, metadata, sitemap, canonical URLs |
| Security headers | Whatever the framework and platform send by default | CSP, HSTS, frame protection, referrer and permissions policies |
Triage it yourself first
Run your live URL through the free Security Headers Checker, open View Source to see if your headline is in the HTML, and check Search Console for indexed pages.
You can run that first check now with the free Security Headers Checker.
Should you keep your app on Replit hosting or move it?
Keep it on Replit if it's a small app or an internal tool. Move it when you need always-on performance, SEO-friendly rendering or full control of your code and data. The hosting itself is cheap. Replit's publishing costs list Autoscale at a $2 monthly base fee plus usage, shared Reserved VMs from $15 a month and dedicated ones from $35. The Replit Core plan is $20 a month, or $18 billed annually, according to Replit's pricing page.
The trade-offs show up once real traffic arrives. Autoscale apps go idle after 15 minutes without requests and wake on the next one, so the first visitor after a quiet spell sits through a cold start. Static Deployments are cheaper, but Replit's deployment docs say they don't work with Agent-built apps, which need a backend server. And a free Starter deployment expires after 30 days.
| Option | Good for | Watch out for |
|---|---|---|
| Replit Autoscale | MVPs, internal tools, low traffic | Cold starts after idle time, everything with one vendor |
| Replit Reserved VM | Always-on APIs, bots, steady traffic | Fixed monthly cost, code still edited inside Replit |
| Vercel or Cloudflare | Public sites that need SEO and edge caching, usually after a Next.js move | Code needs restructuring, limits on long-running tasks |
| VPS or container host | Long-running Node servers, websockets, background jobs | You own patching, backups and uptime |
For me, the bigger reason to move is control. In July 2025, SaaStr founder Jason Lemkin reported that Replit's Agent deleted his production database even though it had been told not to change code. Replit's CEO called it "unacceptable" (eWEEK). The lesson holds wherever you host: an AI agent shouldn't be able to reach live data in the first place.
Keep AI agents away from live data
Give the Agent a development database only. Production needs its own credentials, scheduled backups and a restore you have actually tested.
Getting the code out of Replit is easy: connect a GitHub repository from Replit's Git tool (Replit docs). Do this first on any handover, because code in a repo the client owns can run anywhere. After that, the new host is usually Vercel or Cloudflare for a Next.js front end, or a VPS for a long-running Node server. The domain and email move with it.
How do you handle secrets and authentication in a Replit app?
Split production secrets from preview secrets, keep secret keys out of the browser bundle, and check authorisation on every server route. Replit's Secrets tool encrypts sensitive values and exposes them as environment variables, which is fine. The catch is that since April 2025, deployment secrets sync with workspace secrets unless you unsync them. So preview and live often share the same Stripe key and the same database URL. Give production its own values and use test-mode keys everywhere else.
Then look at the browser bundle. In a Vite app, any variable prefixed VITE_ gets compiled into the JavaScript every visitor downloads. Before anything else, search the built files for secret keys, service-role tokens and third-party API keys. If a key has been in the bundle, treat it as public. Rotate it. Deleting it from the code doesn't undo the leak.
Logins built by Replit Agent usually work. The gap is authorisation, meaning what a logged-in user is allowed to touch. I look for:
- API routes that check you're logged in but not that the record belongs to you
- Admin pages hidden from the menu but open to anyone who types the URL
- Session cookies without HttpOnly, Secure and SameSite flags
- No rate limit on login, sign-up, password reset or any endpoint that calls a paid AI API
- Replit-specific services the app relies on, which have to be replaced before it can change hosts
My own portfolio runs an AI chat on the Claude API and Firestore. Where the key lives and who's allowed to call that endpoint are questions I've had to answer for my own product, not only for clients.
Why isn't my Replit app showing on Google?
Usually because Replit Agent built a client-side React app, so crawlers get a near-empty HTML page. When Agent generates a React or Vite front end, the deployed app is almost always a single-page app by default (Fokal). The first HTML a crawler receives is basically an empty <div id="root">, and the content only appears once JavaScript runs. Google can render JavaScript, but it's less reliable, and plenty of AI crawlers don't run it at all.
To check, right-click your page and choose View Source (not Inspect). If your headline and body text aren't in that HTML, you've found the problem. There are three fixes, from light to heavy:
- Prerender the public pages at build time. Fine if you only have a few marketing pages.
- Add server rendering to the existing Express and Vite setup. It can be done (a Replit forum thread shows one approach), but you're then maintaining a custom setup.
- Move the public site to Next.js, which renders HTML on the server out of the box, and keep the logged-in app behind it.
Move off the .replit.app address to your own domain early, and add canonical tags, a sitemap and a robots.txt. If the old address is already indexed, 301 redirect it page by page. The free AI Crawler Checker on my site tells you whether ChatGPT, Claude and Perplexity crawlers can reach you. Most of the fixes in the Lovable version of this problem carry over, and my technical SEO service covers all of it.
Which security headers does a Replit app need in production?
Six HTTP security headers cover most of the risk for a typical web app:
- Content-Security-Policy: limits where scripts, styles and frames can load from. It's your main defence against cross-site scripting.
- Strict-Transport-Security: tells browsers to use HTTPS only.
- X-Frame-Options or CSP frame-ancestors: stops other sites framing your app for clickjacking.
- X-Content-Type-Options: nosniff: stops browsers guessing file types.
- Referrer-Policy: controls how much of your URL leaks to other sites.
- Permissions-Policy: turns off camera, microphone and location unless you need them.
On an Express server, the Helmet middleware sets sensible defaults in a few lines. In Next.js you set them in the headers() function in next.config.js. Be careful with CSP. Start in report-only mode, because a strict policy can break Stripe, analytics and chat widgets without much warning. My HTTP Security Header plugin for WordPress has 1,000+ active installs. The Security Headers Checker grades your live URL from A+ to F and tells you the value to set for each header.
When should you rebuild a Replit app in Next.js instead of patching it?
Rebuild in Next.js when the public pages have to rank and convert, or when the code is too tangled to fix safely. Patch and harden it when it's mostly behind a login and the code is readable.
| Signal | Patch the Replit app | Rebuild in Next.js |
|---|---|---|
| Main purpose | Internal tool or logged-in product | Public site that must rank and convert |
| Code quality | Readable, consistent structure | Duplicated logic, huge files, dead code from abandoned prompts |
| SEO needs | None, or a few pages | Dozens of pages need to rank |
| Data model | Clear tables and relations | Schema changed by prompts with no migrations |
| Who maintains it | Founder keeps prompting | A developer or team takes over |
A rebuild rarely means starting from zero. Normally the database and business logic stay, and the front end, routing and auth get replaced. It's the same pattern as moving a Lovable app to Next.js. If you're unsure, run your project through the free Tech Stack Advisor first. If Next.js comes out as the answer, that's my Next.js and React websites service.
How much does it cost to make a Replit app production-ready?
Scope drives the cost far more than Replit does. Upwork says hiring a Next.js freelancer typically runs from $800 for small updates to $50,000 or more for enterprise builds. GoodFirms puts marketplace rates for Next.js and JavaScript developers at $15 to $35 an hour at the low end, rising to $150+ for vetted senior people. Hosting is the small line, as the Replit figures at the top show.
The biggest decision is whether you need a hardening pass or a front-end rebuild. Here's how the scope typically compares:
| Scope | Hardening pass | Front-end rebuild in Next.js |
|---|---|---|
| Areas covered | Secrets, authorisation, database separation, security headers, plus prerendering a few public pages | All of that, plus new routing, auth, server-rendered pages and metadata |
| Code kept | Almost all of it | Database and business logic; the front end is replaced |
| Typical length | A few days to a couple of weeks | Several weeks or more |
| Best for | Logged-in products with readable code | Public sites that must rank, or tangled code |
What pushes the price up:
- User roles. Admins, teams and customers each need their own checks.
- Payments. Stripe webhooks, refunds and failed payments all need proper testing.
- Data. Moving live records is slow, careful work, more so if the schema drifted.
- Public pages. Every page that has to rank needs server rendering and metadata.
- Tests. Apps built by Replit Agent rarely have any.
A hardening pass takes a fraction of the time a rebuild does, so get that decision right before anyone writes code.
What should you ask a developer before handing over a Replit app?
Ask about code ownership, environments, permissions, SEO, security headers and whether they'd patch or rebuild. Here's how I'd phrase each one.
- 1
Who owns the code?
Ask them to move it into a GitHub repository in your name before any work starts.
- 2
How will you split dev and production?
You want separate databases, separate keys and a backup you have seen restored.
- 3
Which routes will you test for permissions?
A good answer names the API routes and admin pages, not just the login screen.
- 4
What will Google see on first load?
Ask for View Source proof that public pages ship real HTML after the work.
- 5
What header grade will we launch with?
Agree a target, such as an A on the Security Headers Checker, and a plan for CSP.
- 6
Patch or rebuild, and why?
They should explain the call in terms of your goals, not their favourite stack.
Send me your live Replit URL and two lines on what the app does. I'll tell you whether it needs a hardening pass or a rebuild, and what that would involve. Book a 20-minute call or get in touch.
