We've banned compose.yaml from every project

When we tell development teams that none of our projects has a compose.yaml in it any more, we get two reactions: agreement from those who know the pain, and raised eyebrows from those who still see it as part of the solution. Both are understandable. In this post we want to describe honestly why we made this decision, what it has gained us and what it concretely means for our clients.

It used to be the same with us as almost everywhere. Every project had its own compose.yaml. It described which database was needed, which cache, which search service, which developer ports were taken. That felt good because it was visible. But it was also the source of many small permanent building sites that, in everyday life, added up to real cost.

Why project-local compose files become so expensive

The fundamental problem isn't Docker Compose as a tool. The fundamental problem is what happens with it in practice. Every team eventually maintains its own version, every version drifts slightly from the next. You end up with projects on PostgreSQL 14 next to projects on 16, Redis in four different configurations, one project binding port 5432 locally, another 5433, a third 54321. Anyone switching between two projects spends an hour getting their developer machine running again.

Add to that the security side. Secret handling in project-local compose files is brittle. Developers copy configurations, forget that there's a real token in there, push branches, rotate nothing. The services themselves are rarely hardened, because every project compose file is its own building site and changes would have to be applied 40 times.

And finally, fragmentation costs operational time. If every application brings its own local dependency landscape, the difference between dev and production environments is hard to control.

What we do instead

We centrally operate a development service platform that, in the form of pre-configured, versioned services, covers everything our projects need as infrastructure. Databases, caches, search indexes, message queues, object storage emulations. These services run in a shared orchestration that we maintain, not in 40 individual compose.yaml files living in 40 projects.

The projects themselves no longer contain infrastructure definitions, only a declarative description of what they need. Which database engine in which version, which cache type, which ports through a central allocation, which secrets through the central secret manager. Allocation and start-up are handled by our platform layer. The development team starts its project and gets a working, hardened set of services with it, without ever having to deal with port conflicts or YAML drift again.

Three concrete improvements we measure

1. Onboarding in hours rather than days

New team members or external developers working with us on a project have their environment running in under an hour. Previously, one to two days was standard, often more.

2. Security as a product of the platform

Hardening on our services only has to be done once. TLS, authentication, network segmentation, update paths. That then takes effect for all projects at once. The attack surface in the projects themselves shrinks, simply because there's much less configuration living there.

3. Dev-prod parity without manual work

Because the service versions are maintained centrally, the difference between development, staging and production is small and documented. “It works on my machine” arguments become rarer, and when they do come up, we find the deviation faster.

What this means for our clients

For you as a client, this decision is invisible at first, and that's a good thing. You don't notice the difference in a YAML file, you notice it in the speed at which new development gets going with us, in the reliability of releases, and in the fact that security updates to base services with us aren't a project but a platform routine.

The approach is another building block in our principle of “standardised individuality”. We reduce variance where it doesn't create value, in order to free up capacity for genuine individuality: for your content, your integrations, your business logic.