Docker Compose for Production? A PaaS Idea Sparks Debate

A recent Hacker News discussion delved into the viability of a platform designed to deploy applications using docker-compose.yml files directly into a production environment. The original poster envisioned a service that would automatically handle setup tasks like HTTPS and autoscaling, simplifying the deployment of Docker Compose-based applications, including popular open-source tools.

Initial Interest and Potential Use Cases

The idea garnered notable interest. Several commenters expressed enthusiasm, with one (krstak) mentioning they already use Docker Compose for their production business applications (internal tools) and would be eager to explore such a platform. Another (ilkhan4) remarked, "I’ve always wondered why something like this isn’t a thing," highlighting a perceived gap in the market. The appeal largely stems from Docker Compose's simplicity compared to more complex orchestration tools. The ability to use the same configuration for local development and production was also seen as a significant advantage by some (dschuessler). The platform was particularly seen as beneficial for indie hackers, small startups, or individuals deploying open-source software who prioritize ease of use and low cost over the extensive features of systems like Kubernetes (jsbroks).

Significant Concerns and Challenges

Despite the interest, several critical concerns were raised regarding the practicalities of using Docker Compose in a full-fledged production setting:

• Operational Complexities: A recurring theme was the challenge of managing applications beyond initial deployment. rmdes pointed out the need for robust solutions for backups, migrations, version upgrades, and single sign-on (SSO). They referenced Cloudron as an existing project tackling similar issues, albeit with a curated app store model, and emphasized the need for smooth upgrade paths, especially when applications are used by friends or family in a 'production' context. dschuessler later clarified that the OP's proposal might place the onus of updates, SSO, etc., on the user, unlike Cloudron.
• Trust and Security: For any new PaaS, establishing trust is paramount. mmarian explicitly stated, "I wouldn't, mainly because I don't trust a new platform is secure enough," a sentiment echoed by jsbroks who acknowledged the "chicken and egg situation."
• Production Readiness of Docker Compose: A significant point of debate was whether Docker Compose, primarily seen as a development tool by some (verdverm), is truly suitable for production. verdverm questioned, "How would I express rolling updates or ingress with docker-compose?" suggesting that production environments often necessitate features not natively or easily handled by Docker Compose alone. This could lead to users needing to maintain separate, more complex Docker Compose files for production.
• The Kubernetes Standard: Several participants argued that Kubernetes is the de facto standard for container orchestration in production. verdverm asked, "Kubernetes is the standard now, why would I want to use something else?" and noted the decline of alternatives like Docker Swarm. JojoFatsani predicted that such a platform would eventually face the "death by a thousand cuts" from issues like compliance and advanced autoscaling, ultimately pushing users towards Kubernetes or managed services like AWS ECS.

Counterpoints and Niche Appeal

Proponents of the Docker Compose PaaS idea emphasized its value for specific segments. jsbroks argued that for smaller-scale deployments, the complexities of Kubernetes are unnecessary and often a barrier. The simplicity and familiarity of Docker Compose are highly attractive to users who "have an app they want to deploy and generally, as cheap as possible."

dschuessler highlighted that the primary benefits are using the same tool for local development and production, and Docker Compose's inherent simplicity. This perspective suggests the platform isn't meant to replace Kubernetes for all use cases but to serve those who find Kubernetes to be overkill.

Alternatives and Existing Solutions

The discussion also touched upon existing tools and platforms:

• Local Kubernetes Development: For those who need Kubernetes' power but want local development ease, verdverm and JojoFatsani recommended tools like kind and minikube.
• Simplified PaaS: JojoFatsani suggested Heroku as an alternative for users needing simple deployments without managing infrastructure.
• Similar Services: dschuessler provided links to services already attempting or having attempted similar concepts, such as kvmpods.com and dockerdeploy.cloud.

Conclusion

The discussion revealed a clear tension between the desire for simplified deployment mechanisms like a Docker Compose-based PaaS and the robust, feature-rich environments typically required for production applications. While there's definite interest from developers seeking simplicity for smaller projects, FOSS deployments, or internal tools, significant hurdles remain regarding operational maturity, feature completeness for production demands, and building trust. The viability of such a platform likely hinges on clearly defining its target audience and managing expectations about what can be realistically achieved with Docker Compose in a production context versus more established orchestrators like Kubernetes.