Coolify is a self-hosted deployment platform for running applications, databases, and services on infrastructure you control. On Ubuntu 24.04, the supported quick-install path is the official Coolify installer, which prepares Docker, creates the Coolify control-plane files under /data/coolify, configures server-management SSH keys, and starts the platform.
Raff Technologies is the VM platform used by the original tutorial. The saved tested environment remains Ubuntu 24.04 LTS on Raff 2 vCPU / 4 GB RAM Linux VM; installer, networking, backup, and update guidance reviewed against Coolify documentation in July 2026. This revision re-verifies the workflow against current Coolify documentation on September 5, 2026 without claiming a new end-to-end machine test.
The current documented minimum is 2 CPU cores, 2 GB RAM, and 30 GB of free storage. Treat that as an installation floor, not a production sizing guarantee. Builds, databases, image layers, application memory, persistent volumes, and deployment overlap can require substantially more resources. Coolify also needs several direct-access ports during initial setup; once a custom dashboard domain is working through Coolify's proxy, the direct dashboard/realtime/terminal ports can be closed according to the official firewall guidance.
Prerequisites:
- A fresh Ubuntu 24.04 LTS VM with at least 2 CPU cores, 2 GB RAM, and 30 GB free storage
- SSH access and a tested recovery path
- A domain or subdomain you control
- Public TCP 80 and 443 available for Coolify's proxy
- DNS access for the dashboard and application hostnames
Step 1 — Verify Ubuntu, resources, storage, and existing listeners
Confirm the operating system:
cat /etc/os-release
uname -m
Coolify's automatic installer supports Ubuntu LTS releases including 24.04 and 64-bit AMD64/ARM64 systems.
Check CPU, memory, and free disk space:
Check filesystem usage under /data if it already exists:
df -h /data 2>/dev/null || true
Inspect listeners before installing Coolify:
Pay particular attention to ports 80, 443, 8000, 6001, and 6002. Existing reverse proxies, web servers, Docker stacks, or manually managed applications can conflict with Coolify.
Use a fresh server where practical. Coolify's own documentation recommends this to reduce conflicts with existing services and networking rules.
Verify: Ubuntu should report 24.04 LTS on a supported 64-bit architecture, the server should meet the minimum resource floor, and you should know whether any process already occupies Coolify-related ports.
Step 2 — Confirm SSH access and update Ubuntu safely
Coolify manages its local and remote servers through SSH, so server access is part of the platform's control plane.
Open a second SSH session before making firewall changes:
ssh your_user@your_server_ip
Update package metadata and review upgrades:
sudo apt update
apt list --upgradable 2>/dev/null
Apply updates according to your maintenance policy:
Check whether Ubuntu requests a reboot:
if [ -f /var/run/reboot-required ]; then
cat /var/run/reboot-required
else
echo "No reboot required"
fi
Current Coolify quick-install documentation recommends running installation as root; it also documents sudo for users who are not logged in as root. Do not assume every non-root setup is fully supported simply because sudo can launch the installer.
For general SSH hardening, see Harden Ubuntu 24.04.
Verify: A second SSH connection should work, sudo should be functional if you are not root, updates should complete without repository errors, and any required reboot should be handled before installation.
Step 3 — Review Coolify's required ports before enabling or changing a firewall
For a self-hosted Coolify server, current official firewall documentation lists these inbound ports when using direct IP access:
22/tcp SSH, or your custom SSH port
80/tcp HTTP and certificate generation through the proxy
443/tcp HTTPS through the proxy
8000/tcp Direct Coolify dashboard access
6001/tcp Realtime dashboard communication for direct IP access
6002/tcp Coolify web terminal for direct IP access
Check them locally:
sudo ss -lntp | grep -E ':(22|80|443|8000|6001|6002)\b' || true
If UFW is already active, confirm the real SSH port is allowed before adding Coolify rules.
For initial setup, a straightforward rule set is:
sudo ufw allow 80/tcp comment 'Coolify HTTP'
sudo ufw allow 443/tcp comment 'Coolify HTTPS'
sudo ufw allow 8000/tcp comment 'Coolify initial dashboard'
sudo ufw allow 6001/tcp comment 'Coolify realtime direct access'
sudo ufw allow 6002/tcp comment 'Coolify web terminal direct access'
Do not blindly enable UFW over SSH if it is currently inactive. Use the lockout-safe flow in Set Up UFW Firewall on Ubuntu 24.04.
Docker creates its own firewall/NAT rules. Treat Docker-published application ports separately from ordinary UFW host rules; do not assume UFW alone will block every Docker-published port.
Verify: The active SSH path must remain reachable, ports required for initial Coolify setup should be intentionally available, and no unrelated process should be unexpectedly bound to those ports.
Step 4 — Run the official Coolify stable installer
Install curl if needed:
sudo apt update
sudo apt install -y curl
Run the official stable installer documented by Coolify:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
If you are already root, the documented command can run without sudo:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
The installer:
- installs required command-line tools;
- installs Docker Engine when needed;
- configures Docker for Coolify;
- creates files under
/data/coolify;
- creates SSH keys used by Coolify for server management;
- starts the Coolify control plane.
Docker installed through Snap is not supported. If the installer detects Snap Docker, remove that package and follow the supported Docker path before retrying.
For production, use the normal stable installer/CDN path rather than forcing a GitHub release simply because it is newer. Coolify intentionally may delay CDN availability after a GitHub release for additional testing.
Verify: The installer should complete without an unsupported-OS/Docker error and should print the initial Coolify URL, normally using TCP 8000.
Step 5 — Verify the Coolify containers and initial dashboard listener
Inspect the running containers:
sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
Check port 8000:
sudo ss -lntp | grep ':8000' || true
If installation failed or the dashboard does not load, inspect all containers:
Then inspect relevant logs using the actual container names returned by Docker, for example:
sudo docker logs --tail=200 coolify 2>/dev/null || true
Coolify's troubleshooting documentation notes that an occupied TCP 8000 can cause installation problems, so re-check that port if the initial web UI is unavailable.
Verify: Coolify control-plane containers should remain running rather than restart-looping, and the initial dashboard should answer at the URL printed by the installer.
Open the initial registration page:
http://your_server_ip:8000
Create the first administrator account immediately. Coolify's installation documentation explicitly warns that if another person reaches the registration page before you, they may create the first account and gain control of the server.
Use:
- a unique administrator email;
- a long password stored in a password manager;
- an administrator identity that is not shared between multiple people;
- a documented recovery path outside the VM.
Sign out and back in before changing network access so you know the administrator credentials work.
Verify: The first admin account should exist, login should succeed in a fresh browser session, and the public registration flow should no longer offer unrestricted first-user creation.
Step 7 — Configure a custom dashboard domain and HTTPS
Create a DNS record such as:
coolify.example.com -> your_server_ip
Use an A record for IPv4. Add an AAAA record only when IPv6 really reaches this VM and is protected consistently.
Check DNS from another network when possible:
dig +short A coolify.example.com
dig +short AAAA coolify.example.com
In Coolify's instance settings, configure the dashboard URL:
https://coolify.example.com
Coolify's integrated proxy then handles routing and TLS for the hostname.
Verify HTTPS externally:
curl -I https://coolify.example.com
Do not close the direct setup ports until the custom hostname is proven from a separate browser/network path and you retain SSH/recovery access.
Verify: The dashboard should load over the custom HTTPS hostname with a trusted certificate, and administrator login should work through that hostname.
Step 8 — Close direct dashboard, realtime, and terminal ports after the custom domain works
Current Coolify firewall guidance states that when you use a custom domain through the integrated proxy, you can safely close direct-access ports 8000, 6001, and 6002.
Remove the broad UFW rules you added for initial setup:
sudo ufw delete allow 8000/tcp
sudo ufw delete allow 6001/tcp
sudo ufw delete allow 6002/tcp
Review the final rules:
Keep:
- the real SSH administration path;
- 80/tcp when required for HTTP/certificate handling;
- 443/tcp for HTTPS applications and the Coolify dashboard.
If you deliberately need direct IP dashboard or web-terminal access, restrict the relevant port to a trusted source instead of leaving it open to Anywhere.
Remember that Docker can publish application ports outside ordinary UFW expectations. Audit deployed application bindings with:
sudo docker ps --format 'table {{.Names}}\t{{.Ports}}'
Verify: The custom HTTPS dashboard should continue working after 8000/6001/6002 are closed, SSH should remain available, and no application should expose an unintended host port.
Step 9 — Create a project and deploy an application through the proxy
In Coolify:
- Create a Project.
- Create or select an Environment.
- Add an Application.
- Choose a public repository, connected Git provider, Docker image, or another supported source.
- Set the branch/build method.
- Add required environment variables through Coolify.
- Configure the application's internal listening port.
For private repositories, grant the minimum repository access required by the integration. Remove stale source integrations when repositories or team ownership changes.
Do not commit production secrets into Git merely because Coolify can deploy from the repository. Application credentials belong in protected environment/secret configuration and should have an owner and rotation process.
Verify: Coolify should detect/build the source successfully, required variables should be configured outside the repository, and the deployed container should reach a healthy/running state.
Step 10 — Attach an application domain and verify the deployment end to end
Create another DNS record:
app.example.com -> your_server_ip
Configure that domain on the application in Coolify and route it through the platform proxy.
Prefer domain-based proxy routing over manually publishing random host ports. Direct host-port publication increases attack surface and can bypass assumptions in your host firewall design.
Test from outside the server:
curl -I https://app.example.com
Inspect containers and host utilization:
sudo docker ps
sudo docker stats --no-stream
free -h
df -h /
There is no reliable fixed number of apps a Coolify VM can host. Capacity depends on application memory, build load, databases, background workers, traffic, image/cache growth, and the overlap between deployments.
Verify: The application should respond through its HTTPS domain, there should be no unintended public database/admin ports, and CPU/memory/disk should retain enough headroom for future deployments.
A Coolify instance backup protects Coolify's own database: projects, resources, settings, credentials metadata, and deployment history. It does not back up data inside your applications, databases, or persistent volumes.
Open Settings → Backup in Coolify. Configure the instance backup if it is not already enabled, then trigger Backup Now.
Current documentation supports local backup storage and S3-compatible copies. Do not leave the only usable backup on the same VM.
Coolify encrypts stored secrets using APP_KEY, which is not part of the database backup. Save it separately:
sudo grep '^APP_KEY=' /data/coolify/source/.env
Store the complete value in a password manager or another protected location outside the VM. Do not paste it into tickets, chat, screenshots, or public documentation.
Also preserve the Coolify management keys on replacement-server migrations:
sudo find /data/coolify/ssh/keys -maxdepth 1 -type f -ls
Raff Object Storage can be used as an off-server destination where Coolify's S3-compatible backup configuration is suitable.
Verify: The instance backup execution should report success, at least one copy should exist outside the Coolify VM, and the APP_KEY should be stored securely and separately from the backup file.
Step 12 — Back up application databases and persistent data separately
Coolify instance backups do not contain your workload data.
For supported database resources, current Coolify backup tooling can schedule engine-aware backups for PostgreSQL, MySQL, MariaDB, MongoDB, and ClickHouse and optionally copy them to S3-compatible storage.
Create a separate plan for every stateful resource:
- relational/document databases: scheduled database-aware backups;
- uploaded files: filesystem/volume backups;
- object storage: provider-specific backup/replication policy;
- Redis/Dragonfly/KeyDB: their own persistence/backup method rather than assuming Coolify's scheduled database-backup workflow supports them;
- external SaaS/managed databases: the external provider's recovery procedure.
A successful backup file is not a restore test. Periodically restore a copy into a disposable environment and verify the application can read it.
Raff Data Protection can add VM-level recovery, but do not rely on a VM recovery point as the only consistency mechanism for active databases.
Verify: Every stateful workload should have a documented backup owner, schedule, off-server copy, retention policy, and at least one tested restore path.
Step 13 — Update Coolify through the stable channel with a recovery point first
Before updating Coolify:
- Create a successful Coolify instance backup.
- Confirm the separate
APP_KEY copy is accessible.
- Back up stateful application data.
- Check free storage for replacement images and build cache.
- Read the release notes/changelog for the target stable update.
Coolify can update from the dashboard. The documented stable installer can also be re-run to update to the version currently made available through Coolify's CDN:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
Do not assume the newest GitHub release is immediately the recommended CDN release. Coolify's release documentation states that CDN promotion may be delayed for testing and hotfixes.
After an update, verify the control plane and workloads:
sudo docker ps
sudo docker stats --no-stream
curl -I https://coolify.example.com
curl -I https://app.example.com
Review a representative deployment path before declaring the upgrade complete.
Verify: The dashboard should load, administrator login should work, proxy/TLS should function, existing applications should remain healthy, and at least one test deployment should complete successfully.
Step 14 — Run the final security, capacity, and recovery audit
Audit listening ports:
Audit Docker publications:
sudo docker ps --format 'table {{.Names}}\t{{.Ports}}'
Audit UFW if you use it:
Audit resource headroom:
free -h
df -h /
sudo docker system df
Confirm:
- the custom Coolify dashboard uses HTTPS;
- 8000/6001/6002 are not broadly public unless intentionally required;
- SSH access remains restricted and recoverable;
- public application traffic uses expected proxy routes;
- databases/admin interfaces are not exposed without an explicit design;
- Coolify's instance backup exists outside the VM;
- the matching
APP_KEY is stored safely;
- application databases and volumes have separate backups;
- at least one restore has been tested;
- sufficient CPU, RAM, and disk headroom remains for builds and updates.
A single Coolify server is still a single failure domain for its control plane and any workloads placed on it. Adding remote deployment servers can distribute workloads, but each stateful component still needs its own availability and recovery design.
Verify: There should be no unexplained listener, public Docker port, missing off-server backup, lost encryption key, or capacity condition that would make the next deployment/update unsafe.
Troubleshooting
The installer finishes but port 8000 does not respond
Check whether another service occupied the port or Coolify is restart-looping:
sudo ss -tulpn | grep ':8000' || true
sudo docker ps -a
Then inspect the actual Coolify container logs:
sudo docker logs --tail=200 coolify 2>/dev/null || true
The custom dashboard domain returns a certificate or proxy error
Check DNS and public ports:
dig +short A coolify.example.com
dig +short AAAA coolify.example.com
sudo ss -lntp | grep -E ':(80|443)\b' || true
sudo ufw status numbered
An incorrect AAAA record can break IPv6 clients even when IPv4 works.
The dashboard works on 8000 but realtime updates or the web terminal fail
When using direct IP access, current Coolify firewall guidance also requires 6001 for realtime communication and 6002 for web-terminal access. If you have already moved the dashboard behind a custom domain/proxy, use that architecture and close the direct ports instead of leaving all three public indefinitely.
UFW says a Docker application port is blocked but it is still reachable
Docker's own NAT/firewall rules can bypass ordinary UFW host INPUT assumptions. Check Docker publications:
sudo docker ps --format 'table {{.Names}}\t{{.Ports}}'
Prefer routing public web applications through Coolify's proxy and avoid unnecessary direct host-port publishing.
A Coolify instance backup succeeds but restore cannot decrypt credentials
The database backup is not enough by itself. You need the matching APP_KEY from /data/coolify/source/.env. Without it, encrypted stored credentials cannot be recovered correctly.
The new Coolify version is on GitHub but the dashboard does not offer it
That can be expected. Coolify's release process intentionally separates GitHub release publication from CDN promotion. Wait for the stable CDN channel unless you have a tested reason to force a specific version.
Conclusion
You now have a current Coolify deployment workflow for Ubuntu 24.04: supported resource checks, the official installer, immediate administrator registration, correct direct-access firewall ports, a custom HTTPS dashboard domain, reduced exposure after proxy setup, an application deployment path, separate instance/workload backups, and a controlled stable-channel update process.
The most important operational distinction is between the Coolify control plane and the workloads Coolify manages. Backing up Coolify does not back up application databases or volumes, and securing port 8000 does not automatically secure Docker-published application ports. Treat the control plane, Docker networking, every stateful service, and recovery credentials as separate layers that must all be verified.
For adjacent procedures, use Install Docker on Ubuntu 24.04, Set Up UFW Firewall, and Harden Ubuntu 24.04.
Sources
