How to change the Coolify port

The Coolify port question shows up two ways. Either you want to change the dashboard from its default port 8000 (because port 8000 is in use, because you want it on a less obvious port for security or because something else on your server is conflicting) or you want to expose your application on a non-standard port through Traefik. Different fixes, both worth knowing.

This guide covers both, plus the gotcha that locks people out of their own Coolify dashboard. Written against Coolify v4.0.0.

The default Coolify ports

By default, Coolify uses these ports on the host:

• 8000, the dashboard. HTTP, you reach it as http://your-server:8000 on first install
• 80, HTTP for application traffic, served by Traefik
• 443, HTTPS for application traffic, served by Traefik
• 6001 and 6002, internal communication for the Coolify Realtime feature (Soketi)
• 22, SSH (your own, not Coolify's)

Internal database resources you create get their own ports inside the Docker network (5432 for Postgres, 3306 for MySQL, 6379 for Redis, etc.) but those aren't exposed to the public internet by default.

The most common reason to change a Coolify port is the dashboard one. Port 8000 conflicts with other things you might run (some Python dev servers, Portainer in some configs, Plausible Analytics) and the predictable port number means automated scanners hit it first.

How to change the Coolify dashboard port

There are two ways, only one of which survives Coolify upgrades. Use the upgrade-safe one.

Method 1, docker-compose.override.yml (the right way)

Coolify reads a file at /data/coolify/source/docker-compose.override.yml if it exists and merges it on top of the default Coolify Docker Compose configuration. This file isn't touched by Coolify upgrades, which means your customizations survive when you upgrade. This is the recommended approach.

SSH into your Coolify server, then create the override file:

nano /data/coolify/source/docker-compose.override.yml

Add the following content, replacing 9000 with whatever port you actually want:

services:
  coolify:
    ports:
      - "9000:8080"

The format is HOST_PORT:CONTAINER_PORT. The container internally listens on 8080 (or whatever Coolify's internal port is in your version, check the default docker-compose.yml at /data/coolify/source/docker-compose.yml to confirm). The host port is what you'll reach from outside.

Save, then restart Coolify to pick up the override:

cd /data/coolify/source
docker compose down
docker compose up -d

Now the dashboard is on the new port. Reach it as http://your-server:9000.

Method 2, APP_PORT in .env (limited, not recommended)

Older Coolify guides suggest editing the APP_PORT variable in /data/coolify/source/.env. This historically worked but has limits in current versions. Recent Docker versions expect APP_PORT to be an integer in specific contexts and the .env approach doesn't always survive upgrades cleanly.

The override file approach (Method 1) is more reliable. Use that.

What else needs to change after you change the dashboard port

Don't just change the port and walk away. A few other things need to follow.

Firewall rules

If you have UFW or iptables enabled, the new port needs to be allowed for inbound traffic. On Ubuntu with UFW:

sudo ufw allow 9000/tcp
sudo ufw delete allow 8000/tcp  # If you want to close the old port

Don't close the old port until you've confirmed the new one works, otherwise you can lock yourself out.

GitHub App and webhook URLs

If you have a GitHub App connected as a Source, the webhook URL Coolify generated for it includes the dashboard hostname. After changing the port, the webhook URL changes (or your GitHub App needs to know about the new URL). Check your GitHub App's Webhook URL setting on github.com and update if it points at the old port.

Similarly, any external service hitting Coolify's API (deploy webhooks from CI, custom integrations) needs to know about the new port.

Bookmarks and team docs

Update your team's bookmark or wiki entry for the Coolify dashboard. The number of teams I've seen lock themselves out by changing the port and forgetting to tell anyone is non-trivial.

The lockout warning

Worth a section on its own because it happens. If you change the dashboard port, restart Coolify and the new port doesn't work for some reason (typo in the override file, port conflict with something else on the host, firewall not allowing it), you can find yourself unable to reach Coolify at all.

Recovery requires SSH access to the host. Edit or remove /data/coolify/source/docker-compose.override.yml, restart Coolify with docker compose down && docker compose up -d from /data/coolify/source/ and you're back to the default port 8000.

The recovery is easy. The point is: don't change the dashboard port from a session that depends on the dashboard. Always have an SSH connection open as your fallback before making the change.

How to expose application ports through Traefik

Different question, common confusion. Your applications listen on whatever port you tell them to inside their containers. The "Ports Exposes" field in Coolify's application settings tells Coolify which container port to route external traffic to.

The standard case, web apps on 80 and 443

Most web applications follow this pattern. Your app inside the container listens on something like 3000 (Next.js default), 8000 (Django default) or 8080 (Java apps default). You set Ports Exposes to that port in Coolify's General tab. Traefik routes external traffic on 80 and 443 to your domain, terminates SSL and forwards the unencrypted request to your container on the port you specified.

You don't need to expose a port publicly on the host for this. Traefik handles the routing inside the Docker network, the container only needs to be reachable from Traefik, not from the public internet directly.

The non-web case, exposing custom ports

Sometimes you need a non-HTTP port reachable from outside. A WebSocket server on 9090, a TCP service, a custom protocol. Coolify supports this with the Ports Mappings field (different from Ports Exposes). Format is HOST_PORT:CONTAINER_PORT.

If your app listens on 9090 inside the container and you want it reachable on host port 9090:

9090:9090

Coolify maps this through Docker's port publishing, which means the port is accessible directly on the host IP without going through Traefik. SSL termination doesn't apply (Traefik isn't in the path), so you'd need to either use TLS at the application level or accept that this port is plain TCP/UDP.

Why Ports Exposes vs Ports Mappings matters

The naming is confusing. Quick rule:

• Ports Exposes, used by Traefik for HTTP routing. Set the container port your app listens on. Traefik adds SSL and serves it on 80 and 443
• Ports Mappings, used for direct host port publishing. Bypasses Traefik. Use for non-HTTP services or when you specifically don't want SSL termination

For 95% of web applications, you only need Ports Exposes. Ports Mappings is for the edge cases.

Common Coolify port problems and how to fix them

"Port already in use" when starting Coolify

Something else on the host is bound to the port. Find what's using it:

sudo lsof -i :8000
# or
sudo netstat -tulpn | grep 8000

Either stop the conflicting service or change Coolify's port using the override method above.

Application returns 502 Bad Gateway through Traefik

The container is running but isn't listening on the port Coolify expects. Check the Ports Exposes setting in the application's General tab matches the port your app actually binds to. Also confirm your app binds to 0.0.0.0 not 127.0.0.1 inside the container, because Docker can only reach containers on their external interface.

Application listens on the right port but external requests time out

Almost always Cloudflare or another CDN proxy in front, set up incorrectly. Check the SSL flow first (the Coolify SSL guide covers the Cloudflare proxy gotcha that breaks Let's Encrypt and sometimes also breaks origin connectivity).

Database port conflicts when running multiple databases

Inside the Coolify Docker network, two Postgres containers can both run on internal port 5432 because they have different hostnames. Conflicts happen when you expose them publicly. If you've enabled "expose externally" on two Postgres resources, they need different public ports. Set this in the database resource's settings.

Coolify Realtime not working after firewall change

Ports 6001 and 6002 are used by Coolify's Realtime feature (live log streaming, real-time UI updates). If you locked these down too tightly in your firewall, Realtime stops working. The dashboard still loads but live data doesn't update. Reopen 6001 and 6002 to localhost or to your client IPs.

Here's what I suggest next...

Once your ports are sorted, you can layer on the rest of the production setup. The Coolify SSL guide covers Let's Encrypt, custom certs and wildcards. The Coolify monitoring guide covers Sentinel, Prometheus and Grafana. The production server security guide covers SSH hardening and firewall rules at a deeper level than this article touches.