How to install Coolify on a VPS for self-hosted deployments

Coolify is a self-hosted application deployment platform. It connects to servers over SSH, builds images, starts Docker workloads, stores deployment credentials, and routes domains through an integrated proxy. That makes a Coolify VPS both a hosting server and a privileged control plane: access to the dashboard can become access to every application and server it manages.

This guide installs Coolify on a fresh Ubuntu 24.04 LTS LayerOne VPS with the official installer. It exposes the temporary IP-based setup ports only to an administrator, moves the dashboard to HTTPS, and then closes those direct ports.

Coolify VPS requirements and LayerOne cost

Coolify's own documentation gives the 2-core, 2-GB, and 30-GB minimum. The recommended size and CPU ranges above are planning estimates for a small single-server deployment, not guarantees. Docker builds, language dependency installation, local databases, image layers, and application traffic dominate real use. A build can make the dashboard unresponsive even when the steady application load is low. Move builds or workloads to separate servers, set resource limits, or resize when measurements justify it.

LayerOne bills hourly, and application transfer or optional services can vary. The monthly equivalent assumes a continuously existing server. Confirm current catalog values on Pricing.

Supported setup and prerequisites

Coolify's automatic installer supports Ubuntu LTS 20.04, 22.04, and 24.04. Use a fresh Ubuntu 24.04 LTS VPS; existing Docker stacks or listeners on required ports commonly cause conflicts. The installer runs as root, installs Docker when needed, and writes Coolify under /data/coolify.

Before continuing:

1. Complete Your first hour on a new server.
2. Point a DNS record such as coolify.example.com at the VPS.
3. Make sure TCP 80, 443, 8000, 6001, and 6002 are unused:

sudo ss -lntp | grep -E ':(80|443|8000|6001|6002)[[:space:]]' || true

Coolify does not support Docker installed through Snap. Let the installer add Docker or install it from Docker's official repository.

1. Configure temporary installation firewall rules

At the LayerOne Networking tab, set inbound policy to DROP and outbound to ACCEPT. Add:

Do not open 8000, 6001, or 6002 to the whole internet. If your address changes, update the source rule instead. See The cloud firewall.

Mirror the intent with UFW:

sudo apt update
sudo apt install -y curl ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from YOUR.ADMIN.IP.ADDRESS to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from YOUR.ADMIN.IP.ADDRESS to any port 8000 proto tcp
sudo ufw allow from YOUR.ADMIN.IP.ADDRESS to any port 6001 proto tcp
sudo ufw allow from YOUR.ADMIN.IP.ADDRESS to any port 6002 proto tcp
sudo ufw enable
sudo ufw status verbose

Replace YOUR.ADMIN.IP.ADDRESS before executing the commands. Coolify's official firewall documentation warns that Docker's iptables rules can bypass UFW. The LayerOne cloud firewall is therefore the reliable upstream control for published containers; do not omit it.

2. Run the official installer

The shortest official command is:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

That executes current remote code as root. If your security process requires a review first, download the same script, inspect it, and then run the saved copy:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o /tmp/coolify-install.sh
less /tmp/coolify-install.sh
sudo bash /tmp/coolify-install.sh

Do not reuse an old downloaded installer indefinitely. Coolify's dependencies and Compose definitions change with releases.

The installer creates directories under /data/coolify, generates SSH keys, installs and configures Docker, and starts the control-plane containers. When it finishes, inspect the result:

docker version
docker compose version
docker ps --format 'table {{.Names}}    {{.Status}} {{.Ports}}'
docker logs --tail=100 coolify
curl -fsSI http://127.0.0.1:8000

If the installation fails, do not repeatedly pipe the installer into Bash. Check free space, memory, Docker status, the five required ports, and the installer's official troubleshooting page first.

3. Claim the administrator immediately

Open http://SERVER_IP:8000 from the administration source allowed by the cloud firewall. The first visitor can reach Coolify's registration screen. Create the owner account immediately with a unique password, then enable two-factor authentication. Do not leave an unclaimed instance running overnight.

In Coolify, validate the local server and deploy a tiny test application. Check that it reaches healthy state and that the logs are visible. A working dashboard alone does not prove Docker builds, proxy routing, or application DNS work.

4. Put the Coolify dashboard on HTTPS

Set Coolify's instance URL to https://coolify.example.com in its settings, using the DNS record already pointed at the VPS. Coolify's integrated Traefik or Caddy proxy requests and renews the certificate when the domain includes the https:// scheme.

Open the HTTPS hostname in a private browser window, sign in, load real-time updates, and open the web terminal. Only after all of those work should you close direct-IP access.

Remove TCP 8000, 6001, and 6002 from the LayerOne cloud firewall, then remove the matching UFW rules:

sudo ufw delete allow from YOUR.ADMIN.IP.ADDRESS to any port 8000 proto tcp
sudo ufw delete allow from YOUR.ADMIN.IP.ADDRESS to any port 6001 proto tcp
sudo ufw delete allow from YOUR.ADMIN.IP.ADDRESS to any port 6002 proto tcp
sudo ufw status verbose

Because Docker can bypass UFW, verify the cloud rules were removed. Keep TCP 80 and 443 public for proxied applications and certificate issuance, and keep SSH restricted. Test from a network not on the administrator allowlist:

curl -fsSI https://coolify.example.com
curl --connect-timeout 5 -I http://SERVER_IP:8000

The HTTPS hostname should work. The direct port should time out or be rejected.

5. Deploy applications without opening random ports

For ordinary web applications, configure a domain in Coolify and let the integrated proxy route public 80/443 to the container's internal port. Do not publish PostgreSQL, Redis, Docker API, debug, metrics, or framework development ports to 0.0.0.0.

Every time a project adds a port mapping, inspect the public surface:

docker ps --format 'table {{.Names}}    {{.Ports}}'
sudo ss -tulpn | grep -vF '127.0.0.1' | grep -vF '[::1]'

Add a LayerOne cloud-firewall rule only for a service intentionally designed to be reached directly. Databases should normally stay Docker-internal or on a private network with a narrowly scoped rule.

6. Watch CPU, memory, and disk during builds

Run a representative build while watching:

docker stats
df -h / /data /var/lib/docker
docker system df
free -h

Set application memory and CPU limits in Coolify. Configure Docker log limits and scheduled cleanup, but never delete a named volume merely to recover disk space. If local builds repeatedly use all CPU or memory, build in CI and deploy an image from a registry, or attach a separate build/deployment server.

7. Back up the control plane and every workload

Coolify's instance backup saves its own database: projects, resources, settings, and deployment history. It does not back up application databases, bind mounts, or Docker volumes.

In Settings → Backup, configure and run a Coolify instance backup. Copy the backup away from this VPS. Separately save:

• an encrypted copy of /data/coolify/source/.env, especially its APP_KEY, without printing the file into logs;
• /data/coolify/ssh/keys/ and the corresponding authorized public keys; and
• engine-aware database dumps and volume/bind-mount backups for every deployed workload.

The APP_KEY decrypts credentials in a restored Coolify database, while the rest of .env preserves other generated installation settings and secrets. A database dump without that file is not a complete recovery set. Keep both encrypted and off server. Test the official restore procedure on an isolated replacement host and test applications separately. LayerOne does not back up the server; see Backups and snapshots.

8. Update Coolify deliberately

Coolify self-hosted instances can update automatically, but the project recommends controlled updates for production. Make a current instance backup and workload backups, read the release notes, and use the dashboard's Update control. The official manual updater is:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

After an update:

docker ps --format 'table {{.Names}}    {{.Status}}'
docker logs --tail=100 coolify
curl -fsSI https://coolify.example.com

Then validate the local server, build a test application, inspect the proxy, and reconfirm that 8000, 6001, and 6002 are still blocked upstream.

Security pitfalls

• Coolify is a privileged control plane. Limit owners and administrators, use MFA, and remove former team members promptly.
• Disable public registration and API access unless required. Restrict API source addresses and create separate least-privilege tokens for integrations.
• Protect Coolify's SSH keys, APP_KEY, database, environment values, backups, and Git-provider credentials as root-equivalent recovery material.
• Do not install unrelated software on the control-plane host. Port conflicts and shared Docker access widen the blast radius.
• Review deploy hooks and webhooks. A leaked deployment token may run code from an attacker-controlled revision.
• Coolify manages deployment; it does not patch application images, design a backup policy, or secure every service automatically.

Official and LayerOne references

• Official Coolify installation and requirements
• Official Coolify firewall guide
• Official Coolify domains and HTTPS guide
• Official Coolify backup and restore guide
• Official Coolify upgrade guide
• LayerOne cloud firewall
• Running Docker
• Resize to a larger plan