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.
## 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.
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.
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:
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:
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.
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
MEV production-hardening service: https://mev.com/services/vibe-code-to-production