Docs audit — deploy platforms — 2026-08-13

[SebConejo]

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".

Evidence (for the agent)

• Passive claim: gcp.mdx:71, coolify.mdx:55, aws.mdx:79, digitalocean.mdx:55, render.mdx:54, koyeb.mdx:66, railway.mdx:47 — all end with "The first account becomes the admin."
• Corrected siblings: heroku.mdx:54, easypanel.mdx:76 — "Fresh installs redirect to /setup; the first account you create becomes the admin."; self-hosted.mdx:14 — "On first access, Manifest takes you to a setup screen where you create the admin account."
• Code: needsSetup() is true only when the user count is 0 (setup.service.ts:84-90); the /setup wizard renders a form (Setup.tsx:70) and a "Create admin account" button (Setup.tsx:127); createFirstAdmin signs the user up via Better Auth and sets emailVerified, assigning no role (setup.service.ts:109-160). No admin role or column exists in the backend.
• The same wording was corrected on self-hosted.mdx in issue Docs audit — introduction (getting started) — 2026-08-07 #49 finding 2 (accepted, shipped in PR docs: resolve getting-started audit findings (issue #49) #50). This raises it for the deploy pages, a different page set, not a re-raise of a rejected finding.
• Impact: low. The user becomes the admin regardless, but the topic now describes the same step two different ways.

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.

Evidence (for the agent)

• coolify.mdx:67 — "Persistent Docker volume for PostgreSQL data." ; coolify.mdx:72 — "Keep the PostgreSQL volume backed up through Coolify or your server provider."
• Template: deploy/coolify/docker-compose.yml:16-17 (REQUEST_RECORDING_STORAGE=filesystem, path /data/request-recordings), :19 mount manifest-recordings-data:/data/request-recordings, :49-50 both volumes declared (manifest-postgres-data, manifest-recordings-data).
• Suggested wording (recommended fix):
  • "What Gets Provisioned": add "- Persistent Docker volume for request logs, mounted at /data/request-recordings."
  • Backup note: "Back up both Docker volumes through Coolify or your server provider: PostgreSQL data and the request logs volume at /data/request-recordings."
• Impact: silent request-log loss on any rebuild that does not preserve the second volume.
• Not a re-raise: coolify.mdx was not among the Docs audit — 2026-08-07 (PRs #2693–#2697) #48 deploy findings.

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.

Evidence (for the agent)

• gcp.mdx has no recordings/bucket/storage mention anywhere; Production notes gcp.mdx:81 mentions only "Cloud SQL deletion protection is enabled by default."
• Template: deploy/gcp/main.tf:123-126 google_storage_bucket "recordings" (${local.name_prefix}-recordings, force_destroy = false), :249-250 mount at /data/request-recordings, :204-210 REQUEST_RECORDING_STORAGE=filesystem; outputs.tf:21-23 output recording_bucket; TUTORIAL.md:57 "export or delete its contents before uninstalling".
• The platform's own GCP tutorial documents this (deploy/gcp/TUTORIAL.md:5,34,57); the docs page omits it.
• Suggested wording (recommended): a new "## Request logs" note — "The stack provisions a private Cloud Storage bucket and mounts it at /data/request-recordings for request recordings. The deploy prints its name as the recording_bucket output." ; a Production-notes bullet — "The request logs bucket keeps its objects on teardown. Export or delete its contents before deploystack uninstall."
• Impact: users do not know request logs are stored in a provisioned bucket, and teardown silently leaves a retained, deletion-protected bucket behind. Same class as the AWS retained-bucket case (Docs audit — 2026-08-07 (PRs #2693–#2697) #48 finding 9); GCP was never audited.

---

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.