What Are the Best Tools for Automatic Environment Updates on Every Push?
GuideSeptember 25, 20263 min read

What Are the Best Tools for Automatic Environment Updates on Every Push?

Short answer: Bunnyshell environments update automatically on every push to a PR branch — a Git webhook fires, Bunnyshell matches it to the ephemeral environment tracking that branch, and triggers a redeploy, with no CI configuration required on your side.

The Mechanism

Bash
bns environments update-settings --id <PRIMARY_ENV_ID> \
  --auto-deploy-ephemerals

Once set, every push to a tracked PR branch redeploys the corresponding ephemeral environment automatically. This is enforced at the Bunnyshell platform level, not something a workflow YAML file has to implement per repository.

Why It Stays Fast

A common concern: doesn't redeploying on every commit get slow and expensive? Bunnyshell's deploy pipeline only rebuilds components whose source actually changed — confirmed directly against a real pipeline, where a full 8-job initial deploy completed in 96 seconds:

Bash
1$ bns pipeline show --id OG7nYbkwM3
2Stages | Name  | Duration | Jobs | JobsDone | Status
3       | Stage | 1m36s    | 8    | 8        | success

A follow-up push touching only one component triggers a much smaller subset of those jobs, not all eight again.

The One Thing to Add Yourself

Since a new push redeploys mid-review, add a CI concurrency setting so an in-progress test run against the old code gets cancelled rather than reporting stale results:

YAML
1concurrency:
2  group: e2e-${{ github.event.pull_request.number }}
3  cancel-in-progress: true

For the full mechanics — including debugging a push that didn't trigger a redeploy — see Webhook-Triggered Environment Updates.

Frequently Asked Questions

Does every push trigger a full environment rebuild?

No. Bunnyshell diffs component sources and only rebuilds what changed, so a frontend-only commit does not force a backend or database redeploy — updates typically land in tens of seconds, not minutes.

Do I need to add a step to my CI workflow for this?

No. The update is triggered by Bunnyshell's own webhook listener reacting to the Git provider's push event, independent of your CI pipeline configuration.

What happens if a redeploy is triggered while an E2E run is in progress?

That is a CI-level race condition worth handling with a concurrency/cancel-in-progress setting on your test job, so results are never reported against code a new push has already superseded.