Docker Compose is a great development tool. It is not a deployment strategy — but that is where most teams end up using it.
The path is always the same. Compose starts as the way a new engineer gets the project running in one command. It works. So it goes to staging, because staging is "just a bigger laptop". Then production needs to ship, the compose file already works, and nobody wants to introduce a new tool during a release week.
Now the ops model is a file that was written to make onboarding easy.
The symptoms show up later. Restarts drop in-flight work because nothing waits for the worker to finish its current task. Deploys are a short outage instead of a rollover, because there is no second instance to shift traffic to. Logs live on one host. Secrets live in the same file as the service definitions, so rotating one means editing the thing that defines your topology.
None of that means you need Kubernetes. It means the questions Kubernetes answers — how do I roll over without dropping requests, where do secrets live, what restarts a dead process, who collects the logs — still need answers. A single well-run host with systemd units, a reverse proxy, and a real secret store answers them for a lot of products.
Our rule: local orchestration and production orchestration are allowed to be different tools. Compose stays the developer's tool. Production gets whatever is chosen on purpose, even if that choice is deliberately small.
If your compose file made it to production, what forced you to change it — a failed deploy, or an incident?