This article provides a guide demonstrating how to deploy Coolify on Ubuntu VPS.
What is Coolify?
Coolify is an open-source, self-hosted Platform as a Service, or PaaS, that provides an interface for deploying and managing websites, applications, databases, and Docker-based services. It offers functionality similar to platforms such as Heroku, Railway, Netlify, and Vercel while allowing you to retain control of the underlying server.
Coolify supports deployments from Git repositories, Docker images, Docker Compose files, and numerous preconfigured service templates. It also includes automatic HTTPS certificates, reverse proxy management, environment variables, deployment logs, database backups, and integration with services such as GitHub.
This guide explains how to deploy Coolify on Ubuntu VPS, configure DNS and firewall access, secure the management interface, deploy a test application, and establish basic backup and maintenance procedures.
Deployment Overview
The completed environment will use the following basic architecture:
Internet
|
| TCP 80 and 443
v
Ubuntu VPS
|
+-- Coolify dashboard
|
+-- Traefik or Caddy reverse proxy
|
+-- Docker containers
|
+-- Web applications
+-- Databases
+-- Background services
Coolify runs its own components as Docker containers. Applications deployed through Coolify are also normally placed in containers and connected to the integrated reverse proxy.
For this example, assume the following values:
Server IP: 203.0.113.10 Server hostname: coolify.example.com Dashboard domain: coolify.example.com Operating system: Ubuntu 24.04 LTS SSH user: root
Replace these example values with your actual server IP address and domain.
Prerequisites
You will need:
- A fresh Ubuntu VPS
- Root or sudo access
- A public IPv4 or IPv6 address
- A domain name or subdomain
- Access to the domain’s DNS records
- At least 2 CPU cores
- At least 2 GB of RAM
- At least 30 GB of available storage
- TCP ports 22, 80, and 443 available
Coolify’s current documented minimum is 2 CPU cores, 2 GB of RAM, and 30 GB of free storage. However, those resources include both the control plane and any applications built on the server. A production system that performs Docker builds locally will generally benefit from at least 4 GB of RAM, 4 CPU cores, and substantially more storage.
A practical small-production configuration is:
CPU: 4 vCPU RAM: 8 GB Storage: 100 GB SSD or NVMe OS: Ubuntu 24.04 LTS
Use a fresh VPS whenever possible. Existing web servers, control panels, Docker installations, or services listening on ports 80 and 443 can conflict with Coolify’s reverse proxy.
Supported Ubuntu versions
The automatic installation script currently supports these Ubuntu LTS releases:
Non-LTS Ubuntu releases require the manual installation process.
Compare Ubuntu VPS Plans
How to Deploy Coolify on Ubuntu VPS
To deploy Coolify on Ubuntu VPS, follow the steps outlined below:
-
Create the VPS
Provision a VPS with Ubuntu 24.04 LTS.
During provisioning:
- Assign a static public IP address.
- Add your SSH public key.
- Set the hostname to a fully qualified domain name
- Avoid installing a web hosting control panel.
- Do not preinstall Apache, Nginx, or Docker through Snap.
Coolify explicitly does not support Docker installed through Snap. Its installer can install and configure a supported Docker Engine version automatically.
Connect to the server:
ssh root@203.0.113.10
Confirm the operating system:
cat /etc/os-release
You should see output containing:
NAME="Ubuntu" VERSION="24.04 LTS (Noble Numbat)"
Check the architecture:
uname -m
Supported architectures include:
x86_64 aarch64
Coolify supports AMD64 and ARM64 systems.
-
Configure the hostname
Set the server hostname:
hostnamectl set-hostname coolify.example.com
Confirm it:
hostnamectl hostname -f
Add the hostname to
/etc/hostsif necessary:nano /etc/hosts
Use an entry similar to:
127.0.0.1 localhost 203.0.113.10 coolify.example.com coolify
Do not remove the existing IPv6 localhost entries.
-
Update Ubuntu
Update the package index and install available upgrades:
apt update apt full-upgrade -y
Install several useful administration packages:
apt install -y \ curl \ wget \ git \ jq \ unzip \ ca-certificates \ gnupg \ lsb-release \ openssh-server \ ufw
Enable SSH:
systemctl enable --now ssh
Verify that it is running:
systemctl status ssh --no-pager
Reboot if the upgrade installed a new kernel:
reboot
Reconnect after the server starts:
ssh root@203.0.113.10
-
Configure DNS
Create an
Arecord for the Coolify dashboard:Type: A Name: coolify Value: 203.0.113.10 TTL: 300
This creates:
coolify.example.com
When IPv6 is configured, create an
AAAArecord as well.Verify DNS resolution:
dig +short coolify.example.com
or:
getent ahosts coolify.example.com
The returned address should match your VPS.
Optional wildcard DNS
A wildcard record is useful when multiple applications will be deployed under the same parent domain:
Type: A Name: *.apps Value: 203.0.113.10 TTL: 300
This allows application domains such as:
api.apps.example.com status.apps.example.com store.apps.example.com
You can also assign independent domains to each application without using a wildcard.
Do not proceed with HTTPS configuration until the relevant DNS record resolves to the server.
-
Secure SSH access
Coolify uses SSH internally, including when managing the local server on which Coolify itself is installed. The installation process is currently designed primarily around root access. Coolify’s SSH key must not require a passphrase or interactive two-factor authentication.
Before disabling password authentication, verify that key-based login works in a second terminal window.
Create the SSH directory if needed:
mkdir -p /root/.ssh chmod 700 /root/.ssh touch /root/.ssh/authorized_keys chmod 600 /root/.ssh/authorized_keys
Review the SSH configuration:
nano /etc/ssh/sshd_config
Use settings such as:
PubkeyAuthentication yes PermitRootLogin prohibit-password PasswordAuthentication no KbdInteractiveAuthentication no PermitEmptyPasswords no X11Forwarding no
Validate the configuration:
sshd -t
If no errors appear, restart SSH:
systemctl restart ssh
Keep the original SSH session open until you have successfully connected in another terminal.
-
Configure the provider firewall
The safest approach is to use the network firewall supplied by the VPS provider.
Initially allow:
Port Protocol Purpose 22 TCP SSH administration 80 TCP HTTP and certificate validation 443 TCP HTTPS applications and dashboard 8000 TCP Initial Coolify dashboard 6001 TCP Real-time dashboard communication 6002 TCP Coolify terminal access Coolify documents ports 8000, 6001, and 6002 for direct self-hosted dashboard access, in addition to SSH, HTTP, and HTTPS. Once the dashboard is accessible through its configured domain and integrated reverse proxy, ports 8000, 6001, and 6002 can normally be closed from the public Internet.
For the initial installation, restrict ports 8000, 6001, and 6002 to your own public IP address whenever the provider firewall supports source restrictions.
Example:
22/tcp Allow from administrator IP only 80/tcp Allow from anywhere 443/tcp Allow from anywhere 8000/tcp Allow from administrator IP only 6001/tcp Allow from administrator IP only 6002/tcp Allow from administrator IP only
Important Docker firewall behavior
Docker creates NAT and iptables rules that may bypass ordinary UFW filtering. Therefore, a service published by Docker can remain reachable even when a UFW rule appears to block it. Coolify recommends using the VPS provider’s external firewall when available.
UFW can still protect SSH and non-Docker services, but it should not be treated as the only control for published Docker ports.
-
Configure UFW carefully
Allow SSH before enabling UFW:
ufw allow OpenSSH
If you use a custom SSH port, substitute that port:
ufw allow 2222/tcp
Allow HTTP and HTTPS:
ufw allow 80/tcp ufw allow 443/tcp
Temporarily allow initial Coolify access:
ufw allow 8000/tcp ufw allow 6001/tcp ufw allow 6002/tcp
Set default policies:
ufw default deny incoming ufw default allow outgoing
Enable the firewall:
ufw enable
Check the result:
ufw status verbose
Ubuntu uses UFW as its standard host firewall frontend, but Docker networking requires additional consideration because container-published ports are controlled through Docker’s own firewall chains.
-
Check for conflicting services
Before installing Coolify, determine whether anything is already listening on required ports:
ss -tulpn | grep -E ':(22|80|443|6001|6002|8000)\b'
Port 22 should normally be occupied by SSH.
Ports 80, 443, 6001, 6002, and 8000 should generally be available on a new server.
Check for existing web servers:
systemctl status apache2 --no-pager 2>/dev/null systemctl status nginx --no-pager 2>/dev/null systemctl status caddy --no-pager 2>/dev/null
If an unintended web server is installed, stop and remove it before proceeding. For example:
systemctl disable --now apache2 apt purge -y apache2 apache2-bin apache2-data apache2-utils apt autoremove -y
Do not run that command if Apache is intentionally hosting something you need.
Check whether Docker came from Snap:
snap list docker 2>/dev/null
If Docker appears in the output, remove the Snap package:
snap remove docker
-
Optional: configure swap
A small VPS can become unresponsive during Docker image builds. Swap does not replace adequate RAM, but it can reduce the risk of an abrupt out-of-memory failure.
Check existing swap:
swapon --show free -h
fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile
Make it persistent:
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Set a conservative swappiness value:
cat >/etc/sysctl.d/99-coolify-swap.conf <<'EOF' vm.swappiness=10 EOF
Apply it:
sysctl --system
Confirm:
swapon --show
-
Review the installation script
The recommended installer is downloaded from Coolify’s CDN.
For security-conscious environments, download and inspect it before execution:
curl -fsSL \ https://cdn.coollabs.io/coolify/install.sh \ -o /root/coolify-install.sh
Review the file:
less /root/coolify-install.sh
Optionally calculate a local checksum for your deployment records:
sha256sum /root/coolify-install.sh
The script is updated over time, so record the installation date and checksum if your organization requires change tracking.
-
Install Coolify
Run the downloaded installer:
bash /root/coolify-install.sh
Alternatively, the official one-line command is:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
When running from a non-root account:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
The official installer performs several tasks, including:
- Installing required utilities
- Installing Docker Engine
- Configuring Docker
- Creating
/data/coolify - Creating SSH keys used by Coolify
- Downloading Coolify configuration
- Starting the Coolify containers
The installation directory is:
/data/coolify
The installer currently expects Docker Engine 24 or newer and will install Docker when necessary.
-
Confirm that Coolify is running
At the end of installation, the script should display a URL similar to:
http://203.0.113.10:8000
Check Docker:
docker version docker compose version docker info
List running containers:
docker ps
You should see multiple Coolify-related containers.
Check the listening ports:
ss -tulpn | grep -E ':(80|443|6001|6002|8000)\b'
Review container status in a compact format:
docker ps \ --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'If the dashboard does not respond, inspect the containers:
docker ps -a
Review recent logs:
docker logs --tail 100 coolify
Container names can change between releases. Use
docker ps -ato identify the correct name before requesting logs. -
Create the first administrator account immediately
Open the initial URL:
http://203.0.113.10:8000
Create coolify root account You should be redirected to the account registration page.
Create the first administrator account immediately. Until the initial account is registered, another person who reaches the registration page could potentially create the first administrator and gain control of the instance. Coolify specifically warns administrators not to leave this registration page unattended.
Use:
- A dedicated administrative email address
- A unique password
- A password manager
- Multi-factor authentication after initial setup
Do not reuse a password from your VPS provider, domain registrar, or Git provider.
-
Validate the local server
After logging in, open the server configuration for
localhost.The exact menu names can shift between Coolify versions, but the general path is:
Servers → localhost → General
Click the validation or server-check action.
Confirm that the interface reports that:
- The server is reachable
- Docker is available
- The proxy is running
- Disk and CPU information can be retrieved
Coolify uses SSH even when it manages the local host, so SSH configuration problems can cause local server validation to fail.
If validation fails, check:
systemctl status ssh --no-pager ss -lntp | grep ':22' docker ps
Also inspect the root authorized keys:
ls -la /root/.ssh cat /root/.ssh/authorized_keys
Do not publish or paste private key contents into tickets or public forums.
-
Assign a domain to the Coolify dashboard
Configure the instance domain in Coolify’s settings.
Use:
https://coolify.example.com
Make sure the DNS record already points to the server.
Coolify’s integrated proxy should create the corresponding route and request a TLS certificate. Ports 80 and 443 must remain publicly reachable for ordinary HTTP-based certificate issuance and application traffic.
After saving the domain, browse to:
https://coolify.example.com
Verify the certificate:
curl -I https://coolify.example.com
You can also inspect the certificate from the command line:
openssl s_client \ -connect coolify.example.com:443 \ -servername coolify.example.com \ </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates
Once the domain works correctly, stop using the direct port-8000 URL.
-
Close the temporary dashboard ports
After confirming that the dashboard, real-time updates, and terminal features all work through the HTTPS domain, remove public access to:
- 8000
- 6001
- 6002
Remove the corresponding rules from the VPS provider firewall first.
Then remove the UFW rules:
ufw delete allow 8000/tcp ufw delete allow 6001/tcp ufw delete allow 6002/tcp
Check the final UFW configuration:
ufw status numbered
The publicly required application ports should normally be:
22/tcp 80/tcp 443/tcp
Restrict SSH to trusted addresses when operationally possible.
Remember that UFW alone may not block Docker-published ports. Confirm the result from a different system:
nmap -Pn -p 22,80,443,6001,6002,8000 203.0.113.10
The expected externally reachable ports are generally 22, 80, and 443.
-
Enable multi-factor authentication
Open the user or security settings in the Coolify dashboard and enable two-factor authentication.
Store the recovery codes in a secure password manager or encrypted administrative vault.
Before relying on two-factor authentication:
- Confirm that the authenticator code works.
- Save the recovery codes.
- Ensure that more than one trusted administrator can recover the platform.
- Document the server-side recovery procedure internally.
Do not store recovery codes only on an application running inside the same Coolify instance.
-
Connect a Git provider
Coolify can deploy from public or private repositories.
Depending on your deployment method, you can use:
- GitHub App integration
- GitLab integration
- Deploy keys
- Public repository URLs
- Direct Docker images
- Docker Compose definitions
For GitHub integration, follow the integration wizard in Coolify and authorize only the repositories Coolify needs.
For a private repository using an SSH deploy key:
- Create a new application.
- Select the private repository source.
- Copy the public key supplied by Coolify.
- Add it as a read-only deploy key in the repository.
- Validate repository access.
- Select the branch to deploy.
Do not place a personal Git access token directly in application environment variables unless the deployment method specifically requires it.
Git webhooks normally require inbound HTTP or HTTPS access, so ports 80 and 443 must remain reachable.
-
Deploy a test application
Before deploying a production workload, test the platform with a small application.
Method A: deploy from a public Git repository
Add new resource In Coolify:
- Open Projects.
- Create a new project.
- Create a production environment.
- Choose New Resource.
- Select Public Repository.
- Enter the Git repository URL.
- Select the branch.
- Allow Coolify to detect the build system.
- Enter the application’s internal listening port.
- Assign a domain.
- Click Deploy.
For example:
Repository: https://github.com/example/hello-node.git Branch: main Port: 3000 Domain: hello.example.com
Create the DNS record before assigning the domain:
Type: A Name: hello Value: 203.0.113.10
Watch the deployment log. A successful deployment generally includes:
- Repository checkout
- Dependency installation
- Image build
- Container creation
- Health check
- Proxy route creation
- Certificate issuance
Method B: deploy a Docker image
You can also deploy a public image such as Nginx.
Create a Docker image resource using:
nginx:alpine
Configure its internal port as:
80
Assign:
nginx-test.example.com
After deployment:
curl -I https://nginx-test.example.com
Remove the test application after validating the platform.
-
Configure environment variables
Applications commonly require values such as:
APP_ENV=production APP_URL=https://app.example.com DATABASE_URL=postgresql://... REDIS_URL=redis://... API_KEY=...
Add these in the application’s environment-variable section rather than committing secrets to the Git repository.
Classify values appropriately:
- Build-time variables
- Runtime variables
- Public frontend variables
- Secret server-side variables
Be careful with frameworks that expose variables with prefixes such as:
NEXT_PUBLIC_ VITE_ PUBLIC_ REACT_APP_
Variables intended for frontend builds may be embedded into downloadable JavaScript and should never contain secrets.
Redeploy the application when a changed environment variable must be included during the build process.
-
Configure persistent storage
Containers are disposable. Any data written only to a container’s writable layer can be lost when it is rebuilt or replaced.
Use persistent storage for:
- User uploads
- Database files
- Generated media
- Application configuration that changes at runtime
- Queue or state data that must survive redeployment
Example mount:
Source volume: app-uploads Container path: /app/storage/uploads
Before adding storage, verify the exact path expected by the application.
Do not mount arbitrary host directories unless you understand the permissions and security effects. Prefer a named Docker volume or a dedicated directory beneath a controlled storage path.
-
Deploy a database
Coolify can provision managed containers for databases such as PostgreSQL, MariaDB, MySQL, MongoDB, and Redis.
For a PostgreSQL deployment:
- Open the project.
- Select New Resource.
- Choose PostgreSQL.
- Select an appropriate supported version.
- Generate strong credentials.
- Configure persistent storage.
- Start the database.
- Copy the internal connection URL.
- Add the URL to the application’s environment variables.
- Configure scheduled backups.
Keep the database private unless external connectivity is specifically required.
Whenever possible, applications should connect to databases over the internal Docker network rather than through a publicly exposed database port.
Do not expose these ports to the Internet unless absolutely necessary:
3306 MySQL or MariaDB 5432 PostgreSQL 6379 Redis 27017 MongoDB
If external database access is required, use a VPN, SSH tunnel, private network, or strict source-IP restriction.
-
Configure health checks
A health check allows Coolify and Docker to determine whether the application is actually ready, not merely whether its container process exists.
A typical HTTP health endpoint is:
/health
It should return:
HTTP/1.1 200 OK
Example test:
curl -i https://app.example.com/health
A useful health endpoint should:
- Respond quickly
- Avoid expensive queries
- Confirm essential dependencies where appropriate
- Avoid exposing secrets or detailed debugging data
- Return a non-success status when the application cannot serve traffic
Configure the health-check path, interval, timeout, and retry count according to the application’s startup behavior.
-
Configure application backups
Backups should exist outside the Coolify server.
At minimum, protect:
- Application databases
- Persistent Docker volumes
- Uploaded files
- Important environment-variable records
- Coolify configuration and metadata
- Custom Docker Compose files
- Any private deployment keys not recoverable elsewhere
Use S3-compatible remote storage when supported by the resource.
Suitable destinations include:
- Amazon S3
- Backblaze B2 S3
- Cloudflare R2
- Wasabi
- MinIO on a separate server
- Another compatible object-storage service
Do not treat a VPS snapshot as the only backup. Snapshots can be useful for rapid recovery but may be stored in the same provider account or infrastructure as the original VPS.
A reasonable starting schedule is:
Database backup: Daily Critical database backup: Every 4–6 hours File backup: Daily Retention: 7 daily, 4 weekly, 6 monthly Restore test: Monthly or quarterly
Backup frequency should ultimately be determined by the acceptable recovery point objective.
-
Back up the Coolify control plane
Coolify stores its installation under:
/data/coolify
Inspect the directory:
du -sh /data/coolify find /data/coolify -maxdepth 2 -type d | sort
Before copying live database files directly, use Coolify’s supported backup functions or create application-consistent database dumps. A raw copy of an actively written database volume is not necessarily a reliable backup.
For an additional configuration archive, you can create a protected snapshot of nonvolatile configuration during a maintenance window:
mkdir -p /root/backups tar \ --exclude='/data/coolify/backups' \ -czf "/root/backups/coolify-data-$(date +%F-%H%M%S).tar.gz" \ /data/coolify
This archive may contain credentials and private keys. Protect it:
chmod 600 /root/backups/coolify-data-*.tar.gz
Transfer it to encrypted remote storage and define a retention policy.
Do not depend on this generic archive as a substitute for tested database-specific backups.
-
Configure update behavior
Self-hosted Coolify checks for new versions and service-template changes. Automatic updates are enabled by default, with the default automatic update schedule occurring daily at midnight. Coolify’s documentation recommends considering disabling unattended automatic updates for production systems so changes can be applied during a controlled maintenance period.
For a production instance:
- Open Settings.
- Locate the update section.
- Leave update checks enabled.
- Consider disabling automatic installation.
- Review release notes.
- Confirm backups.
- Apply updates during a maintenance window.
- Test the dashboard and important applications afterward.
For a manual upgrade from the server, the official installation script is also used to retrieve and apply the current Coolify version:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
The upgrade mechanism checks Coolify’s distribution source and updates the instance.
Before updating:
docker ps df -h free -h
After updating:
docker ps docker ps --filter health=unhealthy curl -I https://coolify.example.com
-
Configure automatic Ubuntu security updates
Install the unattended-upgrades package:
apt install -y unattended-upgrades
Enable it:
dpkg-reconfigure -plow unattended-upgrades
Check the configuration:
cat /etc/apt/apt.conf.d/20auto-upgrades
A typical configuration contains:
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";
Test the process:
unattended-upgrade --dry-run --debug
Kernel and container-runtime updates may require a reboot. Plan controlled reboots rather than allowing the server to run indefinitely without loading security-fixed kernels.
Check whether a reboot is required:
test -f /var/run/reboot-required && cat /var/run/reboot-required
-
Monitor server resources
Check basic resource usage regularly:
uptime free -h df -h df -i docker stats --no-stream
Check Docker disk consumption:
docker system df
List large Docker directories:
du -xh /var/lib/docker 2>/dev/null | sort -h | tail -n 20
List large Coolify directories:
du -xh /data/coolify | sort -h | tail -n 20
Build cache and unused images can consume substantial storage.
Do not run destructive cleanup commands indiscriminately. For example:
docker system prune -a
can remove images and build cache that may be useful or expected. Use Coolify’s cleanup functions or carefully inspect the objects before deletion.
-
Configure external monitoring
Do not monitor Coolify solely from an application hosted on the same server.
Use an external monitoring service to check:
https://coolify.example.com https://app1.example.com/health https://app2.example.com/health
Monitor at least:
- HTTP response status
- TLS certificate expiration
- DNS resolution
- Server reachability
- Disk utilization
- Memory pressure
- CPU load
- Container health
- Backup success
- Deployment failures
Configure Coolify notifications for important deployment, server, and backup events using an available notification integration.
-
Troubleshooting
Dashboard does not open on port 8000
Check whether the port is listening:
ss -lntp | grep ':8000'
Check containers:
docker ps -a
Check the provider firewall and local firewall:
ufw status verbose
Test locally:
curl -I http://127.0.0.1:8000
If the local request works but the remote request fails, the problem is likely a provider firewall, routing rule, or Docker firewall policy.
Dashboard domain returns 502 Bad Gateway
Confirm that the Coolify containers are running:
docker ps
Check the proxy container:
docker ps --format '{{.Names}}' | grep -Ei 'proxy|traefik|caddy'Inspect its logs using the name returned above:
docker logs --tail 200 CONTAINER_NAME
Verify DNS:
dig +short coolify.example.com
Confirm the domain resolves to the correct server.
SSL certificate is not issued
Check:
dig +short coolify.example.com curl -I http://coolify.example.com ss -lntp | grep -E ':(80|443)\b'
Confirm that:
- The DNS record points to the VPS.
- Port 80 is publicly reachable.
- Port 443 is publicly reachable.
- No unrelated proxy is intercepting traffic.
- A CDN proxy is not using an incompatible TLS mode.
- The certificate authority’s validation requests are not blocked.
Local server validation fails
Coolify uses SSH for local server management. Verify:
systemctl status ssh --no-pager ss -lntp | grep ':22' ls -la /root/.ssh
Check the SSH logs:
journalctl -u ssh --since '30 minutes ago'
Make sure the Coolify-generated public key is present in the appropriate
authorized_keysfile.Deployment remains stuck
Check resource usage:
free -h df -h docker stats --no-stream
Review the deployment log in the dashboard.
Common causes include:
- Insufficient RAM
- Full disk
- Inode exhaustion
- Invalid build command
- Wrong application port
- Missing environment variables
- Private repository authentication failure
- Registry rate limiting
- Failed health check
Application deploys but returns 502
The application may be listening on the wrong interface or port.
Inside a container, an application should generally listen on:
0.0.0.0
not only:
127.0.0.1
Make sure the configured Coolify port matches the internal application port.
For example, if Node.js listens on port 3000:
app.listen(3000, '0.0.0.0');
Configure Coolify’s application port as:
3000
Server becomes unresponsive during builds
Check for out-of-memory events:
journalctl -k | grep -Ei 'out of memory|oom|killed process'
Check resources:
free -h swapon --show
Possible remedies include:
- Adding RAM
- Adding swap
- Limiting concurrent builds
- Removing unnecessary services
- Using a separate build server
- Building images in an external CI system
- Deploying prebuilt images from a container registry
-
Production security checklist
Before deploying important applications, confirm the following:
- Ubuntu is fully updated.
- SSH key authentication works.
- SSH password authentication is disabled.
- SSH is restricted by source address when practical.
- The Coolify dashboard uses HTTPS.
- Ports 8000, 6001, and 6002 are no longer publicly open.
- Provider-level firewall rules are enabled.
- The first administrator account is secured.
- Multi-factor authentication is enabled.
- Application secrets are not committed to Git.
- Databases are not publicly exposed.
- Persistent storage is configured.
- Remote backups are scheduled.
- Restore procedures have been tested.
- External uptime monitoring is enabled.
- Disk and memory alerts are configured.
- Coolify updates are applied through a controlled process.
- Ubuntu security updates are enabled.
- A recovery path exists if the primary administrator loses access.
-
Final verification
Run the following checks from the server:
hostnamectl systemctl is-active ssh docker version docker compose version docker ps df -h free -h ufw status verbose
Test the dashboard:
curl -I https://coolify.example.com
Test an application:
curl -I https://app.example.com
Check the externally reachable ports from another system:
nmap -Pn -p 22,80,443,6001,6002,8000 203.0.113.10
The expected production result is generally:
22/tcp open or source-restricted 80/tcp open 443/tcp open 6001/tcp filtered or closed 6002/tcp filtered or closed 8000/tcp filtered or closed
Conclusion
You now know how to deploy Coolify on Ubuntu VPS. Your Coolify installation is now ready to host containerized applications, databases, and services on the Ubuntu VPS.
