Guide to Bunnyshell Components
Now that you understand environments, it is time to look at what goes inside them. Components are the building blocks of every Bunnyshell environment, and choosing the right component type for each service will determine how smoothly your deployments run. Watch the video above for a concise overview, then read on for the details that will help you make the right architectural decisions.
What Are Components?
In Bunnyshell, a component represents a single deployable unit within your environment. If your application consists of a React frontend, a Python API, a PostgreSQL database, and a Redis cache, each of those is a separate component. Components define everything Bunnyshell needs to know to build, deploy, and manage that service: the source code location, the build process, the runtime configuration, exposed ports, environment variables, and health checks.
Components are declared in your bunnyshell.yaml file, and they are the section of the configuration you will edit most frequently as your application evolves. Adding a new microservice means adding a new component. Changing how a service is built means updating that component's build configuration. The relationship between components and services is direct and intuitive.
Each component also tracks its own deployment state independently. When you redeploy an environment, Bunnyshell evaluates which components have changed and only rebuilds those. This selective rebuild behavior keeps deployment times short, even as your application grows to include many services.
The Three Component Types
Bunnyshell offers three distinct component types, each designed for a different deployment paradigm. Understanding the strengths of each type will help you build environments that are both efficient and maintainable.
Docker Compose components are the most approachable option, especially if your team already uses Docker Compose for local development. You point Bunnyshell at your existing docker-compose.yml file, and it translates those service definitions into Kubernetes deployments. This means you can go from "it works on my machine" to "it works in a shared environment" with minimal configuration changes. Docker Compose components are covered in depth in Lesson 5.
Helm components are the right choice when you need the full power of Kubernetes. If your team already maintains Helm charts for production deployments, you can reuse those same charts in Bunnyshell. Helm components give you access to the complete Kubernetes API — custom resource definitions, advanced networking, stateful sets, and anything else Helm can deploy. This type is ideal for teams with existing Kubernetes expertise who want their preview environments to closely mirror production. Lesson 6 covers Helm components in detail.
Generic components are the wildcard. They let you run arbitrary scripts as part of your environment's deploy and destroy lifecycle. This is where you handle everything that does not fit into a container: provisioning a cloud database with Terraform, configuring a third-party SaaS integration, seeding test data from an external source, or running custom infrastructure-as-code tools. Generic components are the escape hatch that ensures Bunnyshell can accommodate virtually any architecture. Lesson 7 is dedicated to this type.
Choosing the Right Component Type
The decision tree for choosing a component type is straightforward in most cases.
Start with Docker Compose if you already have a docker-compose.yml. The migration path is the shortest, and for many teams, this covers 80% or more of their services. Docker Compose components handle web servers, APIs, databases, caches, and most stateless services without friction.
Graduate to Helm when you need capabilities that Docker Compose cannot express: Kubernetes-native features like ingress controllers with custom annotations, persistent volume claims with specific storage classes, or deployments that use Kubernetes operators. Helm is also the better choice when your staging and production environments are already Helm-based and you want consistency across the board.
Reach for Generic components when the service you need is not containerized or when the provisioning logic requires custom tooling. The classic example is a managed database — you do not want to run PostgreSQL in a container for every preview environment when you could use Terraform to provision an RDS instance that behaves exactly like production.
Many real-world Bunnyshell environments mix all three types. A typical setup might use Docker Compose for the application services, Helm for an ingress controller or monitoring stack, and a Generic component for Terraform-managed cloud resources. The flexibility to combine types within a single environment is one of Bunnyshell's most powerful features.
In the next three lessons, we will take a deep dive into each component type so you can configure them with confidence.
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
What is a component in Bunnyshell?
A component is the basic unit of deployment in Bunnyshell. Each component represents a service or resource in your application — such as a web server, API, database, or background worker. Components define how that service is built, configured, and deployed.
What are the three component types in Bunnyshell?
Bunnyshell supports three component types: Docker Compose components (which use docker-compose.yml files), Helm components (which deploy Kubernetes Helm charts), and Generic components (which run custom scripts for provisioning external resources like Terraform or cloud services).
How do I decide which component type to use?
Use Docker Compose components if your team already has a docker-compose.yml for local development — it is the fastest path to Bunnyshell. Use Helm components for production-grade Kubernetes deployments or when you need fine-grained control over K8s resources. Use Generic components for anything that does not fit neatly into containers, like Terraform-managed infrastructure or external SaaS dependencies.