What teams run on it

For reviewers and engineering managers

The pipeline stands up a full copy of your application for each pull request, built from that commit, beside the real database and the real neighbours. Reviewers click through the change instead of imagining it from the diff. On merge, the copy is gone.

For developers

One command stands up a full copy of the application on the team's Docker hosts, with your branch's build in place of one service and everything else at the versions the team runs. No laptop that cannot fit the stack, no waiting for staging.

For developers

Run the service you are changing in your IDE, with breakpoints, against the team's database, identity provider and broker. fadebox connect puts each of them on localhost on its own port, through Fadebox itself: no VPN, no client to install beyond the CLI, on Linux, macOS and Windows.

For QA and release managers

Clone the environment for the release, pin its versions and protect it, so nobody's afternoon edit changes what is under test. Run as many copies as you have suites, side by side, and reset any of them to a clean state in minutes.

For sales

Every prospect gets their own copy of the product, seeded and branded, on its own URL, cloned from a blueprint your team keeps known-good. It stops by itself when the trial is over. Nobody borrows staging, and nobody asks engineering.

For support

A customer on last quarter's release reports a bug. Support brings up a copy pinned to that exact version, reproduces the report in minutes and pastes the URL into the ticket. The developer opens the same URL and starts the hotfix from what they see.

For trainers

One environment defines the lab. Each attendee gets their own instance of it, with their own seed data and URL, from the moment they sit down. The trainer can reset any lab in minutes, and every lab stops on its own after the course.