A production checklist for apps built with AI, with a test for each item.

This is the most common hole in generated code. Anything the browser downloads is public. Next.js inlines every NEXT_PUBLIC_ variable into the JavaScript it sends to the browser at build time, and Vite does the same with VITE_ variables; Vite’s docs say they “should not contain sensitive information such as API keys.” A Stripe secret key, an OpenAI key or a Supabase secret (service_role) key under one of those prefixes is a key anyone can copy.

Verify: build locally and search the output, then search the history. Any hit means move the call to a server route and rotate the key, because deleting the line does not un-publish it.

# Build the way production does, then search what ships to the browser
npm run build
grep -rEo "sk_live_[A-Za-z0-9]{8,}|sk-[A-Za-z0-9_-]{20,}|service_role|SECRET" \
  .next/static dist build 2>/dev/null | sort -u

# And the history: a key committed once is a key to rotate
git log -p | grep -nE "sk_live_|sk-[A-Za-z0-9_-]{20,}|service_role" | head

Generated apps often protect the page and forget the API behind it. The page hides the button; the endpoint still answers anyone who calls it. Each route that reads or writes user data has to look up the signed-in user and filter by it on the server.

Verify with two accounts. Sign in as B, open one of A’s records by changing the ID in the URL or the request, and try to edit it. You should get a 403 or 404. Then call the same API with no cookie at all: curl -i https://yourapp.ca/api/orders/123 should return 401.

Apps exported from Lovable or Bolt usually talk to Supabase straight from the browser, so the database policies are the only check. Supabase’s guide says to enable row-level security on every table in an exposed schema and never to use a secret key in the browser. Run this in its SQL editor:

-- Every table in an exposed schema should say true
select relname, relrowsecurity
from pg_class
where relnamespace = 'public'::regnamespace and relkind = 'r'
order by relrowsecurity, relname;

• No `.env` in git. git ls-files | grep -E '(^|/)\.env' should print nothing except an example file.
• Fail at boot, not at the first request. Read required variables when the app starts and exit with their names if one is missing. A crash on deploy is cheaper than a broken checkout at 2 a.m.
• Production values are not test values. Live payment keys, the production database, the real email sender.
• Previews don’t touch production data. On Canner, pull-request previews share the project’s database. If the project holds live credentials, turn previews off and keep a separate staging project with sandbox keys (how).

A stack trace on screen tells an attacker your file paths, library versions and sometimes your SQL. Visitors should get a plain error page; you should get the whole stack.

Verify: hit a route with a bad ID or force a throw, and read the response body. It should not contain a stack. Django needs DEBUG = False; Node frameworks need NODE_ENV=production, which Canner sets for you. Then find that same error in your logs.

On Canner, Logs groups errors from Node, Python, Ruby, PHP, Go, Java and Rust, counts them per deploy and links each to the commit it started in. A Next.js “Application error … Digest” can be pasted into the search box to find the real error (logs and errors docs).

A backup you have never restored is a guess. Turn on scheduled backups, then restore one and look at it.

On Canner, a backup policy on the Database tab runs daily on Starter and as often as hourly on paid plans. Restore with Inspect first: the backup lands in a temporary database you can query and compare with live, without touching production. Canner also restores your newest backup overnight to test it and marks it Verified. See Postgres on Canner and the database docs.

Backups contain data, not configuration. Export your environment variables (canner env --reveal --json) into a password manager, never next to the backup. Without the key that encrypted something inside your data, a restore can’t read it.

Adding the domain is the easy part: two DNS records, and Canner issues the HTTPS certificate and renews it (custom domains). What breaks is everything that still points at the old preview URL.

• OAuth redirect URIs at Google, GitHub or Microsoft.
• The site URL and redirect allow-list in your auth provider.
• Stripe and other webhook endpoints.
• CORS allow-lists and any APP_URL or NEXTAUTH_URL variable.

Login, sign-up, password reset, contact forms and any route that calls a paid AI API. Without a limit, the first is a password-guessing target and the last is a bill.

A Canner project runs one process, so an in-memory limiter sees all of the project’s traffic. It resets on every deploy and wake, which is fine for login throttling. For limits that must survive a restart, such as a daily AI quota per user, count in Postgres; Canner does not run Redis.

Verify:

# 30 bad logins in a row: the last ones should be 429, not 401
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code} " -X POST https://yourapp.ca/api/login \
    -H 'content-type: application/json' -d '{"email":"a@b.c","password":"x"}'
done; echo

You need to answer “what happened to this user at 14:03?” Log one line per request with the user ID, and errors with their stack.

Don’t log request bodies on auth routes, Authorization headers or full card numbers. Canner removes code, state, token, password, api_key and similar query parameters from its own request logs, but it does not touch what your app prints (which ones).

Verify: search your logs for password, Bearer and sk_. Nothing should come back.

If your app collects personal information from people in Quebec, Quebec’s private-sector privacy act, as amended by Law 25, applies to you whoever you are. These are the parts an app team handles. It is our reading of the Act, not legal advice.