Production Readiness

Is your app ready to ship?

AI coding tools are incredible at getting you to 90%. The last 10% - secrets management, database access controls, rate limiting, backups - is where real apps fail in production. This checklist covers the 15 things AI tools consistently get wrong, with specific fixes for each one. Works regardless of where you host.

0 of 15 reviewed
Get started below
Who acts: your code / config verify with your host
01 / 05

Secrets & Credentials

No secrets committed to git history
your code / config
AI tools frequently suggest hardcoding API keys and credentials directly in config files. Run git log -p | grep -iE "api_key|password|secret|token" before pushing. If you find one, rotate it immediately - deleting from git history alone is not enough if it was ever pushed.
Tools: trufflehog git-secrets (pre-commit hook) gitleaks
Real example: Moltbook (Feb 2026) - 1.5M API keys exposed. Built entirely with AI tools. Dev-mode credentials were baked directly into the app config and committed.
No API keys or tokens in client-side code
your code / config
Any key that ships in your JavaScript bundle is public - anyone with browser DevTools can find it. AI tools often put service API keys directly in frontend components. All third-party API calls that use secrets must go through your backend. Your server holds the key; your client never sees it.
Environment variables loaded from a secrets manager, not a .env file
your code / config
.env files work fine locally. In production, they get accidentally committed, accidentally copied into containers, and accidentally logged. Move secrets to a proper store before you go live.
Options: Doppler (free tier) Infisical (open-source) HashiCorp Vault Railway / Render / Fly.io built-in secrets
02 / 05

Database Access

Row-level security enabled (if you use Supabase or Postgres RLS)
your code / config
Supabase creates every table with RLS disabled. Without it, any authenticated user can read every other user's data. Takes 10 minutes to fix: enable RLS on each table, then write policies for SELECT, INSERT, UPDATE, and DELETE. Run SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname='public'; to check your current state.
Data: 48% of Lovable-built apps audited in April 2026 had this issue - Supabase anon key with read access to entire tables (vibeaudit.net, April 2026).
Database is not accessible from the public internet
verify with your host
Your database should only accept connections from your app containers, not from the internet. Most managed hosts put databases on a private network by default - but verify this. If you manage a VPS yourself, block external access: ufw deny from any to any port 5432 and only allow your app server's private IP.
Self-hosted: ufw (Ubuntu) iptables PostgreSQL listen_addresses = 'localhost'
Database credentials are not defaults
your code / config
AI scaffolding tools often generate user: postgres, password: postgres. Change these before going live. Generate a strong password with openssl rand -base64 32, update your database user, update your connection string, and restart your app.
03 / 05

Network Security

WAF protection against injection attacks
verify with your host
A web application firewall blocks SQL injection, XSS, path traversal, and other OWASP top 10 attacks at the network edge - before requests reach your code. This is the most important layer of defense against common automated attacks. Check whether your hosting provider includes WAF protection, or put Cloudflare in front of your app.
Options: Cloudflare WAF (free tier) AWS WAF Coraza (self-hosted) ModSecurity
Rate limiting on auth and API endpoints
your code / config
Without rate limiting, your login endpoint is open to brute-force attacks and credential stuffing. Your registration endpoint is open to spam. Add limits to any endpoint that authenticates users, accepts user-generated content, or calls paid third-party APIs.
Options: rack-attack (Rails) express-rate-limit (Node) DRF throttling (Django) Upstash Redis Cloudflare rate rules
URL fetching validates against an allowlist (SSRF prevention)
your code / config
If your app fetches URLs from user input (link previews, webhooks, image imports), AI-generated code almost never validates the destination. An attacker can make your server fetch internal services or cloud metadata endpoints. Fix: allowlist permitted domains, and explicitly block internal IP ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x).
Research: A study testing 5 AI coding tools (Claude Code, Codex, Cursor, Replit, Devin) found every single one introduced SSRF in URL preview features - 5/5, 100% (Tenzai security study, 2026).
04 / 05

Infrastructure Basics

Automated backups with a tested restore
verify with your host
Read your host's docs and confirm what actually gets backed up, how often, and how long backups are retained. Then test a restore before you have real user data. If you manage your own Postgres: set up pg_dump to a separate storage location (S3, Backblaze B2) on a daily cron. A backup you've never tested is not a backup.
Self-hosted: pg_dump + cron + S3 Litestream (SQLite) Barman (Postgres)
Container image scanned for vulnerabilities
your code / config
AI-generated Dockerfiles often use outdated base images with known CVEs. Add a scanner to your CI pipeline - it takes about 5 minutes with GitHub Actions. Run it on every PR before you push to production. Some hosts also scan images on deployment - check yours.
Free options: Trivy (GitHub Actions) Grype Snyk container Docker Scout
App restarts automatically on crash
verify with your host
Without automatic restart, a single uncaught exception means downtime until someone notices. Most PaaS platforms handle this by default. If you deploy with Docker directly: add restart: unless-stopped to your compose file. On a raw VPS: use systemd with Restart=always to manage the process.
Self-hosted: Docker restart policy systemd Restart=always PM2 (Node.js)
05 / 05

Observability & Compliance

Application error tracking in place
your code / config
You need to know when production errors happen before your users report them. Your hosting provider's infrastructure logs catch crashes - they don't catch application exceptions, failed payments, or silently broken features. Add error tracking directly to your app. Sentry's free tier covers most small projects and takes about 15 minutes to integrate.
Options: Sentry (free tier) Honeybadger Rollbar Datadog APM
External uptime monitoring active
verify with your host
Internal health checks can't detect network-level outages or failures that only appear from outside your infrastructure. You want an external probe hitting your app every few minutes and alerting you when it stops responding - before a user posts about it. This takes about 2 minutes to set up and most tools have a free tier.
Free options: UptimeRobot (5-min checks free) Better Uptime Freshping Grafana Cloud (free tier)
Data residency understood for your users' jurisdiction
your code / config
Know where your data actually lives. Check your host's data center locations. Then check your third-party services too - email providers, payment processors, and analytics tools all store data somewhere. GDPR (EU), PIPEDA (Canada), and HIPAA (US healthcare) have different requirements. This one bites teams post-launch when a customer's legal team asks.
On "verify with your host" items

For infrastructure items, the question to ask your provider is: "Do you handle X by default, or do I configure it myself?" Different hosts give different answers. Railway includes restart-on-crash but no WAF. Cloudflare protects you at the network edge but doesn't know about your app. A full-stack managed host handles the infrastructure layer end-to-end. Whatever you're on - know what's covered and what you still own.

One option for the infrastructure items

Some hosts handle the infrastructure layer for you

If you'd rather not configure WAF rules, set up backup cron jobs, or choose between twelve monitoring tools - a full-stack managed host handles those by default. vmfarms runs on dedicated hardware with WAF, rate limiting, container scanning, uptime monitoring, intrusion detection, and automated backups included for every app we host.

Ask us what we cover
Coraza WAF CrowdSec Trivy scanning Wazuh SIEM Uptime Kuma Infisical secrets Automated backups Canadian data residency