The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
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.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Trending
retrofuturism
Share your favorite designs from the past exploring the distant future. Or your own take on the aesthetic 🚀
halftone
Dots. Texture. Grain. Let's see your designs using the halftone technique.
Midjourney
Creatives are showing off what they're making with Midjourney.
colorgrade
Video editors sound off: How do you enhance the mood of your video in color grading?
Related posts
Introduction
Collections are the bread and butter of the Directus Data Studio. According to Directus's own docs, collections are database tables — with extra metadata and configuration layered on top by Directus.
The part that makes this genuinely beginner-friendly: you never write a single line of SQL. The Data Studio handles all of that for you. Let's build one.
One architectural decision changed everything.
"We don't deploy into our own cloud."
Customers design their backend visually. Our platform generates the Terraform. It deploys straight into their cloud account — not ours.
That sentence sounds simple.
In practice it forced us to rethink five things:
• Terraform state architecture — one isolated state per service, not one shared state per customer
• Identity separation — every tenant runs on its own scoped credentials, sealed off from the rest
• Existing-resource adoption — customers already have infrastructure, so we import it instead of fighting it
• Parallel deployments — many resources at once, without stepping on each other
• Runtime vs infrastructure health — "did it deploy" and "is it healthy" are different questions
The hard part was never generating Terraform.
It was making a system safe enough that someone would point it at their production account.
I designed and built this end to end — the architecture, the Terraform generation, the deploy pipeline.
If your team is heading somewhere similar, or you're about to point automation at a customer's production account for the first time, happy to compare notes. 👋
A multi-tenant AI orchestration platform that lets organizations deploy and manage AI agents at scale. It supports persona-based agents with defined roles and behaviors, webhook-driven triggers for automated actions, and single-prompt management of complex multi-step workflows. Built to run reliably on Kubernetes and Docker across multiple organizations.
Whats your thoughts on this?
Very impressive architecture. Multi-tenancy, persona-based agents, and Kubernetes scalability make this a strong foundation for enterprise AI automation. 🚀