How Coolify works

Coolify separates platform control from workload runtime. The Coolify instance stores configuration and coordinates actions, while Docker on each connected server runs your applications, databases, and services.

That separation determines where deployments run, how traffic reaches resources, what each backup contains, and what happens during an outage.

The short version

You configure a resource in the Coolify dashboard or API. The Coolify instance connects to the selected server over SSH, then runs the Docker operations needed to build, deploy, and manage that resource.

For HTTP resources, requests go to the reverse proxy on the server running the resource and then to its containers. The Coolify server does not relay your application traffic.

You can run the Coolify server yourself or use Coolify Cloud. With self-hosted Coolify, you maintain the Coolify server. With Coolify Cloud, the Coolify team maintains it. In both setups, your applications, databases, and services run on servers you provide.

---

The control path and traffic path

Coolify sends deployment and management commands through the control path. Your users reach running HTTP resources through the application traffic path.

How Coolify manages resources and serves traffic

Coolify uses the control path for deployments and management actions. Running HTTP resources use the application traffic path for user requests.

Control path

• Starts when you use the Coolify dashboard or API, trigger a deployment webhook, or run scheduled automation.
• Reads saved configuration from the Coolify database and places the requested action in a queue.
• Reaches the selected server through SSH.
• Runs Docker commands on the target server or a configured build server.

Application traffic path

• Starts from a client after DNS or an upstream network layer directs the request.
• Reaches the reverse proxy on the server running the resource.
• Travels from the reverse proxy to the correct container over Docker networks.
• Does not pass through the Coolify dashboard or API service.

A self-hosted Coolify server can also run deployed resources. In that setup, the Coolify server and resource containers share a machine but still run as separate containers.

---

Parts of a Coolify setup

A Coolify setup has four main parts.

Coolify instanceProvides the Coolify dashboard and API, then runs deployments, server checks, and scheduled jobs.

Connected serversProvide SSH access to Coolify and run Docker for builds, resources, the reverse proxy, and monitoring.

Docker resourcesRun applications, databases, and services as standard containers with networks and persistent storage.

Reverse proxyRoutes configured domains to containers and handles HTTPS on each server where it is enabled.

Coolify does not require a persistent deployment agent on a connected server. It uses SSH for deployments and server actions. The optional coolify-sentinel container adds monitoring data, but it does not replace SSH.

Inside a self-hosted Coolify instance

A standard self-hosted installation runs four base containers.

The coolify-proxy and coolify-sentinel containers belong to the server runtime rather than this base control-plane stack. Coolify starts a reverse proxy on each server where it is enabled, while Sentinel remains optional.

---

From configuration to running containers

The details vary by resource type, but most operations follow the same control path.

Applications built from Git have more build stages than databases, one-click services, or prebuilt images. Read the Build and deployment model for those resource-specific paths.

---

How requests reach a resource

When an HTTP resource has a domain and uses the reverse proxy, a request follows this sequence:

1. DNS or an upstream network layer directs the domain to the connected server.
2. The reverse proxy on that server receives the request on port 80 or 443 and handles TLS when configured.
3. The reverse proxy matches the hostname and path, then forwards the request to the resource container over an attached Docker network.
4. The container handles the request and returns the response.

The Coolify server does not relay these requests. If Coolify and the resource run on the same machine, the reverse proxy still sends each request directly to the resource container.

If you disable the Coolify-managed reverse proxy for a server, you must provide the external routing and TLS path yourself. Non-HTTP resources can communicate over Docker networks or through explicitly published ports instead of this reverse proxy path.

Read Networking in Coolify for Docker networks, reverse proxy options, domains, and your firewall responsibilities.

---

Where configuration and data live

Coolify configuration and workload data do not all live in one place.

An instance backup contains a copy of the Coolify database used by the control plane. Application files, database data, volumes, and external storage on connected servers are not part of an instance backup.

---

When the Coolify instance is unavailable

Already-running resources use Docker and the existing reverse proxy configuration. They do not need the Coolify server to handle each request.

Runtime independence has limits

This comparison assumes the connected server, Docker daemon, resource containers, network path, and reverse proxy remain healthy.

Keeps running

• Containers that Docker is already running
• Persistent data in volumes, bind mounts, or external storage
• The reverse proxy using its existing routing configuration
• Requests to running HTTP resources

Requires the Coolify instance

• Coolify dashboard and API operations
• Deployments, configuration changes, and lifecycle actions started through Coolify
• Scheduled jobs, webhooks, and background automation coordinated by the control plane
• Status checks, log access, and notifications initiated by Coolify

Losing SSH access has a similar boundary: Coolify cannot operate that server, but the SSH failure does not stop existing containers by itself. If the connected server, Docker daemon, reverse proxy, or upstream network fails, resources on that path can become unavailable even while the Coolify instance remains healthy.

Standard Docker resources reduce platform lock-in because you can inspect and operate them directly. The Coolify instance still holds the configuration and automation that make them manageable as Coolify resources. Keep separate backups of the Coolify database and workload data.

---

Continue learning

Use the detailed Core pages to follow each part of the model.

Docker and containers

Learn how images, containers, networks, and volumes form the runtime layer.

Build and deployment model

Follow how Coolify builds images and replaces application containers.

Networking in Coolify

Understand reverse proxy routing, domains, Docker networks, and exposed ports.

Choose the control plane

Compare who operates the Coolify instance before choosing a setup.

1Self-hosted vs Coolify Cloud2Choose your path

Security and backups

Review security responsibilities and create backups for the Coolify database and workload data.

1Security model2Instance backup3Database backups