Community Contribution: Production-Ready Helm Chart for Coolify on Kubernetes & Potential Collaboration

[saeid-a]

Hi Coolify Team,

I hope you are doing well.

I've been working on a community project that I'm excited to share with you today. I hope to get your thoughts and explore how it could best serve the wider Coolify community.

What I've Built: A Production-Ready Helm Chart for Coolify

I've developed a community-maintained, production-ready Helm chart designed to simplify and enhance Coolify deployments on Kubernetes. The primary goal was to provide a robust and flexible solution for users looking to leverage Coolify within their Kubernetes ecosystems.

Here's a brief overview of its key features:

• Enhanced for Production:
  • High Availability & Scaling: This includes configurations for Pod Disruption Budgets (PDBs), Horizontal Pod Autoscalers (HPAs), and multi-replica setups.
  • Security & Compliance: Features automated secret generation with secure defaults, configurable security contexts, and an RBAC-ready structure.
  • Operational Excellence: Comes with health checks, automatic database migrations, and pre-configured resource requests/limits.
  • Enterprise-Ready: Supports external databases, Ingress with TLS, and stubs for monitoring integration.
• Distribution & Accessibility:
  • The chart is published and versioned via GitHub Pages, with releases automated through GitHub Actions.
• Key Fixes Incorporated:
  • It directly addresses and resolves common deployment challenges, including Redis/PostgreSQL authentication (WRONGPASS and password authentication failed), and ensures database migrations (like the instance_settings table creation) run smoothly.
• Comprehensive Documentation:
  • Includes a detailed README, deployment guides, and notes on security configurations.

Project Links:

• GitHub Repository: https://github.com/saeid-a/coolify-helm
• Helm Repository: To add, users can run helm repo add coolify-community https://saeid-a.github.io/coolify-helm

An Important Note on its Community Nature:

I've taken care to explicitly mark this as an unofficial, community-driven project in all documentation. It's clearly stated that it's not maintained by or affiliated with the official Coolify team. I intend to support and add value to the Coolify ecosystem.

Why I'm Reaching Out:

1. Transparency: First and foremost, I wanted you to be aware of this initiative.
2. Community Demand: I've seen requests and discussions around Kubernetes and Helm deployment options for Coolify, and this chart addresses a real need.
3. Feedback & Guidance: Your team's experience is invaluable. I'd appreciate any feedback, insights, or guidance you might have on this effort.
4. Exploring Collaboration (and a Potential Handover): I'm very open to discussing how this Helm chart could best fit into the broader Coolify landscape. If your team sees value in this and would be interested, I would be genuinely pleased to transition this project to become an official Coolify offering or to integrate it more formally. My primary motivation is to contribute something worthwhile.

A Few Questions for You:

• What are your general thoughts on community-led projects like this one?
• Do you have any specific guidelines or preferences for such contributions?
• Would you be open to discussing the future of this Helm chart, including the possibility of it becoming an official or officially endorsed deployment method?

My Commitment:

Regardless of the outcome, I'm committed to:

• Maintain a clear distinction between this community project and official Coolify resources as long as they remain independent.
• Ensuring users are directed to official Coolify channels for any core Coolify product support.
• Adhering to any guidelines or best practices you might suggest for community projects.

Thank you for your incredible work on Coolify and for considering this contribution. I'm looking forward to hearing your thoughts when you have a moment.

[djsisson]

I can understand wanting to replicate helm inside coolify to manage kubernetes, but maybe i'm misunderstanding a little, but since coolify service is a single digit user container where you can only run one coolify container, (why would it need/ what benefit is there) to run coolify inside a kubernetes cluster?

[saeid-a]

Hey @djsisson,

Good question! You're right, Coolify is neat as a single container. For folks already deep in Kubernetes, though, running it in K8s (like with this Helm chart) is mostly about keeping everything in one familiar place.

Think of it like this:

• Unified Ops: Instead of managing Coolify on the side, it plugs right into their existing Kubernetes setup for logging, monitoring, and network configs (like using their standard Ingress).
• Robust Backend: Even if the Coolify UI is simple, its buddies (Postgres, Redis, Soketi) get the K8s treatment—auto-restarts, and the chart even sets up things like Pod Disruption Budgets for more resilience.
• Declarative & GitOps-Friendly: Managing Coolify's deployment and configuration via this Helm chart fits the declarative, version-controlled way many K8s users operate.

So, less about scaling Coolify's UI, and more about making its whole stack play nice and robustly within an existing Kubernetes environment.

Hope that makes more sense!