Bunnyshell Environments: Overview
Environments are the foundational concept in Bunnyshell. Everything you do on the platform — deploying code, running tests, sharing previews — revolves around environments. Watch the video above for a thorough visual walkthrough, then use this guide as a reference for the details.
What Is a Bunnyshell Environment?
At its simplest, a Bunnyshell environment is a complete, isolated deployment of your application. If your app consists of a React frontend, a Node.js API, a PostgreSQL database, and a Redis cache, then one Bunnyshell environment contains all four of those services running together, accessible via unique URLs, and completely independent from any other environment on the platform.
Under the hood, each environment maps to a dedicated Kubernetes namespace on the cluster you connect to Bunnyshell. This means environments get the full benefits of Kubernetes — resource isolation, networking, health checks, scaling — without requiring your developers to write or manage Kubernetes manifests directly.
Bunnyshell supports several environment types to cover different workflows. Primary environments are typically long-lived and represent your main branches (like main or develop). Ephemeral environments are short-lived, created automatically for pull requests or feature branches, and designed to be disposable. You can also create environments manually for ad-hoc testing, demos, or experimentation.
The Environment Lifecycle
Every environment in Bunnyshell moves through a well-defined lifecycle, and understanding these stages will help you work with the platform efficiently.
Create is the first stage. When you create an environment — whether through the UI, the CLI, or an API call triggered by your CI pipeline — Bunnyshell provisions the environment definition. At this point, no infrastructure resources have been consumed yet. The environment exists as a configuration object that knows what it needs to deploy.
Deploy is where things come to life. Bunnyshell reads your configuration, builds any container images that need building, pulls pre-built images where specified, and deploys all components into the Kubernetes namespace. Services are started in the correct order based on dependency configuration. Once the deploy completes, each service with an exposed port gets a unique URL you can use to access it.
Stop is an important cost-saving mechanism. When an environment is not actively being used — say, overnight or over a weekend — you can stop it. Stopping an environment scales down all running pods to zero, freeing up cluster resources, but it preserves the environment's state and configuration. When you are ready to use it again, you redeploy, and everything comes back up without having to rebuild from scratch. Bunnyshell can also auto-stop environments after a configurable period of inactivity.
Delete permanently tears down the environment. All Kubernetes resources in the namespace are removed, and the environment definition is archived. This is the natural end state for ephemeral environments once their associated pull request is merged or closed.
The Environment YAML Configuration
The bunnyshell.yaml file is the heart of every environment. This declarative configuration file tells Bunnyshell exactly what your application looks like and how to deploy it. It defines your components (services), their build instructions, deployment parameters, environment variables, volume mounts, and the relationships between services.
A typical YAML configuration includes three main sections. The components section lists every service in your stack, specifying whether each one is built from a Dockerfile, pulled from a registry, deployed via a Helm chart, or managed through a generic script. The environment variables section lets you define variables that are shared across components or scoped to individual services. And the configuration section controls environment-level settings like the target cluster, resource limits, and auto-stop policies.
One of the powerful aspects of this YAML-driven approach is that it lives in your repository alongside your code. This means environment configuration is version-controlled, reviewable in pull requests, and always in sync with the code it deploys. When a developer adds a new microservice, they update the YAML in the same commit, and every environment created from that branch automatically includes the new service.
Environment Variables and Secrets
Bunnyshell provides robust support for environment variables and secrets, which are essential for configuring services that behave differently across environments.
Regular environment variables can be defined at the environment level (shared by all components) or at the component level (scoped to a single service). They are visible in the UI and in logs, making them suitable for non-sensitive configuration like API base URLs, feature flags, or service discovery endpoints.
Secrets are handled differently. Bunnyshell encrypts secret values at rest and masks them in logs and the UI. You can set secrets through the dashboard or the CLI, and they are injected into your containers at runtime just like regular environment variables. This makes it straightforward to manage database passwords, API keys, and other sensitive configuration without exposing them in your YAML files or version control.
Understanding these fundamentals will make everything else in this course click into place. Environments are the container — both figuratively and literally — for all the work you do in Bunnyshell.
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 Bunnyshell environment?
A Bunnyshell environment is a complete, isolated deployment of your application stack — including all services, databases, and dependencies — running on Kubernetes. Each environment has its own namespace, URLs, and configuration, making it fully independent from other environments.
What are the main environment lifecycle stages in Bunnyshell?
Bunnyshell environments move through four primary stages: create (provision the environment definition), deploy (build and run all components), stop (pause the environment to save resources while preserving state), and delete (tear down all resources permanently).
How does the environment YAML configuration work?
The environment YAML (bunnyshell.yaml) is a declarative configuration file that defines all components, their build instructions, deployment settings, environment variables, and dependencies. Bunnyshell reads this file to understand what to deploy and how to wire everything together.