Docs audit — deploy platforms — 2026-08-13 #57

Audited: the deploy platform docs (deploy/*.mdx, 10 target pages) against mnfst/manifest at 9b2704cfa (#2712), docs at 0a1d7a4. Scope: the deploy pages only. Window: the full deploy-template surface; the last deploy change is PR #2693 (2026-08-07, persist recordings in deployment templates).

The recordings-persistence gaps already filed in #48 (heroku, render, digitalocean, aws, fly, easypanel, koyeb) are still open and are NOT repeated here. The platform has not changed on those points. This run covers the two deploy pages #48 never audited (coolify, gcp) and one cross-topic wording inconsistency.

Findings

1 · [WRONG] Seven deploy pages say the first account automatically "becomes the admin"; a fresh instance actually sends you to a setup screen where you create that account yourself

Page: https://manifest.build/docs/deploy/gcp, /coolify, /aws, /digitalocean, /render, /koyeb, /railway (each in its "Open Manifest" step). Three sibling deploy pages already use the corrected wording: /heroku, /easypanel, and the self-hosted page.

What actually happens:

1. You open the deployed app URL.
2. If no account exists yet, Manifest redirects you to a setup screen.
3. You fill a short form (name, email, password) and click "Create admin account".
4. That account is the instance's first and only user. No separate "admin" role is granted: "admin" is just what the setup screen calls that first account.

Options:

1. Replace the passive sentence on all seven pages with the wording heroku/easypanel already ship: "Fresh installs redirect to /setup; the first account you create becomes the admin." Recommended.
2. Leave as-is: the user still ends up as the admin, so nothing breaks.
3. Delete only the second sentence ("The first account becomes the admin.") and keep "create the first account".

2 · [MISSING-CASE] The Coolify page tells you to back up only the PostgreSQL volume, but request logs live in a second volume the template also creates

Page: https://manifest.build/docs/deploy/coolify ("What Gets Provisioned" and "Production notes")

What actually happens:

1. The Compose stack creates two persistent storage volumes: one for the PostgreSQL database, one for request logs.
2. Request logs are written to that second volume.
3. The page lists only the PostgreSQL volume and tells you to "keep the PostgreSQL volume backed up".
4. A user who backs up only what the page names loses every request log if the stack is rebuilt.

Fix: name the request-logs volume in "What Gets Provisioned" and extend the backup note to cover both volumes.

3 · [MISSING-CASE] The GCP page never mentions the Cloud Storage bucket it provisions for request logs, so nothing tells you it exists or that teardown leaves it behind

Page: https://manifest.build/docs/deploy/gcp (Overview and Production notes)

What actually happens:

1. The deploy creates a private Cloud Storage bucket for request logs and stores your logs there.
2. The deploy prints the bucket's name at the end of the run.
3. The bucket is protected against deletion, so the teardown command leaves its contents in place.
4. To fully tear down you must export or delete the bucket's contents first. The page documents this for the database but not for the bucket.

Options:

1. Add a short "Request logs" note (a private Cloud Storage bucket is provisioned and mounted at /data/request-recordings, shown as the recording_bucket output) and a Production-notes teardown bullet (export or delete its contents before deploystack uninstall). Recommended.
2. Add only the teardown bullet, matching the Cloud SQL deletion-protection note already on the page.

Reply with the finding number and the chosen option
(e.g. "3 → option 2", or "3: other idea, let's discuss").
PRs are then made manually with the agent, never by the harness.
Rejected findings: reply "N → reject" and they will never be re-raised.