Directus + Coolify: Should You Decouple Postgres and Redis?

This is Part 2 of the Directus and Coolify series. If you are new here, the first method involved coupling all services into a single Docker Compose file, which automatically handles container networking and prevents race conditions during startup.

While bundled setups work best for a single app on a Coolify-managed VPS, the author initially assumed several reasons to split services—such as better control over backups, monitoring, and restarts. Each assumption was tested on a live Coolify instance before recommending any decoupling.

The first assumption was that restarting Directus would restart Redis and Postgres alongside it. In reality, Coolify provides an independent restart button for Directus, Database, and Cache right in the same view, eliminating the need to decouple for this reason alone.

The second assumption concerned backups. Even when Postgres is bundled inside the Directus Compose file, Coolify grants a dedicated Backups option complete with S3 support, proving it is not restricted to separate resources only.

Similarly, Coolify exposes a scheduled tasks tab per service within a bundled stack, featuring a container name dropdown to target cron jobs specifically at the database or Directus without separating anything.

Stock photo for illustration only, not from the actual event

However, two genuine reasons to decouple emerged. First, CPU and memory metrics collection is explicitly not available for Docker Compose-based deployments according to Coolify documentation. To view per-container resource usage through built-in monitoring, the service must be deployed as a standalone resource.