Hardening a Replit AI MVP for Production

A developer outlines production-hardening steps for Replit AI apps, including persistent instructions via a replit.md file, environment variable management, authentication and authorization checks, and rate limiting for uploads and AI usage. The guide emphasizes separating environments and testing security boundaries before deployment.

A vibe-coded Replit app can survive a demo. Production asks different questions. What happens when two users hit the same endpoint? Can one user read another user's records? Are Stripe live keys separated from test keys? What stops an LLM call from looping until the bill hurts? Before you share the link outside your team, harden the app around a few boring files and rules. Boring is good here. replit.md Replit's agent needs persistent instructions. Without them, each prompt session can drift from earlier decisions. Create a replit.md file and treat it like a small production contract. Production rules Security - Every API endpoint must check authentication. - Every user-owned resource must check authorization. - Never expose secrets in client-side code. - Do not create public endpoints unless explicitly requested. Database - Use migrations for schema changes. - Do not modify production data directly. - Keep dev, staging, and production databases separate. Input validation - Validate request body fields. - Set file size limits on uploads. - Reject unsupported file types. External services - Add rate limits for paid APIs. - Add spending caps where the provider supports them. - Log failed webhook events. Code changes - Do not rewrite unrelated functions while fixing a bug. - Change only the affected files unless asked. This does not repair weak code already generated. It does reduce new damage. A Replit prototype often depends on things you forgot were Replit-specific: secrets, URLs, storage, process behavior, or a bundled database. Start with a basic search. grep -R "replit" . grep -R "localhost" . grep -R "process.env" ./src grep -R "sqlite" . grep -R "uploads" . Then check your runtime setup. js const port = process.env.PORT || 3000; app.listen port, "0.0.0.0", = { console.log Server running on port ${port} ; } ; If the app only runs inside the Replit workspace, it is still a prototype. Do not migrate until you can describe every required variable. DATABASE URL= SESSION SECRET= STRIPE SECRET KEY= STRIPE WEBHOOK SECRET= OPENAI API KEY= SENTRY DSN= APP ENV=development Commit the example file. touch .env.example git add .env.example git commit -m "Document required environment variables" Never commit the real .env . .env .env.local .env.production Ouch if this is missing. Fix it early. AI-built apps often make login look finished while leaving the API too trusting. The UI is not the security boundary. js app.get "/api/invoices/:id", async req, res = { const session = await getSession req ; const invoice = await getInvoice req.params.id ; if session { return res.status 401 .json { error: "Unauthorized" } ; } if invoice.userId == session.user.id { return res.status 403 .json { error: "Forbidden" } ; } return res.json invoice ; } ; Then test the bad path. curl -H "Authorization: Bearer USER A TOKEN" \ https://example.com/api/invoices/USER B INVOICE ID Expected result: 403 Forbidden If you get invoice data back, stop adding features. Your app needs limits around uploads, paid APIs, and LLM calls. Example upload guard: js const MAX FILE SIZE = 10 1024 1024; // 10 MB if file.size MAX FILE SIZE { return res.status 413 .json { error: "File exceeds 10 MB limit", } ; } Example AI usage guard: if user.monthlyTokensUsed = user.monthlyTokenLimit { return res.status 429 .json { error: "Monthly AI usage limit reached", } ; } Example route-level rate limit: python import rateLimit from "express-rate-limit"; export const apiLimiter = rateLimit { windowMs: 60 1000, limit: 60, } ; Attach it before the expensive route. app.post "/api/generate", apiLimiter, generateHandler ; Small guardrails save large invoices. Use three separate environments, even if the app is small. php local - local database staging - staging database production - production database A minimal CI workflow is enough to start. name: ci on: pull request: push: branches: main jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm run lint - run: npm test Add smoke tests for login, checkout, upload, and any AI flow that costs money. You can keep hardening the app yourself while the risk is low. Bring in engineering help when one bad prompt could expose user data, trigger live payments, corrupt production data, or break a workflow customers depend on. MEV is one vendor option for that stage. Their Vibe-Code to Production work is built around auditing Replit, Lovable, and AI-built MVPs, then hardening auth, secrets, AI integrations, observability, infrastructure, and deployment without forcing an automatic rewrite. Useful fit: Before sharing the production URL, confirm this: replit.md has production rules .env.example existsA Replit MVP is a strong starting point. Production needs stricter rules, fewer hidden assumptions, and a path back when something breaks. Full original guide: https://mev.com/blog/how-to-get-a-vibe-coded-replit-app-production-ready https://mev.com/blog/how-to-get-a-vibe-coded-replit-app-production-ready MEV production-hardening service: https://mev.com/services/vibe-code-to-production https://mev.com/services/vibe-code-to-production