claude-hdb
a10349d835
Public tool, private state. cast holds no hostnames, no bindings, no secrets: it joins a product repo's .infra/ manifest with a state directory you point it at, and makes Coolify match. Extracted from heavy-duty/infra, which was half tool and half state — the inconsistency that made it impossible to say whether "infra" named a CLI or a runbook. rig builds the boxes; cast fills them; infra is what they are filled with. Two changes were required to make it genuinely stateless and publishable: - The implicit cwd contract (environments.yaml / secrets/ / .coolify.env resolved against the working directory, silently reading the wrong file from the wrong place) is now an explicit --state <dir> / $CAST_STATE. - BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the only product knowledge in the executor — becomes the generic, operator- owned environments.<env>.forbidden_var_patterns. The guard now lives in private state, so a product-side change cannot lower its own guard, and it is a pattern rather than a list, so it catches unforeseen siblings. Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then ~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended apply mechanism, with no environment names known to the tool. Instance identity (org names, the GitHub App name, founder domains) is out of the fixtures and out of register-github-app.sh, which took APP_NAME and ORG as arguments rather than baking them in. 69 tests green; bin/cast + curl installer mirror rig's shape. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.6 KiB
API reference (pinned)
coolify-openapi-4.1.2.json is the OpenAPI spec at the pinned Coolify tag.
The executor is written against THIS file plus controller behavior verified
2026-07-10 (the published spec omits is_buildtime/is_runtime on env
write endpoints; the controllers accept them — infra smoke guards this).
On any Coolify upgrade: re-vendor at the new tag, diff, re-run infra smoke.
Known gap: S3 storage destinations have no API surface (verified 2026-07-10)
Coolify 4.1.2 exposes no endpoint at all — not list, not create, not
read — for S3 storage destinations (the backup-target resource referenced
by s3_storage_uuid on database-backup payloads). Verified two ways:
- The vendored spec has zero
/storages-as-a-resource paths; the onlystoragespaths are/applications/{uuid}/storages,/databases/{uuid}/storages,/services/{uuid}/storages— these are per-resource Docker volume mounts, a different Coolify concept. - Upstream
routes/api.phpat tagv4.1.2imports only these Api controllers: Applications, CloudProviderTokens, Databases, Deploy, Github, Hetzner, Other, Project, Resources, ScheduledTasks, Security, Sentinel, Servers, Services, Team. There is no Storage/S3 controller — the route table has zero routes matchingstorageors3outside the three per-resource-type volume-mount groups above.
S3 storage destinations are UI-only in this Coolify version (Settings → S3 Storages). No S3 storage API exists in 4.1.2 — the destination UUID is recorded in environments.yaml by the bootstrap runbook; the client deliberately has no storage resolver. Re-check on any Coolify upgrade re-vendor.