Latest News And Updates - Rad Web Hosting Blog

Learn How to Deploy Coolify on Ubuntu VPS! 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: Ubuntu 20.04 LTS Ubuntu 22.04 LTS Ubuntu 24.04 LTS Non-LTS Ubuntu releases require the manual installation process. 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/hosts if 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 A record 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 AAAA record 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 To create a 4 GB swap file: 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.swappiness10 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 -a to 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 | 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_ENVproduction APP_URLhttps://app.example.com DATABASE_URLpostgresql://... REDIS_URLredis://... 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 healthunhealthy 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_keys file. 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.

Rad Web Hosting Blog

Recent Posts

Nothing Found

My Feed at https://radwebhosting.com

Services

Categories

Recent Posts

Save on VPS Hosting!

We’re Social!

Rad Web Hosting Blog