Securing Your Coolify Instance After the January 2026 Disclosure

If you're running Coolify to manage your servers, stop what you're doing and read this. In January 2026, multiple critical vulnerabilities were publicly disclosed affecting Coolify instances. These aren't minor issues. We're talking about authentication bypasses, command injection, privilege escalation, and more — in a tool that has root-level access to your entire infrastructure.

I run Coolify in production. My own site sits on it. I built the Coolify MCP server to manage my infrastructure from Claude Code. So when these CVEs dropped, I took it personally. This guide is what I did to lock down my own instance, and what you should do too.

What Was Disclosed

In January 2026, security researchers disclosed a collection of critical CVEs affecting Coolify. The vulnerabilities span several categories:

• Server-Side Request Forgery (SSRF) — Attackers could make the Coolify server send requests to internal services, potentially accessing metadata endpoints, internal APIs, or other resources that should never be reachable from the outside.
• Authentication Bypass — Certain endpoints could be accessed without proper authentication, meaning an attacker didn't need valid credentials to interact with parts of the Coolify API.
• Privilege Escalation — Lower-privileged users could elevate their access to admin-level permissions, gaining full control over the Coolify instance.
• Command Injection — Attacker-controlled input could be executed as shell commands on the Coolify server. Given that Coolify runs with elevated privileges, this is about as bad as it gets.
• Information Disclosure — Sensitive data including internal configuration, environment variables, and server details could be leaked to unauthorized parties.
• Path Traversal — Attackers could read files outside of intended directories on the Coolify server, potentially accessing credentials, private keys, or other sensitive files.

Here's why this is worse than a typical web application vulnerability: Coolify isn't a blog or a SaaS app. It's your server management platform. It holds SSH keys to your servers. It stores database credentials, API tokens, and environment variables for every application you manage. It can deploy code, restart services, and execute commands on your infrastructure. A compromised Coolify instance means a compromised everything.

Step 1: Check Your Coolify Version

Before anything else, find out what version you're running. You can check this in two ways.

From the Coolify UI:

Go to Settings in your Coolify dashboard. The version number is displayed at the bottom of the page.

From the command line:

SSH into your Coolify server and run:

cd /data/coolify/source
docker compose exec coolify php artisan about

This will output detailed application information including the version number.

Alternatively, check the running container image version:

docker ps --filter "name=coolify" --format "{{.Image}}"

If you're running a version from before the January 2026 patches, you are affected. Coolify's GitHub releases page will list which versions contain the security fixes — look for release notes mentioning CVE patches. As a general rule, if you haven't updated since before the disclosure, assume you're vulnerable.

Step 2: Update Coolify Immediately

Do not pass go. Do not finish your current feature. Update now.

Back up your database first:

cp /data/coolify/source/.env /data/coolify/source/.env.backup
docker compose -f /data/coolify/source/docker-compose.yml exec postgres pg_dumpall -U coolify > ~/coolify-db-backup-$(date +%Y%m%d).sql

Using Coolify's built-in updater:

Coolify has an auto-update feature. Go to Settings > Update in the UI and trigger an update. If auto-updates are enabled, your instance may have already updated — but verify the version number after the process completes.

Manual update if the auto-updater isn't working:

cd /data/coolify/source
docker compose pull
docker compose up -d --remove-orphans
docker image prune -f

If you're significantly behind on versions:

Sometimes jumping multiple major versions can cause migration issues. Check the Coolify documentation for upgrade guides between specific versions. In extreme cases, you may need to step through intermediate versions.

After updating, verify the new version:

docker compose exec coolify php artisan about

Confirm you're on a version released after the January 2026 security patches.

Step 3: Audit Your Access

Even after updating, you need to verify that your instance wasn't compromised while it was vulnerable. Patching closes the door, but if someone already walked through it, you have a different problem.

Review Coolify user accounts:

Go to Settings > Team in the Coolify UI. Check every user account. Do you recognise all of them? Is anyone there who shouldn't be? Remove any accounts you don't recognise or no longer need.

Revoke and regenerate API tokens:

Go to Settings > API Tokens. Revoke every token you don't actively recognise and need. Generate new tokens for your legitimate integrations. If you're using the Coolify MCP server or any other API integration, update the token in your configuration after regenerating.

Check for unauthorized SSH keys:

On every server managed by Coolify, check the authorized keys:

cat ~/.ssh/authorized_keys
cat /root/.ssh/authorized_keys

Look for keys you don't recognise. If you see anything unfamiliar, remove it immediately and investigate further.

Review recent deployment logs:

In the Coolify UI, go through recent deployments for each application. Look for deployments you didn't trigger. Check the git source and commit hashes — do they match what you'd expect?

Check for unexpected cron jobs:

On your Coolify server and managed servers:

crontab -l
ls -la /etc/cron.d/
ls -la /etc/cron.daily/

Attackers often install persistence through cron jobs.

Step 4: Harden Your Coolify Instance

Updating fixes the known vulnerabilities. Hardening protects you against the next ones.

Put Coolify behind a reverse proxy with IP allowlisting:

Coolify's default port is 8000. It should never be exposed directly to the public internet. Use a reverse proxy like Caddy or Nginx in front of it, and restrict access to known IP addresses.

Example with Caddy:

coolify.yourdomain.com {
    @blocked not remote_ip 203.0.113.10 198.51.100.0/24
    respond @blocked 403

    reverse_proxy localhost:8000
}

Use a zero-trust solution:

Cloudflare Access, Tailscale, or WireGuard can put your Coolify instance behind authentication before anyone even reaches the login page. This is the single most effective hardening step you can take. Even if Coolify has another auth bypass vulnerability in the future, attackers can't reach it.

Restrict the Coolify port with a firewall:

If you're not using a reverse proxy, at minimum lock down port 8000 with UFW:

# Deny all access to Coolify port by default
sudo ufw deny 8000

# Allow only your IP
sudo ufw allow from 203.0.113.10 to any port 8000

# Verify
sudo ufw status

Or with iptables:

# Drop all traffic to port 8000
sudo iptables -A INPUT -p tcp --dport 8000 -j DROP

# Allow your IP
sudo iptables -I INPUT -p tcp -s 203.0.113.10 --dport 8000 -j ACCEPT

Enable two-factor authentication:

In Coolify, enable 2FA on every user account. Go to your profile settings and set up TOTP-based 2FA. This applies to all accounts, not just yours — enforce it for every team member.

Keep auto-updates enabled:

In Settings, make sure auto-updates are turned on. Security patches need to land as fast as possible. The window between disclosure and patch is when you're most at risk.

Monitor Coolify's GitHub releases:

Star and watch the coolify/coolify repository on GitHub. Set your watch settings to "Releases only" at minimum. This way you'll get notified when security patches ship.

Step 5: Harden Your Managed Servers

Coolify manages your servers, but those servers need their own security posture. A compromised Coolify instance could have been used to tamper with any of them.

Audit SSH keys on all managed servers:

# Check all user accounts for authorized keys
for user in $(cut -f1 -d: /etc/passwd); do
    keyfile="/home/$user/.ssh/authorized_keys"
    if [ -f "$keyfile" ]; then
        echo "=== $user ==="
        cat "$keyfile"
    fi
done

# Don't forget root
cat /root/.ssh/authorized_keys

Remove any keys you don't recognise. Coolify adds its own keys to managed servers — those are expected. Anything else should be investigated.

Lock down firewall rules:

Only open the ports you actually need. A typical web server needs 22 (SSH), 80 (HTTP), and 443 (HTTPS). Everything else should be closed:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

If you access SSH from a fixed IP, restrict that too:

sudo ufw delete allow 22/tcp
sudo ufw allow from 203.0.113.10 to any port 22

Keep your OS updated:

# Ubuntu/Debian
sudo apt update && sudo apt upgrade -y

# Enable automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Scan Docker images:

If you're deploying Docker containers, scan them for known vulnerabilities:

# Using Docker Scout (built into Docker Desktop and CLI)
docker scout cves your-image:latest

# Or using Trivy
trivy image your-image:latest

Make this part of your deployment pipeline, not a one-off exercise.

Ongoing Security Practices

Patching and hardening are not one-time events. Self-hosting means self-securing, and that's a continuous responsibility.

Subscribe to security advisories. Watch Coolify's GitHub repository for releases. Follow the Coolify Discord for community reports. Set up alerts so you know about vulnerabilities before attackers exploit them.

Never expose Coolify to the raw internet. Port 8000 should not be accessible without authentication at the network level. Use Cloudflare Access, Tailscale, a VPN, or at minimum IP-restricted firewall rules. The login page is not a sufficient security boundary.

Back up regularly and store backups off-server. Your Coolify database contains everything — server credentials, application configs, environment variables. Back it up regularly and store copies somewhere that isn't on the same server:

# Dump and copy off-server
docker compose -f /data/coolify/source/docker-compose.yml exec postgres pg_dumpall -U coolify > ~/coolify-backup-$(date +%Y%m%d).sql
scp ~/coolify-backup-$(date +%Y%m%d).sql backup-server:/backups/coolify/

Consider running Coolify on a dedicated management server. Don't co-locate Coolify with your application workloads. If Coolify is on the same server as your apps and it gets compromised, the attacker has direct local access to everything. A separate management server adds a meaningful layer of isolation.

Rotate credentials periodically. API tokens, SSH keys, database passwords — rotate them on a schedule. Don't wait for a breach to force it.

The Responsibility Is Yours

This is the trade-off of self-hosting. You get control, flexibility, and independence from third-party platforms. In return, you take on the responsibility of security. No one is going to patch your servers for you. No security team is monitoring your Coolify instance at 2am.

The January 2026 disclosure was a wake-up call for the Coolify community. The maintainers responded quickly with patches, and the project is better for having gone through this process. But the ball is in your court now. Check your version, update, audit, and harden. Do it today, not next week.

Your infrastructure is only as secure as the tool that manages it.