Operations and safety¶
Token rules¶
- Create separate tokens for each team, AI client, and CI workflow.
- Start with
read. - Use
deployonly for existing application lifecycle actions. - Use short-lived
writeonly to create or modify resources. - Do not use
rootfor routine automation. - Set expirations and rotate or revoke tokens regularly.
Two-stage AI commit¶
website-planrenders an official API payload without a remote write.- A person reviews the resources, domain, repository, environment, and limits.
- Use
--allow-writeto create or deploy. - Return to a read-only token and inspect status and log summaries.
Pre-release checklist¶
- [ ] Repository provenance and license are reviewed.
- [ ] Build and start commands are explicit.
- [ ] CPU, memory, storage, and build concurrency are bounded.
- [ ] Health checks work.
- [ ] TLS, domains, and redirects are correct.
- [ ] Secrets are absent from Git, logs, and prompts.
- [ ] Backup and restore are verified.
- [ ] Team members and tokens follow least privilege.
- [ ] A known stable version exists for rollback.
Failure handling¶
| Symptom | First action |
|---|---|
| Control plane unavailable | Run coolify health |
| 401 | Check token completeness, expiry, and revocation |
| 403 | Check team, permission, API Access, and IP allowlist |
| 422 | Correct request fields; do not replay writes blindly |
| 429 | Follow Retry-After; do not retry writes concurrently |
| Deployment failure | Stop automatic retries, inspect the deployment, and decide on a fix or rollback |
Host boundary¶
Coolify is a high-privilege control plane. Team roles do not equal VM-grade isolation; untrusted code should not share a Docker daemon with existing production workloads.