Shipping an AI-built app to production: the checklist nobody gives you
AI coding tools got you a working app in a weekend. The gap between 'it runs on my machine' and 'strangers can rely on it' is entirely operational — and it is short if you work through it in order.
Published 2026-08-14 · 10 min read
1. Get secrets out of the repository
AI-generated projects routinely inline API keys in client code. Anything shipped to the browser is public, permanently.
Move every credential to server-side environment variables, rotate any key that has ever been committed, and confirm your git history does not contain the old value.
2. Decide where state lives
- Database: a managed Postgres or a container with a mounted volume — never SQLite on a container filesystem you redeploy.
- File uploads: object storage or a mounted volume, not the app directory.
- Sessions: a stable secret, or every deploy logs your users out.
3. Containerise it
A Dockerfile makes the app reproducible and rollback-able. If you do not have one, generate it — the important parts are a pinned base image, a multi-stage build, a non-root user and a health endpoint.
# the endpoint that makes safe deploys possible
GET /healthz -> 200 only when the app can serve real traffic4. Put it on hardware you control
For most AI-built apps, an Oracle Always Free ARM instance is more than enough: 2-4 OCPUs, up to 24 GB RAM, 10 TB egress, $0 forever. Cheaploy connects your GitHub repo, builds on the instance and swaps traffic only after the health check passes.
5. Domain and HTTPS
Point an A record at the instance. Caddy issues and renews certificates automatically, so HTTPS is not a task you revisit. Set your canonical domain (www or apex, not both) before you start collecting links.
6. Backups you have actually restored
A backup you have never restored is a hypothesis. Schedule nightly dumps to object storage, then do one real restore into a scratch database and time it. That number is your recovery time objective.
7. Know when it breaks before your users tell you
- Uptime checks on the public URL, from outside the VM.
- Error tracking with alerts, not just logs you never open.
- CPU, memory and disk alerts — a full disk is the single most common self-hosting outage.
- Cost anomaly alerts if you ever upgrade beyond the free allowance.
8. A rollback plan
Being able to return to the previous container in seconds converts a bad deploy from an outage into a shrug. Health-check gated blue/green deploys with automatic rollback are built into Cheaploy for exactly this reason.
Keep reading
Get the Oracle Always Free deploy checklist
One email with the exact steps, capacity workarounds and tools we use to ship apps for $0 of cloud spend.
One email, no spam. Unsubscribe anytime.
Frequently asked
Do I need to know Docker or Linux?+
Not to use Cheaploy. It helps for debugging, but the deploy path does not require a terminal.
How long does the first deploy take?+
Usually under 20 minutes end to end, with most of it spent on the Oracle account signup.
What if I built it entirely with AI and cannot read the code?+
Start with the non-technical founders guide, which walks through the same checklist without assuming engineering background.
Deploy your project for $0
No credit card. No Oracle sales call. Ship to your own cloud in under 10 minutes.
Start free