Have you ever heard a developer say, “It works on my machine”?
It’s a common phrase in software teams — and a common source of frustration.
We want to help you put an end to that problem.
We’re excited to introduce ephemeral environments in Octopus. They let you test changes in an isolated, temporary environment before merging them into your main branch. You can check your changes where they matter, reduce surprises later, and keep infrastructure costs under control.
Why use Ephemeral Environments?
- Faster feedback: Test changes in isolation so you know they work before merging.
- Lower costs: Automatically remove unused infrastructure to avoid unnecessary spend.
- Scalable: Use the same approach for pull request reviews, feature testing, or cross‑project testing.
- Integrated: Works with your existing Octopus projects, deployment processes, and infrastructure automation.
How it works
Once you’ve set up Octopus for ephemeral environments:
Spin up an ephemeral environment for any feature branch by creating a release via the Octopus Portal, API, CLI, or GitHub Actions, so you can preview and test changes in real time.
Once the environment is no longer needed, it can be spun down in the portal, or via the API as part of a CI workflow triggered from the merge or close of a pull request.
Getting started
Getting started is quick. The guided setup wizard walks you through the process using familiar Octopus concepts.
1. Configure your parent environment
The parent environment is a new concept. It lives in your space alongside your other environments and helps you:
- Scope variables, accounts, and permissions.
- Prevent environments being left running after they are finished being used.
You can’t deploy to a parent environment directly — it’s only there to define settings. By default, ephemeral environments automatically deprovision after 7 days of inactivity, but you can:
- Change the time limit to suit your needs.
- Disable auto‑deprovisioning (not recommended — it helps keep your environment count, and costs, low).
Inactivity means no deployments or runbooks have been run against the environment in that time.
2. Define a naming template
Environment names are automatically generated from a configurable Environment Name Template using Octostache variable syntax .
The name is the quickest way to know which environment belongs to you. We recommend making them as specific as possible to avoid name clashes.
3. Provision and deprovision with Runbooks
When you create an environment, Octopus runs your provisioning runbook first to set up the infrastructure.
When you remove an environment, your deprovisioning runbook tears it down to keep things tidy. This ensures your test setups don’t leave behind forgotten resources. Runbooks are optional, depending on your current infrastructure set up.
Multi-project support
Ephemeral environments support multiple projects meaning you can share ephemeral environments — just configure them with the same parent environment. This will allow you to test multiple services in the same environment ensuring consistency across your testing process.
Keep in mind:
- Environment names must be unique across the space.
- If two projects create an environment with the same name, they’ll share it.
- Deprovisioning is flexible — you can choose to remove it entirely or only for the current project.
Availability
Early access is available now for Octopus Cloud customers.
- Cloud: early access now, general availability in mid‑October 2025
- Self‑hosted: early access in the 2025.3 release, general availability in the 2025.4 release
If you’re self‑hosted and want early access, reach out to your account manager or reach out to harriet.alexander@octopus.com
Current limitations
The following limitations apply for the Ephemeral Environments feature:
- Cannot manually create and provision ephemeral environments.
- Limited API and CLI support
Happy deployments!
Tags:
