Components Deep Dive: Docker-Compose in Bunnyshell
Docker Compose is the most popular way to define multi-service applications for local development, and Bunnyshell is designed to make the transition from local Compose to cloud environments as seamless as possible. Watch the video above for a hands-on demonstration, then use this guide as your reference for the nuances and best practices.
How Bunnyshell Translates Docker Compose
When you configure a Docker Compose component in Bunnyshell, you point it at a docker-compose.yml file in your repository. Bunnyshell parses that file and translates each service definition into the equivalent Kubernetes resources: Deployments, Services, ConfigMaps, and PersistentVolumeClaims.
The translation is remarkably faithful to the original Compose file. A service with a build directive gets a container image built from the specified Dockerfile and context. A service with an image directive pulls that image directly from the registry. Port mappings defined with ports become Kubernetes Services with the appropriate port forwarding. Environment variables defined under environment or loaded from env_file are injected into the containers just as they would be locally.
This means that in most cases, the docker-compose.yml you already use for local development works with Bunnyshell with little or no modification. The application that runs on your laptop with docker compose up runs in a Bunnyshell environment on Kubernetes — same services, same configuration, same behavior.
Volumes, Networking, and Environment Variables
While the core translation is straightforward, there are three areas where the shift from local Docker to cloud Kubernetes introduces meaningful differences.
Volumes are the most common source of questions. In local Docker Compose, you often mount your source code directly into the container using bind mounts (e.g., ./src:/app/src) for hot-reloading during development. Since Bunnyshell runs on a remote Kubernetes cluster, there is no local filesystem to mount. Named volumes translate cleanly into Kubernetes Persistent Volume Claims, and your data persists across redeployments. For source code syncing during active development, Bunnyshell offers a remote development feature that synchronizes your local file changes to the running container in real time — giving you the same hot-reload experience you are used to, but running on cloud infrastructure.
Networking is actually simpler in Bunnyshell than in local Docker Compose. In a Compose file, services communicate using service names as hostnames — api can reach db by calling db:5432. Bunnyshell preserves this exact behavior. Services within the same environment resolve each other by their Compose service name, so your application code does not need any networking changes. External access is handled by Bunnyshell's ingress layer, which automatically generates public URLs for services with exposed ports.
Environment variables work as expected with one important addition. Beyond the variables defined in your Compose file, Bunnyshell lets you override or inject additional variables at the environment level. This is useful for switching between configurations — pointing your API at a different database, enabling debug logging, or toggling feature flags — without modifying the Compose file itself.
Build vs. Image and Multi-Service Setups
Bunnyshell supports both build and image directives in your Compose file, and understanding when to use each one can significantly impact your deployment speed.
Services defined with build are built from source every time their code changes. Bunnyshell uses an integrated build pipeline that supports layer caching, so subsequent builds are faster than the initial one. This is the right choice for your application services — the frontend, API, and workers whose code changes frequently.
Services defined with image pull a pre-built image from a container registry. This is the right choice for infrastructure services like databases, caches, and message queues. PostgreSQL, Redis, RabbitMQ, and Elasticsearch do not need to be built from source — pulling the official image is faster and more reliable.
For multi-service setups, declare all your services in the same Compose file and Bunnyshell will deploy them together as a single component. The dependency ordering defined with depends_on is respected during deployment, so your database will be running before your API tries to connect to it.
A practical best practice: keep your Bunnyshell Compose file as close to your local development Compose file as possible, but do not be afraid to maintain a separate docker-compose.bunnyshell.yml if you need different settings for cloud deployment. Some teams use a shared base file with an override file for Bunnyshell-specific configuration, which keeps duplication minimal while allowing the necessary differences.
One final tip — watch your resource requests. Locally, Docker can use as much RAM and CPU as your laptop allows. In Kubernetes, containers without resource limits can starve other services. Setting explicit memory and CPU limits in your Compose file (or in the Bunnyshell configuration) will prevent one hungry service from destabilizing the entire environment.
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 docker-compose.yml with Bunnyshell without changes?
In most cases, yes. Bunnyshell reads your docker-compose.yml and translates it into Kubernetes resources. Standard features like services, ports, environment variables, and build contexts work out of the box. Some Docker-specific features like host volume mounts need minor adjustments for the Kubernetes environment.
How does Bunnyshell handle Docker Compose volumes?
Bunnyshell translates named volumes into Kubernetes Persistent Volume Claims, which means your data persists across redeployments. Host-mounted volumes from your local docker-compose.yml are handled differently — Bunnyshell uses its remote development feature or init containers to sync files rather than mounting your local filesystem.
What Docker Compose features are not supported in Bunnyshell?
Most standard Docker Compose features work, but a few host-dependent features behave differently. Docker-in-Docker setups, host network mode, and privileged containers may require adjustments. Bunnyshell documentation covers these edge cases with recommended workarounds.