Overview
Sylius is reviewed the way most large open-source projects are reviewed: every open pull request gets a human review, and before a task is considered done, it also gets checked against a running instance. With more than 670 contributors — around 20 of them active in any given month — and a Slack community of 6,500-plus, that verification step happens constantly, often against code nobody on the core team has time to fully vet ahead of time.
Before Bunnyshell, that verification instance was a demo environment the team built and maintained itself. Today it's an automatic, per-pull-request and per-branch Bunnyshell environment — and the demo instance is gone.
Community Background
Sylius runs an open contribution model: anyone can open a pull request, and every one of them is reviewed by the core team before merge. Because a meaningful share of that inflow comes from external contributors — people the maintainers don't have unlimited time to vet — the team leans on a running, clickable instance to confirm a change actually does what it claims, not just that it reads correctly in a diff.
That habit extends past code review, too: it's common for the team to check a proposed implementation's behavior at the review stage itself, before it's merged into anything — which made a fast, disposable environment for each PR a natural fit rather than a nice-to-have.
The Old Way: A Demo Instance Nobody Wanted to Maintain
Verifying a pull request's actual behavior meant one of two things: setting up the environment locally to try it yourself, or checking it against Sylius's own demo instance — a piece of infrastructure the team had to stand up and keep running on top of everything else. Neither option was fast, and both put the cost on the same small group of core maintainers already stretched thin reviewing external contributions.
- Checking a PR's real behavior meant a local setup, every time.
- The team's demo instance had to be maintained as its own piece of infrastructure.
- External contributions — the ones the team has the least spare time for — absorbed the most verification overhead.
- Showing in-progress work to the community meant describing it, not letting people click through it.
Bringing Bunnyshell Into the Review Loop
Sylius now gets an automatically created Bunnyshell environment for every pull request, and for individual branches where the team is building out a feature separately. Reviewers use it exactly where the old local-setup step used to sit: at code review, before a task is marked done, to confirm the implementation behaves the way the PR claims — without anyone standing up a copy of the stack by hand.
Branch-level environments cover the other half of the workflow. Because the team frequently works on several features on separate branches at once, an environment per branch lets anyone — core team, contributors, or the wider community — see a feature as it's being built, instead of waiting for it to land and be described after the fact.
The demo instance the team used to maintain itself is no longer part of the workflow at all.
What Changed
The most immediate change is the one that's easiest to overlook: a whole piece of infrastructure the core team was responsible for simply isn't there to maintain anymore.
- The self-maintained demo instance was retired — Bunnyshell environments replaced it.
- Reviewers can verify how a change actually works or looks in relatively little time, instead of setting up a local copy first.
- Feedback time for contributors on how a change behaves can be shorter, because a working environment is often already there to point to.
- In-progress features on active branches are something the team can show — to each other and to the community — rather than only describe.
Showing the Community What's Being Built
With several branches often moving in parallel, each carrying its own separate functionality, per-branch Bunnyshell environments give the community an early, hands-on look at features long before they ship. The team hears from people who value being able to check an implemented feature at that early stage — even without the workflow amounting to a rehearsed testimonial line for every contributor.
Internally, the same capability changed how the core team demonstrates its own progress: it's made it easier to show what they're currently working on, to each other and to the wider Sylius community, without waiting for a release or a write-up.
Sylius's Advice to Other Open-Source Projects
Asked what they'd tell another open-source project or company weighing whether to adopt Bunnyshell, the answer was direct: try it before committing.
On return, the team is careful to keep the claim proportionate to what they've measured: no maintaining an additional demo instance, and a faster process for verifying both entire tasks and individual external contributions.
Figures reflect Sylius's own account of its community and process, as provided for this case study; no independently audited metrics were supplied.
Want to see it in action? Watch the recorded webinar where the Sylius team walks through how they use Bunnyshell in their day-to-day review workflow.