Coder Legion - Recent posts tagged coolify

Directus + Coolify: Should You Decouple Postgres & Redis?

Thu, 06 Aug 2026 21:39:55 +0000

This is Part 2 of the Directus + Coolify series. If you're new here, start with "Secure Your VPS Before Hackers Do" and the first Directus + Coolify post — the bundled, single-Compose-file setup — before following along with this one.

Introduction

In the first method, we coupled all of the services into one stack using a single Docker Compose file. The network between all services was created automatically, and we didn't have to start them up individually — which removes the risk of a race condition if service startup isn't handled properly.

If you're running a single app, that's genuinely the recommended way to set up Directus on a Coolify-managed VPS. Going in, I assumed there were several good reasons to split the services apart instead — more control over backups, monitoring, restarts, that kind of thing. So before recommending decoupling, I actually tested each of those assumptions on a live Coolify instance.

Most of them turned out to be wrong.

Myth 1: Restarting Directus Restarts the Whole Stack

I expected that restarting Directus inside the bundled Compose file would restart Redis and Postgres along with it. It doesn't. Coolify lets you restart each service in the stack independently — Directus, Database, and Cache each get their own Restart button, right there in the same view. No decoupling needed for this one.

Myth 2: You Need a Separate Database Resource for S3 Backups

Same story. Even with Postgres bundled inside the Directus Compose file, Coolify still gives it its own dedicated Backups option, S3 included. This isn't a separate-resource-only feature.

Myth 3: Scheduled Tasks Require Separate Services

Also not true. Coolify exposes a Scheduled Tasks tab per service, even inside a single bundled stack — complete with a Container name dropdown letting you target the cron job at just the database, or just Directus, without splitting anything apart.

What Actually Holds Up

Two things survived testing.

First: metrics. This one's confirmed directly in Coolify's own documentation — CPU and memory metrics collection is explicitly not available for Docker Compose–based deployments. If you want to see per-container resource usage through Coolify's built-in monitoring, the service needs to be created as its own standalone resource, not bundled inside a Compose file. This is a real, documented limitation of the bundled approach.

Second: sharing a database across multiple apps. This one isn't a Coolify feature at all — it's just how Docker networking works. A database defined inside one app's Compose file lives on that stack's own private network by default. A second, completely separate application can't reach it without deliberately bridging the two networks. If you've got a desktop app and a mobile app that both need to talk to the same Postgres instance, that database needs to exist as its own standalone resource from the start — it can't stay tucked inside one app's Compose file.

So this really comes down to two reasons to decouple, not five — one a genuine Coolify limitation, the other a structural fact about Docker networking. Let's set both of those up properly.

Adding the Resources

Adding the PostgreSQL Database

Dashboard → Add Project
+ Add Resource
Databases → PostgreSQL → Supabase PostgreSQL (with extensions)
Change the name to something human-friendly
Copy your username and password and save them somewhere — you'll need them shortly
Click Save
Click Start, and wait for the database to spin up (this can take a little while)

Once it's up, the status should read "Running (Healthy)."

💡 Enable metrics while you're here. In the sidebar, go to Servers → localhost → Metrics, and enable metrics. Back in your project, under Databases, click your Postgres database, then Metrics — you should now see live CPU/memory usage for it. This is the exact capability that isn't available on a bundled Compose deployment.

Adding Redis Cache

Dashboard → + Add Resource (from the project itself)
Databases → Redis
Rename it to something more convenient
Copy the Redis connection URL — you'll need it shortly
Save, then Start

Once both are running, SSH into your VPS and run:

docker ps

to confirm both containers are up.

The Docker Compose Config for Directus

This is what goes into the empty Compose file for the Directus resource:

services:
  directus:
    image: 'directus/directus:12.2.0'
    ports:
      - '8055:8055'
    volumes:
      - './uploads:/directus/uploads'
      - './extensions:/directus/extensions'
    healthcheck:
      test:
        - CMD-SHELL
        - 'wget --spider -q http://127.0.0.1:8055/server/ping || exit 1'
      interval: 10s
      timeout: 5s
      retries: 5
      start_interval: 5s
      start_period: 30s
    environment:
      SECRET: secretstring
      MARKETPLACE_TRUST: all
      DB_CLIENT: pg
      DB_HOST:
      DB_PORT: '5432'
      DB_DATABASE: postgres
      DB_USER: postgres
      DB_PASSWORD:
      CACHE_ENABLED: 'true'
      CACHE_STORE: redis
      CACHE_AUTO_PURGE: 'true'
      REDIS:
      ADMIN_EMAIL: *Emails are not allowed*
      ADMIN_PASSWORD: '1234567890'
      CORS_ENABLED: 'true'
      CORS_ORIGIN: 'true'
      CORS_CREDENTIALS: 'true'
      PUBLIC_URL:

Notice the healthcheck already uses 127.0.0.1 instead of localhost — that's the fix from Part 1. Carrying it forward here saves you from hitting the exact same "unhealthy" bug all over again.

Adding Directus

Dashboard → + Add Resource (from the project itself)
Applications → Docker Compose Empty
Paste in the Compose configuration above
Click Save
Network → Connect To Predefined Network → check the box
Services → Directus service → Settings
Add your Directus subdomain — remember to use https:// (e.g. https://directus.yourdomain.com)
Save

Connecting the Services Together

Variable	What it is
`SECRET`	A long, unguessable random string
`DB_HOST`	The name of your Postgres container — run `docker ps` on your VPS to find it
`DB_DATABASE`	The name of the database on your Postgres server (Coolify's default is usually `postgres`, but confirm it against your Postgres service)
`DB_USER`	The database username, from the Postgres service you created earlier
`DB_PASSWORD`	The password from that same Postgres service
`REDIS`	The Redis connection URL from the Redis service you created earlier
`PUBLIC_URL`	Your Directus subdomain

⚠️ Redis URL gotcha: the connection URL follows the format redis://username:password@host:port. Coolify's generated URL includes the username you set when creating the Redis resource — in my case, that username was also redis, so the URL looked like redis://redis:somelongvariable.... Directus doesn't need the username here, just the password, so strip that segment out: redis://:somelongvariable.... If you used a different username when creating your Redis resource, remove that value instead — not literally the word "redis."

Setting Up Environment Variables

Rather than hardcoding any of this directly into the Compose file, move it into Directus's environment variables:

Dashboard → Projects → Services / Directus
Environment Variables
Click + Add, enter the variable name in all caps, and its value
Save
Repeat for: SECRET, DB_HOST, DB_DATABASE, DB_USER, DB_PASSWORD, ADMIN_EMAIL, ADMIN_PASSWORD, and REDIS

Updating the Compose File

Now reference those variables instead of the raw values:

SECRET: '${SECRET}'
DB_HOST: '${DB_HOST}'

...and so on for each variable. Then:

Save
Restart

Launching Directus

Paste your Directus subdomain into the browser, and you should land on your running Directus instance. You can also click Links on the Directus service, then click the subdomain — it'll take you straight to your Directus Studio login.

Same as the last video: sign up for your free license, which arrives by email, and paste it into your Directus instance to unlock everything.

Any questions or hit a different result testing any of these yourself? Drop it in the comments — I'm genuinely curious whether this holds up across different Coolify versions and setups.

Setting Up Directus on a Coolify VPS (And Fixing the "Unhealthy" Error)

Sun, 02 Aug 2026 14:42:21 +0000

Introduction

Directus is a backend for developers. It can connect to any SQL database and asset storage, and it provides developer tooling — which the Directus team calls the "Data Engine" — alongside a web application that lets both developers and non-developers manipulate data and assets through a no-code interface called the "Data Studio."

Directus also offers granular access control, meaning end users can only see, manipulate, and interact with the data allowed by their role and access policy — enforced consistently by both the engine and the studio. It's extensible through its own marketplace, and it's completely free, with a free license available.

Directus is also known as a headless CMS — meaning it doesn't ship with a front end attached out of the box, the way WordPress traditionally did. You can pair it with whichever front end you prefer; TanStack Start is my front end of choice.

In this post, I'll self-host Directus on my Coolify-managed VPS, walk through both setup methods, and — since nothing ever works perfectly on the first try — fix the actual errors I hit along the way.

📌 New here? I'd recommend checking out my earlier posts where I set up the VPS itself and installed Coolify on it, before continuing with this one.

Let's Get Started

There are two ways to set up Directus on a Coolify-managed VPS. I'll cover the first one here.

1. Log in to your Coolify Dashboard

In the sidebar menu, go to Projects → +Add
Give your project a name and description, and press continue

2. Add a Resource

After naming your project, you should be redirected to the project's page, where you can add a resource. If that redirect doesn't happen, click Projects in the sidebar, then click into your project, and you should see +Add Resource.

Click +Add Resource
Under Applications, select Docker Compose Empty
A blank Docker Compose file will open
Go to directus.com → Docs → Hosting → Deployment
Scroll down until you find the example Docker Compose YAML file, and copy it
Paste it into your blank Coolify Compose file
Find the directus: service, and under it, image: — update this to the version you want. As of this post, the latest version is 12.2.0:
```
image: directus/directus:12.2.0
```
Scroll to the end and set your own admin email and password — these become your Data Studio login credentials
Click Save at the top

3. Configure the Service

You should now be on the Configuration screen, with a Deploy button (yellow outline arrow) in the top right.

Under Network, check the box
Under Services, click Settings on the directus tab
In the Domain field, enter your subdomain — e.g. https://directus.yourdomain.com. Use https, so Traefik knows to issue a Let's Encrypt certificate for it
Click Save, then Back
Click Edit Compose File at the top, scroll down to PUBLIC_URL, and set it to match your subdomain:
```
PUBLIC_URL: https://directus.yourdomain.com
```
Click Save, close the modal
Click Deploy, then Confirm on the popup
Wait for the deployment to finish

4. Launch Directus

On the Configuration screen, click Links, then click your new subdomain.

The Errors

At this point, your browser will show two errors: a "Not Secure" warning in the address bar, and a "no available server" page.

Back on the Coolify dashboard, you'll notice the Directus instance is showing as unhealthy. Traefik will not route traffic to a service that's failing its health check — which is exactly what's happening here. So the first job is figuring out why the health check is failing.

Diagnosing the Problem

SSH into your VPS to start digging.

Check your running containers:

sudo docker ps

Install jq, so the JSON output we're about to read is actually readable:

sudo apt install jq

Check the health check failure log (grab your Directus container's name from the docker ps output above):

docker inspect --format='{{json .State.Health}}' <your-directus-container-name> | jq

The result looked like this:

{
  "Status": "unhealthy",
  "FailingStreak": 79,
  "Log": [
    {
      "Start": "2026-07-30T18:12:21.445964902-04:00",
      "End": "2026-07-30T18:12:21.502447668-04:00",
      "ExitCode": 1,
      "Output": "wget: can't connect to remote host: Connection refused\n"
    },
    {
      "Start": "2026-07-30T18:12:31.505411263-04:00",
      "End": "2026-07-30T18:12:31.556307544-04:00",
      "ExitCode": 1,
      "Output": "wget: can't connect to remote host: Connection refused\n"
    }
  ]
}

The first clue: "wget: can't connect to remote host: Connection refused". Whatever endpoint the health check is trying to reach, it's being actively refused — not timing out, refused. That distinction matters, and it's the thread that leads to the actual fix.

Inspecting the Docker Compose File

From the Coolify dashboard, select Projects in the sidebar
Click your project
Click the service, then Edit Compose File next to Service Stack

Here's the relevant section:

directus:
  image: 'directus/directus:12.2.0'
  ports:
    - '8055:8055'
  volumes:
    - './uploads:/directus/uploads'
    - './extensions:/directus/extensions'
  depends_on:
    database:
      condition: service_healthy
    cache:
      condition: service_healthy
  healthcheck:
    test:
      - CMD-SHELL
      - 'wget --spider -q http://localhost:8055/server/ping || exit 1'
    interval: 10s
    timeout: 5s
    retries: 5
    start_interval: 5s
    start_period: 30s

The problem is in the wget line — specifically, http://localhost:8055.

Why `localhost` Breaks This

Inside a Linux container, localhost isn't an address — it's a hostname that has to be resolved first, and it typically maps to two addresses at once:

127.0.0.1   localhost   # IPv4
::1         localhost   # IPv6

When wget looks up localhost, the system's resolver hands back both addresses, and wget tries them in whatever order it receives them — which, on many Linux/Alpine base images, tends to prefer IPv6 first.

Checking the container's logs confirms what's actually listening:

docker logs <your-directus-container-name> --tail 150

Directus only bound to IPv4. The startup log says exactly that:

Server started at http://0.0.0.0:8055

0.0.0.0 means "listen on every IPv4 interface" — Directus never opened an IPv6 socket at all. So when wget tries ::1:8055 first, there's genuinely nothing listening there, and the OS doesn't wait around wondering — it immediately sends back a rejection (a TCP RST). That's exactly why the log shows an instant "Connection refused" rather than a slow timeout. A timeout would mean something was reachable but not responding; a refusal means the OS said "nothing's here" right away.

127.0.0.1 sidesteps the whole problem, because it's already a literal IP address — no hostname lookup, no ambiguity about which protocol family to try, no chance of picking the wrong one. It goes straight to the one address where Directus is actually listening.

The Fix

Change localhost to 127.0.0.1 in the health check:

directus:
  image: 'directus/directus:12.2.0'
  ports:
    - '8055:8055'
  volumes:
    - './uploads:/directus/uploads'
    - './extensions:/directus/extensions'
  depends_on:
    database:
      condition: service_healthy
    cache:
      condition: service_healthy
  healthcheck:
    test:
      - CMD-SHELL
      - 'wget --spider -q http://127.0.0.1:8055/server/ping || exit 1'
    interval: 10s
    timeout: 5s
    retries: 5
    start_interval: 5s
    start_period: 30s

Save the change, close the modal, and click Restart in the top right. Wait for the restart to complete — it may look like nothing's happening for a bit, so give it a moment. Once it's finished, close the logs modal, and Directus should show as healthy.

Click Links, then your Directus subdomain, and you should land on the Data Studio login screen.

Logging In & Licensing

Enter the credentials you set earlier in the Compose file. You'll be asked whether you have a license or want to install the Core — choose Core for now, and follow the flow to complete sign-up.

At this stage, your instance isn't fully unlocked — you'll need a license. Good news: it's completely free if your business's revenue is under $5M and your team is under 50 people.

Head to directus.com/oig to apply for your key. Once you have it, go to your Directus Studio, click the gear icon (Settings) in the sidebar, click License, and add your key there to unlock all features. Your key is valid for a year.

Got questions, or hit a different error setting this up? Drop a comment below — happy to help troubleshoot.

Coolify: The Complete Manual Setup Guide (For When the Auto-Install Script Won't Cut It)

Thu, 23 Jul 2026 05:15:31 +0000

Coolify's one-line install script is great — until it isn't. Right now it officially supports Ubuntu 20.04, 22.04, and 24.04 LTS. If you're running anything newer (Ubuntu's already on 26.04 LTS), the script won't work and you're left doing it manually.

This is that manual walkthrough — set up in the order that fits a security-first VPS workflow rather than the order Coolify's own docs use. If you've been following along with the Ansible playbooks from earlier in this series, this picks up right where that left off.

Minimum Hardware Requirements

CPU: 2 cores
Memory: 2 GB RAM
Storage: 30 GB free

Coolify can technically run below this, but it's not recommended.

Prerequisites

Before touching Coolify itself, you'll need:

SSH access to your VPS
CURL installed
Docker Engine installed

If you're reconnecting to a server you've rebuilt or re-provisioned, clear the old fingerprint first:

ssh-keygen -f '/home/your-path/.ssh/known_hosts' -R 'your-vps-ip'

Installing SSH

If you followed the earlier videos in this series, OpenSSH is already installed. If not:

sudo apt update && sudo apt install -y openssh-server

Confirm it's running and check which port it's listening on (you should have already changed this from the default 22 — see the VPS security video):

sudo systemctl status ssh
sudo ss -tulpn | grep ssh

Installing CURL

sudo apt update && sudo apt install -y curl
curl --version

curl and ca-certificates also get installed as part of the apt-update Ansible playbook below, so this may already be handled.

Running the First Ansible Playbook

Connect Ansible to the VPS:

ANSIBLE_HOST_KEY_CHECKING=FALSE ansible -i ./inventory/hosts vpsDemo -m ping --user root --ask-pass

Then run the update playbook:

ansible-playbook ./playbooks/apt-update.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

If you haven't set up the Ansible inventory and playbooks from the earlier videos, do that first — this guide assumes they're already in place.

Installing Docker Engine

Remove any conflicting packages first:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)

Add Docker's official GPG key and repo:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Verify it worked:

sudo systemctl status docker
sudo docker run hello-world

Creating a Non-Root Admin User

Coolify's own docs assume you're using the root account. Since root login is disabled as part of the security hardening earlier in this series, we create a dedicated user with passwordless sudo instead.

Run the second playbook to create that user:

ansible-playbook ./playbooks/basic-secure.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

Then set up that user's SSH directory:

sudo mkdir -p /home/your-sudo-user/.ssh
sudo touch /home/your-sudo-user/.ssh/authorized_keys
sudo chmod 700 /home/your-sudo-user/.ssh
sudo chmod 600 /home/your-sudo-user/.ssh/authorized_keys

Setting Up Coolify's Directory Structure

sudo mkdir -p /data/coolify/{source,ssh,applications,databases,backups,services,proxy,webhooks-during-maintenance}
sudo mkdir -p /data/coolify/ssh/{keys,mux}
sudo mkdir -p /data/coolify/proxy/dynamic

Generating and Adding an SSH Key

sudo ssh-keygen -f /data/coolify/ssh/keys/*Emails are not allowed*rnal -t ed25519 -N '' -C your-sudo-user@coolify

Add the public key to the authorized_keys file:

cat /data/coolify/ssh/keys/*Emails are not allowed* | sudo tee -a /home/your-sudo-user/.ssh/authorized_keys

Pulling Coolify's Configuration Files

sudo curl -fsSL https://cdn.coollabs.io/coolify/docker-compose.yml -o /data/coolify/source/docker-compose.yml
sudo curl -fsSL https://cdn.coollabs.io/coolify/docker-compose.prod.yml -o /data/coolify/source/docker-compose.prod.yml
sudo curl -fsSL https://cdn.coollabs.io/coolify/.env.production -o /data/coolify/source/.env
sudo curl -fsSL https://cdn.coollabs.io/coolify/upgrade.sh -o /data/coolify/source/upgrade.sh

Generating Secure Environment Values

Only run these once, on first install. Changing them later can break Coolify. Back them up somewhere safe.

sudo sed -i "s|APP_ID=.*|APP_ID=$(openssl rand -hex 16)|g" /data/coolify/source/.env
sudo sed -i "s|APP_KEY=.*|APP_KEY=base64:$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|DB_PASSWORD=.*|DB_PASSWORD=$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|REDIS_PASSWORD=.*|REDIS_PASSWORD=$(openssl rand -base64 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_ID=.*|PUSHER_APP_ID=$(openssl rand -hex 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_KEY=.*|PUSHER_APP_KEY=$(openssl rand -hex 32)|g" /data/coolify/source/.env
sudo sed -i "s|PUSHER_APP_SECRET=.*|PUSHER_APP_SECRET=$(openssl rand -hex 32)|g" /data/coolify/source/.env

Permissions and Docker Setup

Set correct ownership and permissions:

sudo chown -R 9999:root /data/coolify
sudo find /data/coolify -type d -exec chmod 755 {} \;
sudo find /data/coolify -type f -exec chmod 644 {} \;
sudo chown -R your-sudo-user:your-sudo-user /home/your-sudo-user/.ssh

Create the Docker network Coolify expects:

sudo docker network create --attachable coolify

Add your user to the Docker group:

sudo usermod -aG docker your-sudo-user

Starting Coolify

sudo docker compose --env-file /data/coolify/source/.env -f /data/coolify/source/docker-compose.yml -f /data/coolify/source/docker-compose.prod.yml up -d --pull always --remove-orphans --force-recreate

Confirm it's running:

sudo docker ps

Then visit http://YOUR-SERVER-IP:8000 in your browser.

Setup your SSL Certificates

Coolify's reverse-proxy Traefik does this under the hood automatically.

In your DNS records add two A records.

A     @     your-vps-ip-address        14400
A     *     your-vps-ip-address        14400

In your Coolify dashboard go to settings in the left side column. In the input box marked URL type your https subdomain for Coolify there.

https://coolify.yourdomain.com

Traefik will automatically apply a Let's Encrypt certificate to your Coolify subdomain.

Disable Port 8000

Disable port 8000 on your VPS. If your hosting provider allows you to configure a firewall from your dashboard, disable it from there. To disable port 8000, simply write rules that allow the ports you want and block everything else.

Wrap-Up

That's a full manual Coolify install on a hardened, non-root VPS — no automated script required. From here, Coolify handles the rest: connecting your Git repos, setting up applications, and managing deployments.

If you hit issues with the automated script on a newer Ubuntu release, this manual path should get you unblocked. Questions or corrections welcome in the comments.

What is Coolify? Self-Hosting with Superpowers

Thu, 18 Jun 2026 03:34:08 +0000

Introduction

In the last post, we talked about the VPS and why it is a compelling option for hosting your web applications. I mentioned a tool called Coolify that makes managing a VPS significantly easier. In this post, we are going to dive deeper into what Coolify actually is, what it does, and why I think it is one of the best tools available for developers and small teams who want the power of a VPS without the complexity of managing one from scratch.

What is Coolify?

Coolify is a free, open-source, self-hostable platform as a service — or PaaS. Think of it as your own personal Heroku or Render, but running on your own server. This means you own your infrastructure, your data, and your costs.

The best way to understand Coolify is to compare it to the alternatives. Platforms like Heroku, Render, and Railway are fully managed PaaS solutions. They abstract away all the server complexity — you push your code and it runs. The trade-off is cost and control. As your app scales, the bills grow quickly and you have limited control over the underlying infrastructure.

Coolify gives you the same developer experience — push your code and it deploys — but on a VPS that you control. You get the simplicity of a managed platform with the economics and control of a VPS.

What Does Coolify Do?

Coolify handles all the hard parts of running applications on a VPS.

Git Integration - Connect your GitHub, GitLab, or Bitbucket repository and Coolify will automatically deploy your app every time you push to your main branch. No manual deployments, no SSH commands — just push your code and it is live.
Dockerized Deployments - Every application Coolify deploys runs in a Docker container. This means your apps are isolated, portable, and consistent across environments. You do not need to know Docker deeply to use Coolify — it handles the containerization for you.
Automatic HTTPS - Coolify integrates with Let's Encrypt to automatically provision and renew SSL certificates for all your applications. Every app gets HTTPS out of the box with zero configuration on your part.
Built-in Reverse Proxy Coolify uses Traefik as its built-in reverse proxy and web server. It automatically routes traffic to the right application based on the domain name. You can run multiple applications on the same VPS and Coolify handles the routing between them.
Database Management - Coolify can deploy and manage databases alongside your applications — PostgreSQL, MySQL, MongoDB, Redis and more. You can spin up a database with a few clicks and connect it to your application without any manual configuration.
Environment Variables - Manage your environment variables securely through the Coolify dashboard. No more manually editing .env files on the server.
Monitoring and Logs - Coolify provides basic monitoring and real-time log streaming for all your applications directly from the dashboard. You can see what your app is doing without SSH-ing into the server.
Backups - Coolify supports automated database backups to S3-compatible storage. Your data is protected without any manual backup scripts.

Why Would You Use Coolify?

There are several scenarios where Coolify makes a lot of sense.

You want the economics of a VPS without the complexity.
A 6USD to 10USD per month VPS with Coolify can run multiple applications that would cost hundreds of dollars per month on Heroku, Render, or Railway. For a startup or indie developer this is a significant saving.

You want full control over your infrastructure.
With Coolify you own everything. Your data stays on your server. You choose your hosting provider. You are not locked into any platform's pricing or terms of service.

You want a great developer experience.
Coolify's dashboard is clean and intuitive. Deploying an application is genuinely just a few clicks. It does not feel like managing a server — it feels like using a modern PaaS.

You are running multiple projects.
One VPS with Coolify can host multiple applications, multiple databases, and multiple domains. Instead of paying for separate hosting for each project, you consolidate everything onto one server.

What Are the Limitations?

Coolify is not perfect for every situation. Here are some things to be aware of.

You are responsible for your server — if your VPS goes down, your apps go down. With managed platforms the provider handles up time.

Some configuration is still required — especially for custom setups, firewalls, and advanced networking.

It is self-hosted — meaning you need to keep Coolify itself updated and maintained.

Not ideal for very large scale — for enterprise applications with massive traffic you may need dedicated infrastructure beyond a single VPS.

How Do You Get Started with Coolify?

Getting Coolify up and running is surprisingly straightforward. In an upcoming post I will walk you through the complete setup — from provisioning a VPS to having Coolify installed and your first application deployed.

All you need to get started is:

• A VPS with at least 2GB RAM and 2 CPU cores 
• A domain name 
• About 30 minutes of your time

Conclusion

Coolify bridges the gap between the simplicity of managed platforms and the power and economics of a VPS. For developers and small teams who want to own their infrastructure without being overwhelmed by server management, it is genuinely one of the best tools available right now.

In an upcoming post we will get our hands dirty and set up Coolify from scratch. See you there.

References

• https://coolify.io 
• https://coolify.io/docs 
• https://github.com/coollabsio/coolify

Back-End Web Development — VPS vs Vercel vs Netlify

Thu, 18 Jun 2026 03:34:03 +0000

Introduction

Every great web application with millions of users has an even greater back end — and it has to be. Accessing your app over a prolonged period of time will test the integrity, availability, and speed of your back end. Backend technology can be inexpensive, or it can cost you thousands of dollars. So what's the deal here?

Let me warn you that this post is highly opinionated. I am sharing the tools that I use and how I use them.

For my back end that powers my web apps, I use Directus for my headless CMS, supported by a PostgreSQL and Redis database, hosted on a VPS, and managed by Coolify. Wow, that is a mouthful — and on my channel I explore how they all work together.

So let's tackle each technology one at a time, starting with the VPS.

What is a VPS?

A Virtual Private Server, known as a VPS, is a virtual environment created on a physical server. Think of it like an apartment building — everyone shares the same physical structure, but each unit has its own private space, utilities, and security. While multiple VPS instances share a physical server, be careful not to confuse this with shared hosting.

Each VPS is allocated its own dedicated resources, which are restricted to that VPS for as long as it is active. Therefore, the performance of a VPS is not directly affected by the usage of other VPS instances, but rather by the underlying performance of the physical server itself.

What are the benefits of a VPS?

There are several benefits to consider when deciding on virtual private server hosting:

Greater control — Compared to shared hosting, you have root access and can fully customize your server environment.
Dedicated resources — Allocated CPU, memory, and storage help ensure consistent performance.
Scalability — You can easily scale resources up or down to accommodate changing traffic and application demands.
Cost-effectiveness — A VPS typically offers a balance between the affordability of shared hosting and the power of a dedicated server.
Improved security — Isolation from other users on the same physical server enhances security.
Choice of operating system — You can choose the operating system that best suits your needs, such as Linux or Windows.

How does it stack up against Vercel or Netlify?

Vercel offers minimal setup with Git integration and fast deployment right out of the box. It has a free Hobby plan, but it is strictly for personal, non-commercial use. Once your app grows and needs to scale, you will need to move to a paid plan.

The Pro plan starts at $20 per user per month, and also covers serverless functions. Despite the name, serverless code still runs on a physical server — however, the infrastructure management, such as scaling, security patching, and provisioning, is handled entirely by the cloud provider. The main factor to watch carefully is cost.

Vercel uses usage-based billing, and costs can escalate quickly — especially since Turbo build machines became the default for new Pro projects in February 2026, at 0.126USD per build minute. A moderate team workflow can generate over $400 per month in build costs alone, before bandwidth and compute charges. I have seen some alarming Vercel bills shared online by customers, which means you need to fully understand the pricing model before you commit.

Netlify has historically been more suited to static sites and composable web applications. Composable applications are software systems built from independent, interchangeable modules rather than a single rigid code base. Netlify also has Git integration, customizable build plugins, and serverless functions. Netlify moved to a credit-based pricing model in September 2025, which is
designed to simplify metered billing.

As of April 2026, the Pro plan costs 20USD per month and now includes unlimited team member seats, which is an improvement over the previous per-seat model. However, teams working on active projects with real traffic can burn through their credit allocation quickly, and credit pack add-ons at 10USD per 1,500 credits mean teams can regularly spend 40USD to 80USD or more per month beyond the base subscription. Your overall control is also more limited compared to a VPS, and you will still face a monthly cost as your app grows.

Now the VPS.

VPS prices can grow as your app grows, but in my experience at a slower and more predictable rate — with no surprise charges. However, if you manage a VPS yourself, it requires understanding web servers, firewalls, operating systems, caching, and more. It can get complex very quickly and may cause you to spend more time managing the server than building and scaling your app.

That is why some developers and business owners hire a team to handle it. Small teams may not have the budget for a dedicated infrastructure team, so they often opt for a more convenient managed solution.

There is one tool, however, that I think is worth mentioning and is a genuine game changer — and that is Coolify. In a later post I will go into more detail about what Coolify is and what it does. Coolify is a self-hostable platform that makes managing your VPS significantly easier. It offers Git integration, runs apps in Dockerized containers, handles HTTPS automatically, and includes a built-in web server that works out of the box with no manual configuration required. This makes the VPS a very real and competitive option worth considering.

If you choose a solid hosting provider and pair it with the right tools, you can make this an absolute dream to work with.

Now don’t get me wrong, even with Coolify there are some configurations that you will have to make, but I do believe a VPS is a great solution for a start up, mid-size or enterprise scaled app, with the right tools.

References

• https://cloud.google.com/learn/what-is-a-virtual-private-server 
• https://aws.amazon.com/what-is/vps/ 
• https://www.ibm.com/think/topics/vps 
• https://www.scalahosting.com/blog/what-is-a-vps-technical-explanation/ 
• https://www.dreamhost.com/blog/beginners-guide-vps/ 
• https://vercel.com/pricing 
• https://www.netlify.com/pricing/ 
• https://bejamas.com/blog/self-hosting-vs-vercel-and-netlify-which-solution-is-right

Coder Legion - Recent posts tagged coolify

Directus + Coolify: Should You Decouple Postgres & Redis?

Introduction

Myth 1: Restarting Directus Restarts the Whole Stack

Myth 2: You Need a Separate Database Resource for S3 Backups

Myth 3: Scheduled Tasks Require Separate Services

What Actually Holds Up

Adding the Resources

Adding the PostgreSQL Database

Adding Redis Cache

The Docker Compose Config for Directus

Adding Directus

Connecting the Services Together

Setting Up Environment Variables

Updating the Compose File

Launching Directus

Setting Up Directus on a Coolify VPS (And Fixing the "Unhealthy" Error)

Introduction

Let's Get Started

1. Log in to your Coolify Dashboard

2. Add a Resource

3. Configure the Service

4. Launch Directus

The Errors

Diagnosing the Problem

Inspecting the Docker Compose File

Why localhost Breaks This

The Fix

Logging In & Licensing

Coolify: The Complete Manual Setup Guide (For When the Auto-Install Script Won't Cut It)

Minimum Hardware Requirements

Prerequisites

Installing SSH

Installing CURL

Running the First Ansible Playbook

Installing Docker Engine

Creating a Non-Root Admin User

Setting Up Coolify's Directory Structure

Generating and Adding an SSH Key

Pulling Coolify's Configuration Files

Generating Secure Environment Values

Permissions and Docker Setup

Starting Coolify

Setup your SSL Certificates

Disable Port 8000

Wrap-Up

What is Coolify? Self-Hosting with Superpowers

Introduction

What is Coolify?

What Does Coolify Do?

Why Would You Use Coolify?

What Are the Limitations?

How Do You Get Started with Coolify?

Conclusion

Back-End Web Development — VPS vs Vercel vs Netlify

Introduction

What is a VPS?

What are the benefits of a VPS?

How does it stack up against Vercel or Netlify?

Now the VPS.

References

Why `localhost` Breaks This