canonical: https://jentic.com/apis/coolify.io/coolify # Coolify Jentic publishes the only available OpenAPI specification for Coolify, keeping it validated and agent-ready. Coolify is an open-source, self-hostable platform for deploying applications, databases, and services from Git, Dockerfile, Docker image, or Docker Compose definitions. The 134 endpoints cover application lifecycle, environment variables, storage volumes, cloud provider tokens, databases, services, projects, servers, teams, and team members. Authentication is a bearer API token created from the Coolify dashboard's Keys and Tokens section, and the same API works against Coolify Cloud or any self-hosted instance. ## For AI agents Deploy and manage applications, databases, and services on Coolify across self-hosted or cloud instances. Agents authenticate with a bearer API token from Keys and Tokens. ## Scope Does not provision underlying cloud servers, manage DNS records, or run CI builds - use for application, database, and service lifecycle management on Coolify only. ## Capabilities - Create applications from public or private GitHub repos, Dockerfiles, Docker images, or Docker Compose via the /applications POST endpoints - Start, stop, and restart applications via `/applications/{uuid}/start`, /stop, and /restart - Manage environment variables individually or in bulk via `/applications/{uuid}/envs` and `/envs/bulk` - Provision and manage persistent storage volumes for applications via `/applications/{uuid}/storages` - Manage cloud provider tokens used for deployments via /cloud-tokens with a validate endpoint - Provision databases and services and inspect their logs through the /databases and /services endpoints - Manage projects, servers, teams, and team members from a single API ## Use cases ### Self-Hosted Deployment Automation Replace manual SSH-and-docker-compose with API-driven deployments on a self-hosted Coolify server. POST `/applications/public` creates the app from a Git repo, `/applications/{uuid}/envs` sets configuration, and `/applications/{uuid}/start` launches it. Suited to engineering teams running Coolify as their internal Heroku and wanting deploys triggered from CI rather than the dashboard. Example prompt: Create an application from https://github.com/acme/web on the production server, set DATABASE_URL via POST `/applications/{uuid}/envs`, then call `/applications/{uuid}/start` ### Database Provisioning for Preview Environments Spin up disposable Postgres or Redis instances per pull request via the /databases endpoints, attach them to a freshly deployed application, and tear everything down when the branch is merged. Coolify's API treats databases as first-class resources with their own lifecycle endpoints. Useful for engineering teams running real preview environments with isolated data per branch. Example prompt: Create a Postgres database for PR #4123, capture its connection string, set it on the preview application's envs, and start the application ### Multi-Server Application Lifecycle Management Operate a fleet of Coolify servers across regions or clients by listing servers, projects, and applications through the API and pushing lifecycle commands centrally. The /servers, /projects, and /applications endpoints surface state, and /teams plus /team-members manage access. Useful for agencies and platform teams running Coolify on behalf of customers. Example prompt: List all servers and applications, then restart any application whose latest deployment status is 'failed' ### Agent-Driven Deployment Workflows via Jentic An AI agent operates a Coolify instance through Jentic - creating applications, setting envs, and running lifecycle commands - without holding the API token. The agent searches Jentic for the deploy intent, loads the schema, and orchestrates the multi-step flow. Through Jentic the bearer token is held in the vault so deployment automation runs without secret exposure. Example prompt: Search Jentic for 'deploy a coolify application', load the schema, then create a Node.js app from a Git repo, set NODE_ENV=production, and start it ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/applications` | List applications | | POST | `/applications/public` | Create an application from a public Git repo | | POST | `/applications/dockercompose` | Create an application from a Docker Compose file | | GET | `/applications/{uuid}/start` | Start an application | | GET | `/applications/{uuid}/logs` | Get application logs | | POST | `/applications/{uuid}/envs` | Create an environment variable on an application | | GET | `/databases` | List databases | ## Key resources - **Applications** — Create, configure, deploy, and control applications from Git, Dockerfile, image, or Compose - **Databases** — Provision and manage databases such as Postgres, MySQL, and Redis - **Services** — Deploy prebuilt services from the Coolify catalog and control their lifecycle - **CloudTokens** — Store and validate cloud provider tokens used for deployments - **Servers** — Manage the underlying servers Coolify deploys onto - **Projects** — Group applications, databases, and services into logical projects - **Teams and Team Members** — Manage access for human and machine users ## Why Jentic - **Setup:** Wiring Coolify by hand means holding its bearer token and coding the application, database, and service lifecycle calls yourself across its 134 endpoints. Through Jentic you install once, import Coolify from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** Coolify puts the application uuid in the URL path (`/applications/{uuid}/start`, `/applications/{uuid}/logs`, `/applications/{uuid}/envs`), so a rule can pin your agent to one application: it can start it and read its logs and nothing else. You choose the operations it may call, so creating new applications or editing environment variables is not included unless you add them. - **Credential handling:** Your Coolify token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'deploy a Coolify application' or 'read a Coolify service log', and Jentic returns the matching applications, databases, or services operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Render API** — Hosted PaaS for deploying web services and databases, similar deploy primitives to Coolify Cloud. - **Railway API** — Hosted developer platform for deploying apps and databases from Git or Docker. - **DigitalOcean API** — Cloud infrastructure provider that often hosts the underlying servers a self-hosted Coolify runs on. ## FAQ ### Why is there no official OpenAPI spec for Coolify? Coolify does not publish a maintained OpenAPI specification covering every endpoint. Jentic generates and maintains this spec so that AI agents and developers can call Coolify via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Coolify API use? Coolify uses HTTP bearer authentication. Generate a token in the Coolify dashboard under Keys and Tokens / API tokens and send it as Authorization: Bearer on every call. Through Jentic the token is stored encrypted in the vault and injected at execution time so it never enters the agent's prompt. ### Can the Coolify API deploy an application from a private GitHub repo? Yes. POST `/applications/private-github-app` deploys from a private repo via a configured GitHub App, and POST `/applications/private-deploy-key` deploys using a deploy key. Use POST `/applications/public` for public repos and POST `/applications/dockerfile` or /dockerimage for non-Git sources. ### Does the Coolify API work with self-hosted instances? Yes. The base URL on Coolify Cloud is https://app.coolify.io/api/v1, but the same API runs on every self-hosted Coolify instance - point requests at https://your-coolify-host/api/v1 and use a token generated on that instance. ### How do I update many environment variables at once? PATCH `/applications/{uuid}/envs/bulk` accepts an array of env updates so dozens of variables can be changed in a single call. This is faster than iterating through PATCH `/applications/{uuid}/envs` per variable when reseeding configuration after a config-as-code change. ### What are the rate limits for the Coolify API? Rate limits are not declared in the OpenAPI spec. Self-hosted instances do not impose any out of the box, while Coolify Cloud applies plan-level limits - back off on HTTP 429 responses. Contact Coolify support for documented limits applicable to your plan. ### How do I deploy an application through Jentic? Run jentic search for 'deploy a coolify application', load the POST `/applications/public` (or /dockercompose) operation, then execute it with the Git repo, project, and server UUIDs. Chain in `/applications/{uuid}/envs` and `/applications/{uuid}/start` to set configuration and launch the deploy. Jentic injects the bearer token from the vault. ### Can I limit what my agent is allowed to do with the Coolify API? Yes. Jentic One is self-hosted by you, so your own rules decide which Coolify operations and which token the agent may use. Because Coolify puts the application uuid in the URL path, such as `/applications/{uuid}/start`, `/applications/{uuid}/logs`, and `/applications/{uuid}/envs`, you can pin the agent to a single application, letting it start that app and read its logs and nothing else. You choose the operations it may call, so creating new applications or editing environment variables stays out of reach unless you explicitly add those operations.