Automating Preview Environments in Bunnyshell
One of the most powerful features of Bunnyshell is the ability to spin up a fully working preview environment every time a developer opens a pull request. No manual steps, no Slack messages asking someone to deploy a branch — just push code, open a PR, and get a live environment with a unique URL. Watch the video above for a complete walkthrough of configuring this from scratch.
Setting Up Git Provider Integration
Before Bunnyshell can react to pull request events, you need to connect your Git provider. Bunnyshell supports GitHub, GitLab, and Bitbucket out of the box. The integration works through webhooks — small HTTP callbacks that your Git provider sends to Bunnyshell whenever something interesting happens in your repository.
To set up the integration, navigate to your organization settings in Bunnyshell and add a new Git integration. You will authenticate with your provider using an OAuth flow or a personal access token, depending on the platform. Once connected, Bunnyshell registers a webhook on your repository that listens for pull request events: opened, synchronized (new commits pushed), and closed or merged.
The webhook configuration is the backbone of automation. When a developer opens a pull request, the webhook fires, Bunnyshell receives the event payload, and the platform reads the bunnyshell.yaml configuration from that specific branch. It then provisions a complete environment — containers, databases, networking, and all — using the exact code from the PR branch. This means every reviewer gets a live, isolated copy of the application reflecting precisely the changes under review.
Automatic Deploy, Redeploy, and Destroy
The real productivity gain comes from the full lifecycle automation. Here is what happens at each stage:
On PR open: Bunnyshell creates a new environment from the branch. All components defined in your environment configuration are built and deployed. Once the environment is ready, Bunnyshell posts a comment directly on the pull request with the environment URL. Reviewers can click the link and interact with the running application immediately — no local setup required.
On push to the PR branch: When a developer pushes new commits to the branch, the webhook fires again. Bunnyshell detects the change and automatically redeploys the affected components. Only the components whose source code changed are rebuilt, which keeps redeploy times short. This means the preview environment always reflects the latest commit on the branch.
On PR merge or close: When the pull request is merged into the main branch or closed without merging, Bunnyshell automatically destroys the preview environment. All cloud resources are released. This is critical for cost management — you never end up with dozens of forgotten environments burning through your cloud budget.
Pipeline Integration Patterns
While the webhook-based approach works out of the box, many teams prefer to integrate Bunnyshell into their existing CI/CD pipelines for finer control. You can trigger Bunnyshell environment operations from GitHub Actions, GitLab CI, or Bitbucket Pipelines using the Bunnyshell CLI or API.
A common pattern is to add a step in your CI pipeline that calls bns environments create after your test suite passes. This way, preview environments are only created for PRs that pass basic quality checks. Another pattern is to run end-to-end tests against the preview environment URL before marking the PR as ready for review.
The PR comment feature deserves special attention. When Bunnyshell posts environment URLs as pull request comments, it creates a frictionless review workflow. QA engineers, product managers, and designers can all access the running application without any technical setup. The comment is updated automatically if the environment URL changes, and it is marked as resolved when the environment is destroyed.
Teams that adopt automated preview environments typically report shorter review cycles, fewer "works on my machine" issues, and significantly less time spent on environment management. The initial setup takes about fifteen minutes per repository, and the ongoing maintenance is essentially zero — Bunnyshell handles provisioning, updates, and cleanup automatically.
For organizations managing multiple repositories or monorepos, Bunnyshell supports configuring automation rules at the project level. You can define which branches trigger environment creation, set naming conventions for environments, and configure resource limits to control costs across the team.
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
Which Git providers does Bunnyshell support for automated preview environments?
Bunnyshell supports GitHub, GitLab, and Bitbucket. Each provider uses webhooks to notify Bunnyshell when pull requests are opened, updated, or closed, triggering automatic environment creation, redeployment, or teardown.
Will automated preview environments increase my cloud costs?
Not significantly, because Bunnyshell automatically destroys preview environments when the associated pull request is merged or closed. This means environments only exist for the duration of the review cycle. You can also configure auto-stop timers to hibernate idle environments, further reducing costs.
Can I customize what gets deployed in an automated preview environment?
Yes. The environment configuration is defined in your bunnyshell.yaml file, which lives in your repository. Each branch can have its own configuration, so preview environments reflect the exact changes in that pull request — including infrastructure changes, new services, or updated environment variables.