Building an Enterprise Internal PaaS: Scaling Coolify Advanced Queue Mode with Redis Sentinel on a 3-Node Cloud Cluster

Introduction: The Rise of the Internal PaaS

In modern software engineering, operational efficiency is a core competitive advantage. While public Platform-as-a-Service (PaaS) providers like Heroku, Render, or Vercel offer unparalleled convenience, they often introduce significant challenges as organizations scale. These include escalating subscription costs, rigid data sovereignty limitations, and vendor lock-in. Conversely, managing raw Kubernetes clusters introduces a steep learning curve and high administrative overhead that can distract development teams from delivering core business value.

To strike a balance, forward-thinking enterprise engineering teams are turning to self-hosted, internal PaaS solutions. Coolify has emerged as a premier open-source alternative, giving organizations Heroku-like simplicity on their own infrastructure. However, out-of-the-box single-node setups pose a catastrophic risk: if the main server goes down, your entire deployment pipeline and background task execution halt.

This technical guide demonstrates how to architect a highly available, resilient internal PaaS by configuring Coolify's Advanced Queue Mode backed by a Redis Sentinel cluster distributed across three cloud server nodes. This architecture ensures that your background deployment jobs, webhooks, and automated tasks remain operational even during unexpected infrastructure failures.

1. Understanding the Architecture: Coolify, Horizon, and Redis Sentinel

To build a resilient platform, we must first understand how Coolify processes heavy workloads. Coolify relies on an asynchronous queue system powered by Laravel Horizon to handle long-running tasks such as building Docker images, provisioning SSL certificates, and executing health checks. By default, these tasks are queued inside a local Redis instance on a single server.

Under heavy enterprise workloads or during server maintenance, this single Redis instance becomes a bottleneck and a Single Point of Failure (SPOF). If the node hosting Redis crashes, pending deployments vanish, and the platform becomes unresponsive.

The Role of Advanced Queue Mode

Coolify's Advanced Queue Mode decouples the queue management execution from the primary application dashboard. Instead of relying on a localized, fragile loop, it allows Coolify to point its Horizon queue workers toward an external, robust database cluster. This unlocking of distributed queue management is what transforms Coolify from a hobbyist tool into an enterprise-grade internal PaaS.

Why Redis Sentinel?

To back this advanced queue, we require a storage layer that guarantees high availability. Redis Sentinel provides the perfect framework for this use case, delivering three essential capabilities:

• Monitoring: Constantly checks if your master and replica Redis instances are functioning correctly.
• Notification: Alerts external applications (like Coolify) via an API when a Redis instance fails.
• Automatic Failover: If the master node goes offline, Sentinel initiates a failover process, promoting a healthy replica to master and reconfiguring the remaining replicas automatically.

By spreading three cloud nodes across distinct availability zones, we achieve a quorum-based architecture capable of surviving the sudden loss of any single server without data loss or downtime.

2. Prerequisites and Cluster Topology

Before initiating the deployment, ensure your cloud infrastructure meets the following architectural requirements. We will utilize three identical cloud compute instances (e.g., AWS EC2, DigitalOcean Droplets, or Hetzner Cloud vCPUs) located within the same private network layer for optimal latency and security.

Security Note: Ensure that your cloud provider's firewall rules permit internal TCP communication on port 6379 for Redis traffic and port 26379 for Redis Sentinel cluster consensus. These ports must strictly block public internet traffic.

3. Step-by-Step Deployment Guide

Step 3.1: Deploying the Redis and Sentinel Topology

First, we must establish our highly available database layer across all three nodes. Install Redis and the Redis-Sentinel package on each server using your system package manager. Once installed, modify the configuration files as follows:

On Node-01 (Master), configure /etc/redis/redis.conf to bind to the private network IP and allow connections:

bind 127.0.0.1 10.0.0.11
protected-mode no
port 6379
requirepass YourSecureClusterPassword

On Node-02 and Node-03 (Replicas), configure their respective redis.conf files to point directly to the master node:

bind 127.0.0.1 [Local_Private_IP]
protected-mode no
port 6379
requirepass YourSecureClusterPassword
replicaof 10.0.0.11 6379
masterauth YourSecureClusterPassword

Next, configure the Sentinel configuration file (/etc/redis/sentinel.conf) identically across all three nodes to create the monitoring quorum:

port 26379
sentinel monitor mymaster 10.0.0.11 6379 2
sentinel auth-pass mymaster YourSecureClusterPassword
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Restart the Redis and Sentinel services across all nodes. You can verify the health of your replication cluster by executing the command redis-cli -p 26379 sentinel masters on any node to ensure all three sentinels have successfully registered and formed a quorum.

Step 3.2: Installing Coolify and Activating Advanced Queue Mode

Execute the official Coolify installation script on Node-01 to host your main management panel. Once operational, access the dashboard via your browser and navigate to the global settings console.

To transition Coolify from localized execution to distributed execution, you must modify its underlying environment variables. Access Node-01 via SSH and locate the Coolify environment configuration file (typically found at /data/coolify/source/.env). Update or append the following connection strings to hook into your Redis Sentinel cluster:

QUEUE_CONNECTION=redis
REDIS_CLIENT=predis
REDIS_SENTINELS=10.0.0.11:26379,10.0.0.12:26379,10.0.0.13:26379
REDIS_SENTINEL_SERVICE=mymaster
REDIS_PASSWORD=YourSecureClusterPassword

After saving the changes, restart your core Coolify instance via Docker Compose to apply the new configurations: docker compose down && docker compose up -d. Coolify is now decoupled from local state; its Horizon task workers will natively pull job allocations out of the highly available Redis array.

Step 3.3: Scaling Out Remote Docker Engines

With the control plane stabilized, navigate to the Coolify UI to register Node-02 and Node-03 as Remote Destinations. Coolify uses secure SSH keys to seamlessly install its localized proxy agent on these target nodes. By distributing your target build destinations across these remote servers, you ensure that even if the primary node experiences high CPU overhead during a compilation cycle, the background task queue remains entirely unhindered.

4. Validating High Availability and Failover Capabilities

An enterprise architecture is only as reliable as its tested resilience. To confirm that your new internal PaaS can handle catastrophic node failure, execute a controlled chaos engineering test.

Initiate a multi-stage application build within the Coolify dashboard so that your Horizon queue actively processes tasks. While the progress bar is active, simulate a hardware crash on Node-01 by abruptly stopping its Redis service or shutting down its network interface:

sudo systemctl stop redis-server

Monitor your logs on Node-02 or Node-03 immediately. Within 5,000 milliseconds (as configured in our down-after-milliseconds directive), the remaining Sentinels will detect the master's absence, reach a 2/3 majority quorum, and elect one of the replicas as the new Master. Because Coolify is configured with the entire Sentinel array string, its internal database client automatically discovers the newly promoted master, routes pending deployment packets without throwing critical execution exceptions, and ensures the active application builds conclude successfully.

Conclusion: Enterprise Freedom on Your Own Terms

By combining the intuitive user experience of Coolify with the robust reliability of Redis Sentinel, you successfully build an enterprise-tier internal PaaS that matches the uptime metrics of expensive commercial alternatives. This setup protects your mission-critical deployment flows from infrastructure anomalies while dramatically lowering operational costs. As your development team expands, this 3-node cluster architecture easily scales up, enabling your organization to deploy faster, safer, and with complete cloud sovereignty.