Open-source projects categorized as Helm | Edit details
Language filter: + Go + Mustache + Emacs Lisp + Rust

Top 23 Helm Open-Source Projects

  • GitHub repo helm

    The Kubernetes Package Manager

    Project mention: Building a Kubernetes CI/CD Pipeline with GitLab and Helm | dev.to | 2021-05-07

    Helm calls itself "the package manager for Kubernetes". That's a pretty accurate description. Helm is a versatile, sturdy tool DevOps engineers can use to define configuration files in, and perform variable substitution to create consistent deployments to our clusters, and have different variables for different environments.

  • GitHub repo charts

    ⚠️(OBSOLETE) Curated applications for Kubernetes (by helm)

    Project mention: My Journey With Spark On Kubernetes... In Python (1/3) | dev.to | 2021-04-12

    In this section, you use Helm to deploy the Kubernetes Operator for Apache Spark from the incubator Chart repository. Helm is a package manager you can use to configure and deploy Kubernetes apps.

  • GitHub repo Harbor

    An open source trusted cloud native registry project that stores, signs, and scans content.

    Project mention: Code review request | reddit.com/r/golang | 2021-05-04

    As a heads up, the entire internal/harbor directory is generated by go-swagger based on the swagger spec for goharbor.io, so don't waste too much time looking in there. Everything other than that is code that I wrote, so feel free to blame me for any ugliness that you find.

  • GitHub repo Flux

    The GitOps Kubernetes operator (by fluxcd)

    Project mention: Open source Heroku Like Platform on premises | news.ycombinator.com | 2021-03-25

    Looks really neat. We have a not-super-trivial rails app that I want to move to docker one day, but kinda scared to make the jump. We're already using docker for development, plus even have a home-grown docker-compose setup for ephemeral labs, but it's clunky at best.

    This seems like something that might provide a simple jumping board hopefully... Also bumped into fluxCD[0] recently which also looks interesting.

    [0] https://github.com/fluxcd/flux

  • GitHub repo argo-cd

    Declarative continuous deployment for Kubernetes.

    Project mention: Configuring ArgoCD on Amazon EKS | dev.to | 2021-04-17

    stages: - init - deploy variables: KUBECTL_VERSION: 1.20.5 ARGOCD_VERSION: 1.7.4 ARGOCD_ADDR: argocd.example.com # Get ArgoCD credentials from Secret Manager before_script: - export AROGOCD_TOKEN="$(aws secretsmanager get-secret-value --secret-id argocd-token --version-stage AWSCURRENT --query SecretString --output text)" # install kubectl - curl -L "https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VERSION}/bin/linux/amd64/kubectl" -o /usr/bin/kubectl # install argocd - curl -sSL -o /usr/local/bin/argocd "https://github.com/argoproj/argo-cd/releases/download/v${ARGOCD_VERSION}/argocd-linux-amd64" init demo project 🔬: stage: init when: manual image: name: amazon/aws-cli script: - argocd cluster add $BUSINESS_K8S_CONTEXT --name business-cluster-dev --kubeconfig $KUBE_CONFIG --auth-token=${AROGOCD_TOKEN} --server ${ARGOCD_ADDR} || echo 'cluster already added' tags: - k8s-dev-runner only: - master deploy demo project 🚀: stage: init when: manual image: name: amazon/aws-cli script: - sed -i "s,,$BUSINESS_K8S_CLUSTER_URL,g;s,,$CI_PROJECT_URL.git,g" application.yaml # Connect to aws eks devops cluster - aws eks update-kubeconfig --region $AWS_REGION --name $EKS_CLUSTER_NAME # Create ArgoCD project - argocd proj create demo-dev -d $KUBERNETES_CLUSTER_URL,app-dev -s $CI_PROJECT_URL.git --auth-token=${AROGOCD_TOKEN} --server ${ARGOCD_ADDR} || echo 'project already created' # Create ArgoCD application - kubectl apply -n argocd -f application.yaml tags: - k8s-dev-runner only: - master deploy demo app 🌐: stage: deploy image: name: amazon/aws-cli script: - cd envs/dev - argocd app sync demo-dev --auth-token=${AROGOCD_TOKEN} --server ${ARGOCD_ADDR} tags: - k8s-dev-runner only: - tags

  • GitHub repo k3sup

    bootstrap Kubernetes with k3s over SSH < 1 min 🚀

    Project mention: Self-Hosted single node Kubernetes: k3d? | reddit.com/r/selfhosted | 2021-05-09

    k3s works fine (running a 4 RPI cluster for more than a year now). Can be easily setup using k3sup https://github.com/alexellis/k3sup

  • GitHub repo charts

    Helm Charts (by bitnami)

    Project mention: Helm, just because? | reddit.com/r/kubernetes | 2021-05-02

    An example where Helm is much nicer to use than not using Helm: WordPress Helm chart which incidentally also explain why Artifact Hub is not that relevant: the charts are somewhere else. That particular one has 3.1k stars.

  • GitHub repo helm

    Emacs incremental completion and selection narrowing framework (by emacs-helm)

    Project mention: Is there a way to learn how to use Emacs other than the built-in tutorial? I find it hard to learn from that. | reddit.com/r/emacs | 2021-05-06
  • GitHub repo helmfile

    Deploy Kubernetes Helm Charts

    Project mention: Using Terraform to both create kubernetes clusters (AKS) and deploy helm charts in the same project - good or bad? | reddit.com/r/Terraform | 2021-04-09

    Checkout helmfile as well as an alternative to installing helm charts in terraform https://github.com/roboll/helmfile

  • GitHub repo engine

    Deploy your apps on any Cloud providers in just a few seconds (by Qovery)

    Project mention: Why you should code in Rust in 2021 | dev.to | 2021-05-06

    I hope you liked this article, and it gives you the appetite to try out Rust. If you have no idea how to start learning it, I would recommend reading the official free ebook. Then, trying to reimplement some good old academic (or not) algorithms and data structures in Rust. If you want to put your hands into dirty stuff, I can recommend contributing to my project Qovery Engine and RedisLess as well.

  • GitHub repo chartmuseum

    Host your own Helm Chart Repository

    Project mention: Ditching Docker Compose for Kubernetes | dev.to | 2021-04-06

    Another benefit of Helm is in it's package management. If your application requires another team's application up and running, they can publish their Helm chart to a remote repository like a ChartMuseum. You can then install their application into your Kubernetes by naming that remote chart combined with a local values file. E.g., helm install other-teams-app https://charts.mycompany.com/other-teams-app-1.2.3.tgz -f values-other-teams-app.yaml. This is convenient because it means you don't have to checkout their project and dig through it for their helm charts to get up and running - all you need to supply is your own values file.

  • GitHub repo devspace

    DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.

    Project mention: Improving Developer Productivity with DevSpace | dev.to | 2021-04-28

    The team at Loft has built several tools to help with developer productivity, but the best-known tool we've made is DevSpace. DevSpace is a free and open source tool that allows developers who are building apps that run in Kubernetes clusters to be more efficient. I thought it would be interesting to look at the different ways DevSpace can help with productivity in light of the SPACE framework.

  • GitHub repo porter

    Kubernetes powered PaaS that runs in your own cloud.

    Project mention: Launch HN: Porter (YC S20) – Open-source Heroku in your own cloud | news.ycombinator.com | 2021-04-30

    Hi HN! We are Alexander, Justin, and Trevor from Porter. We're building a Kubernetes-based Platform as a Service (PaaS) that deploys applications on your own cloud provider. Specifically, Porter provisions a Kubernetes cluster in your own cloud account and lets you deploy and manage applications on it through a Heroku-like PaaS layer. And although applications deployed via Porter run on Kubernetes, no knowledge of Kubernetes is necessary to use Porter. Here is our repository (https://github.com/porter-dev/porter) and website (https://getporter.dev). There was also an HN thread about us a few weeks ago, posted by someone who discovered us (https://news.ycombinator.com/item?id=26587637 - thank you OP!).

    We have known each other since high school/college and have been working on projects together full-time since 2020. When YC funded us in S20, we were building a remote development platform for teams on Kubernetes (kinda like repl.it but for microservices in particular). This was a more enterprisey product and we got burnt out by the slow sales/iteration cycle (we had zero experience with sales, let alone enterprises). So we decided to pivot a few months after demo day.

    When we were struggling to get traction with the original direction, we learned a ton by talking to engineering teams that are using Kubernetes (k8s). One thing we noticed is that there's an increasing number of startups who start on a PaaS like Heroku and end up migrating to k8s later as their applications “grow out” of Heroku, due to constraints in networking, performance, security, etc.

    While Kubernetes is great, it incurs a ton of engineering overhead. For teams who don’t know k8s at all, learning everything from scratch is daunting and time-consuming. Even if there are devops engineers on the team who are familiar with kubernetes, adopting k8s slows down developer velocity because other developers always need the devops engineers’ help to troubleshoot the slightest application issues. While we were working on our previous product, we discovered that some companies even built internal development platforms (IdP) that are much like Porter, in order to help developers deploy and troubleshoot their applications without help from the devops engineers. Our goal with Porter is to create a platform that is truly as easy to use as Heroku, without compromising the flexibility of k8s.

    There are many self-hosted PaaS's that came before Porter, such as Flynn, Tsuru, Dokku, and CapRover, which were all created before Kubernetes changed the DevOps landscape. While these are great lightweight options for smaller projects, a PaaS built on top of the k8s ecosystem comes with many benefits such as scalability, stability, configurability and interoperability across cloud providers. We believe that k8s is the best system to deliver a PaaS on, and we’re not alone - many of the new hosted PaaS’s are also built on top of k8s, although that’s an implementation detail that is usually not advertised to the user. We want to not only deliver the PaaS experience on top of Kubernetes, but also give users full ownership/control of the underlying k8s cluster by running it in their own cloud.

    This is how it works: with one click, Porter spins up a k8s cluster in your own AWS/GCP/DO account and lets you deploy and manage applications on it through a Heroku-like abstraction layer. For teams using a PaaS like Heroku, Porter can be a drop-in replacement that you don’t “grow out” of. And although our abstraction layer covers most use cases, we let those who want to customize go freely under the hood to interact with the underlying cluster. In each cloud provider, we provision the standard managed k8s offering (e.g. EKS/GKE/DigitalOcean Kubernetes), so the clusters we provision are perfectly compatible with kubectl and any other k8s tooling out there. It’s even possible to connect Porter to an existing k8s cluster - while this isn’t the primary use-case we’re building for at the moment, we’d love to discuss this use-case more in the comments if anyone is interested.

    In terms of implementation, we’ve built Porter around the Helm ecosystem, and every application you deploy is packaged as a Helm chart. For those who want more visibility, we’ve built features like “devops mode” that lets you visualize and manage the Helm charts and its underlying k8s objects.

    We’ve published Porter to be fully open source under the MIT license. We provide a hosted version that is currently in open beta, but it's also possible to run Porter locally. It’s worth clarifying that on the hosted version, the applications you deploy through Porter still run in your own cloud. What is hosted by us is only the PaaS layer, not your applications. We plan to release a self-hostable version of the PaaS layer itself in the near future, packaged as a Helm chart. We do not support this yet because self-hosting the PaaS layer inevitably incurs devops overhead and requires some knowledge of k8s, and we are currently focused on those who just want the Heroku experience without having to deal with k8s in any way.

    In terms of pricing, we are still figuring out the specifics. Our goal is to not charge individual developers/small startups but instead draw revenue from larger teams based on usage, and with premium features that are geared towards collaboration. Existing PaaS’s like Heroku/Netlify have solid examples of such premium features - review apps, pipelines, and Role Based Access Control are a few examples that we also consider to be potential premium features on Porter. That said, we are currently focused on laying out the stable foundation of the platform, so these premium features are further down on our roadmap.

    Thank you so much for reading and we'd love it if you could give it a try: https://github.com/porter-dev/porter. We'll be hanging out in the comments to hear any ideas and feedback you may have. If you have any experiences related to what we’ve built, we would love it if you could share them below. Very much looking forward to learning from you!

  • GitHub repo arkade

    Open Source Kubernetes Marketplace

    Project mention: Guess how much RAM my Raspberry Pi K3s cluster has? | reddit.com/r/kubernetes | 2021-04-05

    Take a look at arkade, it has dozens of apps that we've hand-picked because we know that they work well: https://github.com/alexellis/arkade

  • GitHub repo okteto

    Develop your applications directly in your Kubernetes Cluster

    Project mention: A Home Lab for trying Kubernetes | reddit.com/r/kubernetes | 2021-04-25

    Maybe try a "Namespace as a Service". It's far from a full k8s experience, but might be a nice place to experiment with basic deployments/services/etc. Okteto has the best dev tier that I'm aware of - up to 10 pods, 5GB of memory, 3 namespaces. Enough room to do a bit of experimentation. If you are just wanting to learn Kubernetes from a developer side, this would be an excellent option.

  • GitHub repo flux2

    Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.

    Project mention: Flux2: Continuous Delivery for Kubernetes | news.ycombinator.com | 2021-04-21
  • GitHub repo podinfo

    Go microservice template for Kubernetes

    Project mention: Example of a simple application to practice monitoring and logging | reddit.com/r/devops | 2021-04-18
  • GitHub repo kube-score

    Kubernetes object analysis with recommendations for improved reliability and security

    Project mention: Top 20 useful k8s tools | dev.to | 2021-02-20

    Link : https://github.com/zegl/kube-score

  • GitHub repo helm-charts

    Prometheus community Helm charts (by prometheus-community)

    Project mention: Configuring prometheus using helm onto a specific node in kubernetes | reddit.com/r/PrometheusMonitoring | 2021-04-28

    You set the wrong value, try --set server.nodeSelector=.... (https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml#L797)

  • GitHub repo helm-diff

    A helm plugin that shows a diff explaining what a helm upgrade would change

    Project mention: Bitnami Sealed Secrets - How To Store Kubernetes Secrets In Git Repositories | reddit.com/r/kubernetes | 2021-01-06

    So helm secrets is a helm plugin, not quite native. It requires the helm diff plugin as well.

  • GitHub repo helmsman

    Helm Charts as Code

    Project mention: Terraform/helm and environment variables | reddit.com/r/devops | 2021-03-24

    I'm using Helmsman. It's a wrapper around Helm that allows you to inject environmental variables, amongst other things. It allows me to easily inject environmental variables from my Gitlab CI/CD into my Helm release.

  • GitHub repo helm-operator

    The Flux Helm Operator, for declarative Helming

    Project mention: Auto helm (software) installations in ci/cd pipeline | reddit.com/r/devops | 2021-03-21

    You can store the values file of the helm in your repository and deploy with CI, but I personally prefer going to GitOps and Helm Operator (https://github.com/fluxcd/helm-operator) Or you can have a mixed approach where you define your HelmRelease to be deployed for HelmOperator and deploy it with CI (instead of having an operator in the cluster to apply every change in the repo)

  • GitHub repo cp-helm-charts

    The Confluent Platform Helm charts enable you to deploy Confluent Platform services on Kubernetes for development, test, and proof of concept environments.

    Project mention: An alternative or simpler way to event stream with or without Kafka | dev.to | 2021-04-30

    Now comes the challenging part. I would love to try to use Kafka to publish the events in my microservice network but geez does it become complicated there. I've found some Helm charts here which seem to be meant for development, testing, or proof of concept services but it seems to contain more than just Kafka and Zookeeper. Looking at the documentation for real production data it seems like an even more daunting task.

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2021-05-09.


What are some of the best open-source Helm projects? This list will help you:

Project Stars
1 helm 19,431
2 charts 15,069
3 Harbor 14,625
4 Flux 6,296
5 argo-cd 5,907
6 k3sup 3,264
7 charts 3,119
8 helm 3,001
9 helmfile 2,978
10 engine 2,903
11 chartmuseum 2,345
12 devspace 2,061
13 porter 1,948
14 arkade 1,736
15 okteto 1,591
16 flux2 1,568
17 podinfo 1,419
18 kube-score 1,183
19 helm-charts 1,125
20 helm-diff 1,082
21 helmsman 875
22 helm-operator 577
23 cp-helm-charts 556