Components Deep Dive: Helm & Kubernetes in Bunnyshell
For teams that are already invested in the Kubernetes ecosystem, Helm components in Bunnyshell let you bring your existing charts and manifests directly into ephemeral environments. Watch the video above for a practical demonstration, then read on for the configuration details and decision-making guidance.
Using Helm Charts in Bunnyshell
Helm is the de facto package manager for Kubernetes, and Bunnyshell treats it as a first-class deployment mechanism. When you define a Helm component in your bunnyshell.yaml, you specify the chart source, the version, and any values overrides. Bunnyshell then runs the equivalent of helm install (or helm upgrade on redeployments) to deploy the chart into the environment's Kubernetes namespace.
Chart sources can come from multiple places. You can reference a chart stored directly in your Git repository — useful for custom application charts that evolve alongside your code. You can point to a public Helm repository like Bitnami, which hosts production-ready charts for databases, caches, and other infrastructure components. And you can use private OCI-compatible registries if your organization maintains proprietary charts.
The key advantage of Helm components is fidelity with production. If your production infrastructure is deployed via Helm, using the same charts in Bunnyshell means your ephemeral environments are structurally identical to production. The same Kubernetes resources, the same health checks, the same resource limits, the same sidecar containers. This eliminates an entire class of "works in staging but not in production" bugs that arise from environment asymmetry.
Chart Values Override and Dynamic Configuration
The real power of Helm in Bunnyshell comes from the values override system. Helm charts are designed to be configurable through values files, and Bunnyshell gives you multiple layers of control over those values.
The simplest approach is to include a custom values.yaml file in your repository and reference it in your Bunnyshell configuration. This file can contain environment-specific settings: smaller resource requests than production (you do not need 16 GB of RAM for a preview environment), debug-level logging, test seed data configuration, or feature flags that should be enabled for development.
For more dynamic configuration, Bunnyshell supports value interpolation directly in the bunnyshell.yaml. This lets you inject runtime values — the environment's auto-generated URLs, secret references, or variables from other components — into your Helm chart values. For example, you can set your API's FRONTEND_URL to the dynamically generated frontend URL of the same environment, ensuring services within an environment are correctly wired together without hardcoded URLs.
You can also combine both approaches: a base values file for stable configuration plus inline overrides in bunnyshell.yaml for dynamic values. This layered approach keeps your configuration DRY while retaining the flexibility to adapt to each environment's unique characteristics.
Kubernetes-Native Deployments and Custom Resources
Helm components unlock the full Kubernetes API, which is something Docker Compose components cannot provide. This matters when your application depends on Kubernetes-native features.
StatefulSets are essential for databases and other stateful workloads that need stable network identities and ordered deployment. While a Docker Compose component can run a database, a Helm chart can deploy it as a proper StatefulSet with persistent volume claims, init containers for data restoration, and readiness probes that ensure the database is accepting connections before dependent services start.
Custom Resource Definitions (CRDs) are increasingly common in the Kubernetes ecosystem. If your application uses cert-manager for TLS certificates, external-dns for DNS management, or a service mesh like Istio, those are all CRD-based systems that require Helm or raw manifests to deploy. A Helm component can install these operators and their custom resources as part of your environment.
Network Policies and Ingress configurations give you fine-grained control over traffic flow. While Bunnyshell handles basic ingress automatically, Helm charts let you define custom ingress rules with annotations for specific controllers, rate limiting, authentication middleware, or path-based routing that goes beyond what auto-generated URLs provide.
When to Choose Helm Over Docker Compose
The decision between Helm and Docker Compose components often comes down to where your team is on the Kubernetes adoption curve.
If your team primarily works with Docker Compose for local development and does not maintain Helm charts, start with Docker Compose components. The learning curve is minimal, the migration is fast, and you can always add Helm components later for specific services that need Kubernetes-native features.
If your team already maintains Helm charts for production deployments, use them in Bunnyshell. The consistency between your ephemeral environments and production will pay dividends in reduced debugging time and increased confidence in deployments.
A hybrid approach is common and often optimal. Use Docker Compose components for your application services that change frequently — they are easier to iterate on — and use Helm components for infrastructure services like databases, monitoring stacks, or ingress controllers that benefit from the maturity and configurability of established Helm charts.
Ship faster starting today.
14-day full-feature trial. No credit card required. Pay-as-you-go from $0.007/min per environment.
Frequently Asked Questions
Can I use my existing Helm charts with Bunnyshell?
Yes. Bunnyshell natively supports Helm charts from any source — your own Git repository, a public Helm repository like Bitnami or Artifact Hub, or a private OCI-compatible registry. You configure the chart source and values overrides in your bunnyshell.yaml, and Bunnyshell handles the helm install and upgrade operations.
When should I use Helm instead of Docker Compose in Bunnyshell?
Choose Helm when you need Kubernetes-native features that Docker Compose cannot express: custom resource definitions, advanced networking policies, StatefulSets with specific storage configurations, or when your production deployments already use Helm and you want staging to match. Docker Compose is faster to set up but Helm gives you full Kubernetes control.
How do I override Helm chart values in Bunnyshell?
You can override values in two ways: by specifying a custom values.yaml file in your repository, or by setting individual value overrides directly in the bunnyshell.yaml configuration. Bunnyshell also supports dynamic value interpolation, so you can inject environment-specific variables like URLs and secrets into your chart values at deploy time.