carlos / platform Public

Paul asked for carlosframework.com/platform/self-host/ to become a step-by-step guide: create an infrastructure repo, copy the OpenTofu examples, choose regions/hosts, bootstrap, and deploy an app. Checking released v0.28.9 (platform 26fbd042) against the public examples found that a new operator cannot complete that flow using published material alone.

Please provide a supported public self-host bootstrap path, with a fresh-install test, rather than making the website reconstruct private deployment scripts.

Confirmed gaps:

• Release artifacts and the normal build recipe publish carlos, not the separate cmd/console binary.
• carlos bootstrap installs host units but no base console.service, console service identity, or registry/console data permissions.
• There is no fresh-deployment bootstrap for the console's ops/console application and its route/update lifecycle. The console-as-an-app design already calls this a product gap.
• carlos system claims install-console is a dormant activation tool with deployment-specific assumptions, not a general installer; it must not be advertised as one.
• The public OpenTofu example references host-init.sh without supplying it. The reference Debian AMI needs SSM agent installation before the documented Session Manager bootstrap works.
• The multi-region example uses providers = { aws = aws.${each.key} }, explicitly pseudocode, and an undefined additional data bucket resource. Publish valid static provider aliases and complete regional bucket definitions.
• The host bootstrap installs the Litestream service but not its executable or complete configuration/enablement. Document and test system database backups, including the actual console.db path, separately from tenant hibernation replication.

Acceptance criteria:

1. From a new infrastructure repo, copy a public, version-pinned example and reach a working console + first CLI deployment without private repos or live-box folklore.
2. Publish supported console artifacts or a reproducible public source-build path, base service/user setup, required filesystem permissions, first operator access and HTTPS routing.
3. Keep the console signing key isolated from tenant processes. A root-owned EnvironmentFile alone is insufficient if the console and app children share a UID; establish and test the intended service identity boundary.
4. Provide a small reference host configuration (current public example: t4g.small, 2 vCPU / 2 GiB RAM / 20 GiB disk). State measured minimums only if measured.
5. Support and test single-region/one-host plus multi-region/one-host-per-region examples. v0.28.9 leaves CARLOSHOSTCLAIM and CARLOSREGIONHA dormant; two hosts in one region must not be presented as safe automatic failover for hibernating instances.
6. Verify backup/restore and document upgrades through supported CLI operations after bootstrap.

No infrastructure was changed or created. Website guide research and a first draft are saved locally under /home/paulca/.cache/carlos-self-host-guide/. The existing live self-host page remains unchanged pending a usable installation path.