Replit to production: a checklist for publishing an app real users can trust

Replit makes publishing an app almost a one-click job. That’s a real strength: one place for the editor, the AI agent, hosting and the database. But “it’s live” and “it’s ready for paying users” are different things. This is the checklist I work through before a Replit app goes in front of real customers. I run one of these in production myself: a coaching business platform built in Replit, with Supabase, Stripe and Resend.

1. Pick the right deployment type

Replit offers several ways to run a published app (Replit docs):

• Autoscale starts more machines as traffic changes. Replit recommends it for most apps.
• Reserved VM keeps a machine running all the time, which suits apps with background work or long-lived connections.
• Static serves files with no backend at all.
• Scheduled runs a job on a timer.

If your app sends emails, processes webhooks or runs anything in the background, check that the deployment type actually keeps that work running.

2. Know where your production data lives

Your published app has its own production database, separate from the one you use while building, and the Publishing pane controls how it’s created and filled when you publish (Replit docs). Before the first real user signs up:

• decide whether production starts empty or with seed data
• make sure test accounts and test orders never end up in production
• know how you’d export the data and restore it if something goes wrong

The development database can’t be reached by other apps or external database tools, while the production database can be reached with a PostgreSQL client using the connection string in its settings (Replit docs). That’s useful for backups and reporting. Treat that connection string like a password.

3. Secrets: check, don’t assume

API keys for Stripe, your email provider and AI models belong in Secrets, never in the code. Replit says secrets sync from development to your published app (Replit docs). Still, check the published app’s secrets before launch: production often needs different values (live Stripe keys instead of test keys, a production email domain), and a missing key usually only shows up when a real customer hits that feature.

4. Access rules that hold on the server

This is where AI-built apps most often break. A page that hides a button is not access control. Check that:

• every route and API endpoint that returns private data checks who is asking, on the server
• if you use Supabase, row-level security is on for every table with user data, and tested as two different users
• roles (admin, staff, member) can’t be changed from the browser

On the coaching platform, members with different roles see completely different dashboards, and the rule that one member can never reach another’s content lives in the database, not in the interface.

5. Payments that grant exactly what was bought

A checkout page isn’t a payment system. Test the whole loop on the published app:

• a successful payment gives the buyer the right access, automatically, through a webhook
• a failed or cancelled payment gives nothing
• subscriptions renew, and access ends when they’re cancelled
• you can see, in one place, any payment that didn’t produce access

That last point saves real support time. We built a sync on the coaching platform that compares every Stripe checkout with platform access and repairs anything missing.

6. Email that actually arrives

Sign-up confirmations, password resets, receipts and notifications all depend on email. Verify your sending domain with your provider (we use Resend), send yourself every email the app can send, and check none land in spam.

7. Access, security scan and domain

• Who can see it: choose Public, Password protected, Workspace only or Invite only in the Publishing pane (Replit docs). Password-protect the app while you test with real data.
• Security scan: Replit runs a security scan before publishing (Replit docs). Read what it finds; don’t just click through.
• Custom domain: connect your own domain so links, emails and search results all point to your brand.

8. Walk the real journey, end to end

Before you announce anything, go through the app as a brand-new customer would, on the published URL: sign up, verify email, buy, use what you bought, reset your password, cancel. Then do it again as an admin. Most launch-day problems show up in the first ten minutes of this.

When to get help

To see where your app stands in two minutes, run the free production readiness check.

If your Replit app works in the editor but you’re not sure about access rules, payments or data, a short audit before launch costs far less than fixing problems with real customers watching. That’s what an app rescue starts with.