How to Self-Host Coolify and Deploy Your Own Apps Without a Cloud Provider

Understand the architecture before installing anything

Coolify is a self-hosted application deployment platform. It runs on a Linux server and coordinates container builds, application processes, environment variables, domains, deployment logs, and related resources through a web dashboard. It can provide a platform-style workflow without transferring day-to-day infrastructure responsibility to a hosted application provider.

Self-hosting does not remove the underlying operational work. You remain responsible for the server, storage, network reachability, security updates, credentials, backups, restore testing, monitoring, and capacity planning. The number and size of applications you can run are constrained by the CPU, memory, storage, and network capacity of your hardware.

Dashboard traffic and application traffic are separate

The Coolify dashboard is an administrative interface, commonly reached locally on port 8000 after installation. It can create deployments, reveal logs, modify environment variables, and control services. It is therefore more sensitive than an ordinary public application.

Applications deployed through Coolify have their own listening ports and publication paths. On a publicly reachable server, a reverse proxy can route an application's domain through inbound ports 80 and 443. On a server behind NAT or CGNAT, those inbound connections may never reach the server. Making only the Coolify dashboard available through a tunnel does not make the deployed applications public.

Choose one of three networking cases

Prepare the server and perform pre-install checks

Use a dedicated server or virtual machine where possible. Installing a platform manager on a machine already running a reverse proxy, database, or unrelated containers can create port conflicts and complicate recovery. Before installation, record what currently runs on the machine and make sure you have a tested way to recover access if networking changes.

Coolify's supported operating-system and architecture matrix can change. Use a currently supported 64-bit Linux release from the Coolify v4 documentation. Do not assume that every distribution, ARM board, Raspberry Pi model, or container host is supported merely because Docker can run on it. The applications you deploy must also provide images or build dependencies compatible with the server architecture.

Capacity and access checklist

• A currently supported 64-bit Linux installation.
• Administrative shell access, because the standard installer performs system-level changes.
• Enough CPU, memory, and disk for Coolify, image builds, application containers, logs, and retained data.
• Working outbound DNS resolution and HTTPS access so the server can download installation files, images, and source code.
• Correct system time, which is important for TLS, package repositories, and authenticated Git operations.
• A backup or snapshot created before modifying a server that already contains important data.
• A decision about whether the server will use public inbound ports or outbound Localtonet tunnels.

Run these read-only checks before installing:

uname -m
cat /etc/os-release
nproc
free -h
df -h
ip address
ip route
getent hosts cdn.coollabs.io
curl -I https://cdn.coollabs.io/coolify/install.sh
sudo ss -lntup

Review the output rather than looking only for command success. Confirm that the architecture and operating system appear in the current Coolify support matrix, that free memory and storage are appropriate for the intended workload, and that no unexpected process already occupies ports you plan to use.

The final command lists listening TCP and UDP sockets. Existing listeners on 80, 443, or 8000 deserve investigation before installation. Do not stop an unfamiliar service until you understand its purpose and have a rollback plan.

Install Coolify with an inspectable workflow

Coolify v4 provides an automated installation script at the URL below. A common one-line installation pipes that remote script directly into a shell:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

This is convenient, but it gives code downloaded at that moment permission to make privileged changes without giving you a natural review point. DNS compromise, a changed script, a typographical error, or an unexpected redirect could have serious consequences. Fetching the script first does not make it inherently trustworthy, but it lets you verify the URL, retain a copy, inspect the contents, and decide when to execute it.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o /tmp/coolify-install.sh
file /tmp/coolify-install.sh
head -n 40 /tmp/coolify-install.sh
less /tmp/coolify-install.sh
sudo bash /tmp/coolify-install.sh

When the installation process finishes, inspect containers and listening sockets:

sudo docker ps
sudo ss -lntp
curl -I http://127.0.0.1:8000

An HTTP response from port 8000, including a redirect, establishes that an HTTP service is answering. It does not prove that every Coolify component is healthy. Review the container status and installation output as well. If the connection is refused, do not create a tunnel yet. Resolve the local Coolify problem first.

Create the first administrator carefully

Open the dashboard from a trusted local network or through a temporary, carefully controlled path. The first account created during the initial setup may receive broad administrative authority, depending on the installed Coolify release and setup state. Complete registration immediately rather than leaving an unclaimed setup page reachable.

• Use a unique password generated and stored by a password manager.
• Do not reuse a Git provider, server, email, or personal password.
• Review account-security options supported by your installed Coolify release.
• Create lower-privilege operator access where your version supports it instead of sharing an administrator account.
• Do not place secrets directly in project names, public repository files, build output, or screenshots.

Coolify v4 normally presents its local server as a deployment destination during initial configuration. Validate the server using the current interface and resolve any reported health or connectivity errors. Connecting a private Git provider is optional for this tutorial because the example can be stored in any repository Coolify can read. Provider-specific OAuth setup, token scopes, webhook behavior, and automatic deployment controls vary by Coolify release and Git provider.

Build and deploy a reproducible test application

A useful installation test should verify more than a static welcome page. The application below reads an environment variable, listens on the port supplied through PORT, binds to every container interface, and exposes a machine-readable health endpoint.

Create an empty directory on your workstation:

mkdir coolify-health-demo
cd coolify-health-demo

Create package.json:

{
  "name": "coolify-health-demo",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "start": "node server.js"
  }
}

Create server.js:

const http = require("http");

const port = Number(process.env.PORT || 3000);
const message = process.env.APP_MESSAGE || "Coolify deployment is healthy";

const server = http.createServer((request, response) => {
  if (request.url === "/health") {
    response.writeHead(200, { "content-type": "application/json" });
    response.end(JSON.stringify({ status: "ok" }));
    return;
  }

  response.writeHead(200, { "content-type": "text/plain; charset=utf-8" });
  response.end(`${message}\n`);
});

server.listen(port, "0.0.0.0", () => {
  console.log(`Listening on 0.0.0.0:${port}`);
});

Create a Dockerfile:

FROM node:22-alpine

WORKDIR /app
COPY package.json server.js ./

ENV PORT=3000
EXPOSE 3000

CMD ["npm", "start"]

Create compose.yaml. The loopback-only host mapping is intentional. It provides a predictable local endpoint for testing and for an outbound Localtonet tunnel without making port 3000 listen on every server interface.

services:
  app:
    build: .
    restart: unless-stopped
    environment:
      PORT: "3000"
      APP_MESSAGE: "${APP_MESSAGE:-Coolify deployment is healthy}"
    ports:
      - "127.0.0.1:3000:3000"

Test the application locally if Docker is available on your workstation:

APP_MESSAGE="Local test succeeded" docker compose up --build -d
curl http://127.0.0.1:3000/
curl http://127.0.0.1:3000/health
docker compose logs --tail 100
docker compose down

The success criteria are a plain-text response containing Local test succeeded, an HTTP 200 health response containing {"status":"ok"}, and a log entry showing that the process listens on port 3000.

Commit and publish the repository

Place these files in a Git repository that the Coolify server can read. Do not commit passwords, API keys, private keys, or production environment files.

git init
git add package.json server.js Dockerfile compose.yaml
git commit -m "Add Coolify health demo"
git branch -M main
git remote add origin <YOUR-REPOSITORY-URL>
git push -u origin main

The repository URL is intentionally a placeholder. Use a repository you control. If it is private, configure the minimum Git-provider permissions required by the Coolify release and provider you use.

Deploy the Compose application in Coolify

The exact menu labels are version-sensitive, but the required workflow is consistent: create or select a project and environment, add a resource from a Git repository, choose the repository and branch, deploy its Docker Compose definition, and provide the application environment variable.

curl -i http://127.0.0.1:3000/
curl -i http://127.0.0.1:3000/health
sudo ss -lntp | grep ':3000'

The deployment is successful only when the root response contains Deployed through Coolify, /health returns HTTP 200 with {"status":"ok"}, the container remains running, and the application log does not show a restart loop.

Coolify can also work with other application build approaches, including Nixpacks and Dockerfiles, subject to the installed release. Build-pack support, language detection, Git integrations, automatic deployments, health-check controls, rolling behavior, and rollback options can change. Do not promise zero-downtime updates without testing the deployment strategy, replica count, health checks, startup time, database migrations, and reverse-proxy behavior for your application.

Publish applications using the path that matches your network

Case 1: Public server with DNS and inbound web ports

If the server has a public address and your network permits inbound traffic, applications can normally be published through the reverse proxy configured for the Coolify server. Do not assume that every Coolify installation always uses one particular proxy implementation. Check the proxy selected and supported by your installed release.

For a conventional domain-based deployment:

1. Create the application's DNS record so it resolves to the server's public IPv4 or IPv6 address.
2. If you publish an AAAA record, verify that IPv6 routing and firewall policy work. A broken AAAA record can cause failures for IPv6-capable visitors.
3. Allow only the required inbound ports through the host firewall, provider firewall, router, and upstream network.
4. Configure the application's domain in Coolify using the current release's domain settings.
5. Verify plain HTTP behavior, HTTPS certificate issuance, the application response, and the health endpoint from a network outside the server.

getent ahosts app.example.com
curl -I http://app.example.com
curl -I https://app.example.com
curl https://app.example.com/health

Replace app.example.com with your real domain. Certificate issuance requires the domain and network path to satisfy the certificate authority and proxy configuration in use. DNS resolution alone is not enough. Incorrect records, blocked inbound ports, an unreachable IPv6 address, rate limits, or a proxy configuration error can all prevent issuance.

Case 2: Private Coolify dashboard through Localtonet

Use this when an administrator needs to reach Coolify from another network but you do not want to forward port 8000 through the router. It is also applicable behind CGNAT because the Localtonet client establishes an outbound connection to our relay.

This tunnel publishes only the dashboard target. It does not automatically publish the demonstration application on port 3000, a database, or any other Coolify resource.

Case 3: Individual application behind NAT or CGNAT

Each public application needs a verified route to its own local endpoint. For the demonstration application, the endpoint is 127.0.0.1:3000. A separate Localtonet HTTP tunnel can publish that endpoint. For additional applications, use distinct reachable local ports or another routing arrangement you have tested from the machine running the Localtonet client.

Access the Coolify dashboard through Localtonet

Before creating the tunnel, verify from the machine that will run our client that http://127.0.0.1:8000 reaches Coolify. If Localtonet runs on another device, replace 127.0.0.1 with a private address that device can reach and protect the intervening network appropriately.

Localtonet setup uses the client application and dashboard. Do not copy unverified shell installers, service flags, relay codes, or authentication tokens from old tutorials. Obtain the current client for your operating system through the Localtonet application flow and keep the device-specific token private.

The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. Press Stop to make the configured tunnel unavailable while retaining it for later use. Delete it when the configuration is no longer required. Creating a tunnel and starting it are separate lifecycle actions.

Using a custom domain for the tunnel

A custom domain is optional and should not be treated as an authentication mechanism. Current Localtonet custom-domain setup delegates the domain's DNS to Localtonet nameservers. This is an authoritative DNS change, so inventory existing records before proceeding. Do not delegate a production domain until you understand how its website, email, verification, and other records will be reproduced.

1. Add the root domain, without www or another subdomain, in the Localtonet DNS Manager.
2. At the domain registrar, replace the existing authoritative nameservers with ns1.localtonet.com and ns2.localtonet.com.
3. Wait for nameserver propagation and verify that the expected DNS records resolve correctly.
4. Create an HTTP tunnel and choose Custom Domain as its Process Type.
5. Select the registered domain, choose the required subdomain, and enter the local target.
6. Create the tunnel, then press Start.

Nameserver propagation can take from minutes to as long as 48 hours. Existing and new DNS records should be verified from more than one network before relying on the domain. For the complete current workflow, see our Localtonet custom-domain guide.

Publish the demonstration application through Localtonet

This is a separate HTTP tunnel from the dashboard tunnel. It targets the application on port 3000, not Coolify on port 8000. First verify the application from the server:

curl -i http://127.0.0.1:3000/
curl -i http://127.0.0.1:3000/health

Then repeat the documented HTTP tunnel workflow:

The public success criteria are the same as the local criteria: the root page must contain Deployed through Coolify, and /health must return HTTP 200 with {"status":"ok"}. Test both paths after every change to the application port, Compose mapping, or tunnel target.

For additional applications, repeat this pattern with a unique local endpoint and a separate HTTP tunnel. Do not point multiple unrelated applications at the same local port. Also remember that public application access has its own security requirements. Implement authentication and authorization inside the application where appropriate, validate inputs, protect secrets, and do not expose administrative or development endpoints merely because a tunnel makes them convenient to reach.

Routine operations, backups, updates, and troubleshooting

Check service and container status

Start troubleshooting from the inside and move outward. Verify local process health before investigating DNS or Localtonet.

sudo docker ps
sudo docker ps -a
sudo docker stats --no-stream
sudo ss -lntp
df -h
free -h

A container in a restart loop usually indicates an application, configuration, dependency, permission, or resource problem. Discover the actual container name with docker ps -a, then inspect its logs:

sudo docker logs --tail 200 <container-name>

Coolify also provides deployment and resource logs in its dashboard. The exact tab labels vary by release. Examine both build logs and runtime logs because they answer different questions. A build can succeed while the resulting process crashes at startup.

Diagnose failed builds

• Confirm that Coolify can read the repository and selected branch.
• Check the Compose file path, Dockerfile path, build context, and filename capitalization.
• Look for package download failures, architecture-incompatible dependencies, missing files, and exhausted disk space.
• Verify that required build-time variables are actually build-time values. Do not print secrets to diagnose them.
• Reproduce the image build locally with the same source revision when possible.
• Read the first meaningful error in the build log rather than only the final nonzero exit message.

Diagnose an incorrect application port

Four values must agree: the application's listening port, the container declaration, the host mapping, and the Localtonet target. In this tutorial, the Node.js process listens on 0.0.0.0:3000, Compose maps host 127.0.0.1:3000 to container port 3000, and the application tunnel targets 127.0.0.1:3000.

If the application works inside the container but not through the host port, inspect the Compose mapping. If it works through 127.0.0.1:3000 but not through Localtonet, inspect the selected AuthToken, client status, tunnel target, and tunnel running state.

Distinguish Coolify failures from Localtonet failures

Handle DNS, firewall, and certificate failures

For a public-server deployment, confirm DNS from multiple resolvers, verify both A and AAAA records, and test from an external network. Check the host firewall, provider firewall, router, and upstream network independently. An open host firewall cannot compensate for a blocked provider rule, and a correct DNS record cannot compensate for CGNAT.

If certificate issuance fails, first confirm that the domain resolves to the intended publication path and that the required challenge traffic can reach the configured proxy or tunnel edge. Review proxy and certificate logs without repeatedly retrying at high frequency. Certificate authorities may apply issuance limits.

Plan for reboots and recovery

Do not assume that every component will recover automatically after a reboot. Test it. Schedule a maintenance window, reboot the server, and then verify:

1. The server is reachable through its intended administrative path.
2. The container runtime is active.
3. Coolify containers are running.
4. The dashboard answers locally on port 8000.
5. The demonstration application answers locally on port 3000.
6. The Localtonet client reconnects using the supported startup method for the installed client version.
7. Required tunnels are running.
8. Public health checks return the expected response.

The demonstration Compose file uses restart: unless-stopped for its application container. That setting alone does not guarantee that Coolify, networking, storage mounts, secrets, or the Localtonet client are ready after every failure.

Update deliberately

Follow the update mechanism documented for the installed Coolify release. Before updating, record the current version, read release notes, confirm free disk space, create relevant backups, and understand the rollback or recovery procedure. Interface buttons and previously successful deployment behavior are not substitutes for a recovery plan.

Update the host operating system and container images on a controlled schedule. Test major changes in a separate environment where possible. Application updates can include irreversible database migrations, so rolling containers back may not restore compatible data.

Back up data and test restoration

A backup feature is useful only when its destination, retention, encryption, and restoration process are understood. Coolify versions may provide database or storage integrations, but their supported engines, destinations, schedules, and restore workflows can change. Verify these details in the installed release instead of assuming one-click backup coverage.

• Back up application databases using a method supported by the database engine.
• Back up persistent volumes and uploaded files with application-consistent procedures.
• Protect Coolify configuration and the credentials required to rebuild the environment.
• Store at least one backup outside the server being protected.
• Encrypt backup data and restrict access to backup credentials.
• Record retention and deletion requirements.
• Perform scheduled restore tests to a separate environment.

A restore test should verify more than archive extraction. Start the restored application, test its health endpoint, authenticate where required, confirm expected records and files, and document the recovery time. Never wait for a production incident to discover that a backup is incomplete.

Decide whether self-hosting fits the workload

Coolify can simplify deployment coordination, but it does not turn privately owned hardware into an unlimited or maintenance-free platform. A hosted application platform may be more suitable when a team does not want to manage operating-system patches, capacity, incident response, backups, network availability, or server replacement.

Evaluate the operational responsibilities, available expertise, recovery requirements, data sensitivity, hardware limits, and expected traffic. Current pricing and service limits should be checked directly with each provider rather than inferred from broad comparisons.

Frequently asked questions