Coolify is a self-hosted platform for deploying applications, databases, and services from Git repositories or Docker images. It provides a browser-based deployment workflow while the applications continue to run on infrastructure you control.
In this tutorial, you will prepare a fresh Ubuntu 24.04 server, run the official Coolify installer, secure the first administrator account, configure DNS and HTTPS, deploy an application, review network exposure, and establish separate backup and update procedures for Coolify and the workloads it manages.
Step 1 — Choose an Appropriate Server
Coolify's automatic installer supports Ubuntu 24.04 LTS on AMD64 and ARM64 systems. The documented minimum is 2 CPU cores, 2 GB RAM, and 30 GB of free storage.
Those values are installation minimums rather than a universal production size. Every application, database, build, and image adds CPU, memory, and storage demand. A 2 vCPU and 4 GB RAM VM is a more practical starting point for Coolify plus several light workloads.
Use a fresh server when possible. Existing reverse proxies, manually managed Docker networks, firewall scripts, or applications already occupying ports 80, 443, or 8000 can conflict with Coolify.
Check the operating system and available resources:
cat /etc/os-release
nproc
free -h
df -h /
Do not install Docker through Snap. Coolify's documentation lists the Snap-based Docker package as unsupported.
Step 2 — Prepare DNS and Secure SSH Access
Create a DNS A record such as:
coolify.example.com -> your_server_ipv4
Publish an AAAA record only when IPv6 reaches the same VM and is protected correctly.
Connect with a non-root sudo user and update Ubuntu:
sudo apt update
sudo apt upgrade -y
Coolify manages local and remote deployment servers over SSH. Confirm your SSH key access works before installation:
ssh your_user@your_server_ip
Avoid aggressive SSH rate limiting that can interrupt Coolify's repeated management connections. Key-only authentication, a trusted-source firewall rule, or private network access is usually safer than a low connection-attempt threshold.
Step 3 — Check Port Availability
Coolify needs public web ports for its proxy and an initial dashboard endpoint:
22/tcp or your configured SSH port for server management
80/tcp for HTTP traffic and certificate validation
443/tcp for HTTPS traffic
8000/tcp for the initial Coolify dashboard setup
Check whether another process already listens on these ports:
sudo ss -ltnp | grep -E ':(22|80|443|8000)\b' || true
The SSH port should already be in use. Ports 80, 443, and 8000 should be available on a fresh server.
If UFW is active, allow the required ports:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 8000/tcp
sudo ufw status numbered
Keep port 8000 reachable only long enough to create the first administrator account and establish the HTTPS dashboard domain. Restrict it afterward when your access design allows.
Step 4 — Run the Official Coolify Installer
Install curl if necessary:
Run the official installer with sudo:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
The installer configures Docker, creates Coolify's files under /data/coolify, prepares SSH keys used for server management, and starts the Coolify services.
Do not execute an installation script from an unverified mirror. The command above uses the hostname documented by Coolify.
When installation finishes, inspect running containers:
sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
Review installer or container logs when a service restarts repeatedly:
sudo docker ps -a
sudo docker logs --tail=200 coolify 2>/dev/null || true
Container names can change between Coolify releases, so treat the actual docker ps output as the source of truth rather than relying on a fixed list.
Open the initial dashboard:
http://your_server_ip:8000
Create the first administrator account immediately. Until the initial registration is completed, leaving the setup endpoint broadly reachable creates an avoidable takeover risk.
Use:
- A unique administrator email address
- A long password stored in a password manager
- A recovery process documented outside the VM
After creating the account, sign out and sign back in to confirm the credentials work before changing firewall access.
Step 6 — Configure the Coolify Dashboard Domain
In Coolify's instance settings, configure a dashboard URL such as:
https://coolify.example.com
The DNS record must already point to the VM. Coolify's proxy can then route the hostname and obtain a TLS certificate.
Verify the dashboard over HTTPS:
curl -I https://coolify.example.com
Once the HTTPS hostname works, review whether port 8000 still needs public access. Restrict it to a trusted source address when practical:
sudo ufw delete allow 8000/tcp
sudo ufw allow from 203.0.113.5 to any port 8000 proto tcp
Replace the documentation address with your real trusted public IP. Do not remove access until the HTTPS dashboard and a recovery method have been tested.
Step 7 — Create a Project and Connect a Source
In the dashboard:
- Create a project and environment.
- Add an application resource.
- Choose a public repository, connected Git provider, or Docker image.
- Select the branch and build method.
- Define required environment variables through Coolify rather than committing secrets to the repository.
For private repositories, connect the supported Git provider through Coolify's source settings. Grant only the repository access required for deployment and review the integration when team members or repositories change.
Step 8 — Configure the Application Domain and Port
Create a DNS record such as:
app.example.com -> your_server_ipv4
In the application settings, configure:
- The container's internal listening port
- The public HTTPS domain
- Health checks when the application exposes a suitable endpoint
- Required environment variables and secrets
Prefer domain-based routing through Coolify's proxy. Publishing a container port directly on the host increases network exposure and can remove deployment features such as controlled proxy switching or rolling updates.
Do not expose database ports publicly unless a documented architecture explicitly requires it. Keep application-to-database traffic on Coolify's internal or private networks.
Step 9 — Deploy and Verify the Application
Start the deployment from the Coolify interface and follow the build log. After completion, verify the public endpoint:
curl -I https://app.example.com
Check the running containers and resource usage on the server:
sudo docker ps
sudo docker stats --no-stream
There is no reliable fixed number of applications that one VM can host. Capacity depends on build activity, application memory, databases, traffic, background jobs, and storage growth. Measure actual utilization and leave headroom for deployments and updates.
Coolify can trigger deployments through Git-provider integrations or webhooks. Configure automatic deployments only for branches that are intended to reach that environment.
Before enabling push-to-production automation:
- Protect the production branch.
- Require code review where appropriate.
- Keep deployment secrets outside the repository.
- Define a rollback path.
- Ensure database migrations are backward-compatible or coordinated with deployment.
A successful build does not guarantee a safe production release. Use application health checks and inspect logs after deployment.
Step 11 — Back Up the Coolify Instance
Coolify instance backups protect Coolify's own configuration database. They do not automatically back up every application's persistent volume, uploaded files, or external database.
Configure an S3-compatible destination in Coolify's backup settings when available, and test that backup objects are created.
Also preserve these recovery-critical items outside the VM:
- Coolify's
APP_KEY from /data/coolify/source/.env
- SSH keys under
/data/coolify/ssh/keys
- DNS records and domain inventory
- Application environment variables and secret ownership documentation
Inspect the protected values without copying them into tickets or public logs:
sudo grep '^APP_KEY=' /data/coolify/source/.env
sudo find /data/coolify/ssh/keys -maxdepth 1 -type f -ls
Losing the instance database, application key, or management keys can turn a restore into a manual reconstruction.
Step 12 — Back Up Each Application Separately
Create a backup plan for every stateful workload managed by Coolify:
- PostgreSQL, MySQL, and MongoDB need database-aware dumps or tested native backup methods.
- Uploaded files and application volumes need filesystem or volume backups.
- Object storage data needs its own replication or backup policy.
- External managed services must follow the provider's recovery process.
A VM snapshot can complement these backups, but it should not be the only recovery method for an active database.
Use Raff Data Protection for VM-level recovery and Raff Object Storage as an off-server destination where the application's tooling supports S3-compatible storage.
Step 13 — Update Coolify Safely
Coolify supports update workflows through its interface and documented command-line procedures. Before updating:
- Review release notes and known breaking changes.
- Create a current Coolify instance backup.
- Back up stateful applications separately.
- Confirm adequate free disk space for new images.
- Schedule a maintenance window when the platform is business-critical.
After the update, verify:
sudo docker ps
sudo docker stats --no-stream
curl -I https://coolify.example.com
curl -I https://app.example.com
Check application logs and redeploy a non-critical test service before assuming all deployment paths remain healthy.
Step 14 — Review Security and Capacity Regularly
At regular intervals:
- Remove unused users, sources, projects, and environment secrets.
- Patch Ubuntu and review Docker storage usage.
- Inspect listening ports with
sudo ss -tulpn.
- Confirm port
8000 is restricted according to your access policy.
- Test restoring the Coolify instance and at least one stateful application.
- Monitor CPU, memory, disk space, container restarts, and certificate failures.
A single Coolify VM remains a single failure domain. Adding deployment servers can distribute workloads, but the control plane and each stateful service still require an explicit availability and recovery design.
Conclusion
You now have Coolify installed on Ubuntu 24.04, protected by an administrator account and HTTPS domain, with an application deployed through its proxy and a separate plan for instance and workload backups.
Raff Linux VMs start at $8.49 per month with 2 vCPU, 2 GB RAM, 40 GB NVMe storage, and 3 Gbps unmetered bandwidth. The 2 vCPU and 4 GB RAM plan at $13.99 per month is a more practical starting point for Coolify plus light application workloads, but production sizing should follow measured usage.