Learning paths / For AI builders

Production checklist for AI-built apps

AI-built apps keep failing in production for the same few reasons: exposed keys, open databases, missing ownership checks, no way back. These 13 checks catch them. Each one says why it matters, how to check it, and which lesson teaches it.

Printed from learn.computesphere.com/production-checklist

0 of 13 done

Your ticks are saved in this browser only.

Secrets

No API keys in the code
AI tools hard-code keys to make the first run work, and every clone, fork and agent then has them.
How to check: Search the code for key-shaped strings. Every key is read from an environment variable, and when one is missing the app locks the feature, not opens it.
Learn it: Secrets don't belong in code (lesson 4.6.1, 6 min)
None left in Git history, logs or screenshots
Deleting a key in a later commit doesn't remove it; the old commit still has it.
How to check: Search history with git log -p -S "<part of the key>" or a secret scanner. Any key that ever leaked gets rotated, not just deleted.
Learn it: How secrets leak: git, logs, images, screenshots (lesson 2.6.2, 6 min)

Data and access

Every endpoint checks who may do this
Agents build the feature and skip the ownership check, because the demo works without it.
How to check: For each route that reads or changes someone's data, try it as a different user. You should get 403 or 404, never their data.
Learn it: Authorization: who may do this? (lesson 4.6.2, 6 min)
Your database isn't open to the internet
Scanners find open database ports within minutes and try default passwords.
How to check: Only what visitors' browsers must reach has a public address. The database is private, or locked to TLS, a strong password and allowed addresses.
Learn it: Public and private: what should be reachable (lesson 1.8.2, 5 min)
Agent tokens are scoped and expire
A mistake or a leak then stops at one project and one week.
How to check: The token your agent uses covers one project, expires in days, was never pasted into a chat, and is revoked when the work is done.
Learn it: Least-privilege tokens (lesson 4.8.1, 6 min)

Code you didn't write

You read every change before it ships
A change can be tidy, tested and well described, and still be unsafe.
How to check: Each pull request is read against its brief: scope, new dependencies and how input is handled. Merge only what you understand.
Learn it: Review an agent's pull request (lesson 4.4.2, 8 min)
Your tests can fail
A test you've never seen fail might not be checking anything.
How to check: Break the code on purpose, or run the test before the fix. It fails for the reason you expect, then passes.
Learn it: Tests that prove something (lesson 4.5.1, 6 min)
User input stays data, and every package is real
Injection and invented package names both look like working code, and no test catches them unless you write one.
How to check: Queries use placeholders, never strings built from input. Look up each new dependency on its registry yourself before installing it.
Learn it: Injection, invented packages and licences (lesson 4.6.3, 6 min)

Running it

It listens where the platform sends traffic
The most common reason an app works locally and not online is one line.
How to check: The app listens on 0.0.0.0, not 127.0.0.1, and on the same port as the service's Port setting.
Learn it: Why it works locally and not online (lesson 4.2.3, 5 min)
A health endpoint that tells the truth
The platform uses it to decide when a new version is ready for traffic.
How to check: /healthz answers 503 until start-up finishes, then 200. Dependencies are reported on a separate /status, so a slow one doesn't fail the check.
Learn it: A good health endpoint (lesson 6.4.2, 7 min)

When it breaks

You know which log answers which failure
Build, deploy and runtime logs each cover one stage, and looking in the wrong one wastes the first ten minutes.
How to check: You can open your service's build, deploy and runtime logs, and you know which to read first when a deploy fails.
Learn it: Build, deploy and runtime logs (lesson 6.2.1, 6 min)
You can roll back to the last good version
A rollback lets you fix a bad release without doing it under pressure.
How to check: You know where your deploy history is and have rolled back once on purpose, from the console or the CLI.
Learn it: Deploy history and rollback (lesson 5.7.4, 6 min)
Your data has a backup you've restored
Rollback restores your service, not your data, and a standby copy repeats a bad delete within seconds.
How to check: You know who backs up each place your data lives, how often, and you've restored a backup into a separate environment.
Learn it: Backups, snapshots and standby copies (lesson 6.8.1, 7 min)

Ship it on ComputeSphere.

Secrets stored write-only, a health check before a new version gets traffic, and deploy history you can roll back from. Start a 14-day trial. A card is required at signup, and you're charged from day 15 unless you cancel.

Start your 14-day trial Take the track