Docker containers on Bitrise are now much easier to set up, reuse, and manage. Create container definitions in the Workflow Editor, attach them to any Step or Step Bundle, and skip the With group boilerplate entirely.
What’s new
Define containers in the Workflow Editor UI
A new Container Images section in the Workflow Editor lets you create and manage container definitions visually. For each container, you can configure:
- ID — a reference name used in your YAML and across the UI
- Docker image — the image name and version (e.g.
golang:1.22,redis:latest) - Type — execution container (runs your Steps) or service container (runs alongside your Steps)
- Credentials — username, password, and registry server for private images
- Port mappings — exposed ports for service containers
- Environment variables — custom env vars injected into the container
Changes to a container definition automatically apply everywhere it’s referenced.
Assign containers to Steps and Step Bundles
You can now attach containers directly to individual Steps or Step Bundles — replacing the need to wrap Steps in a With group.
- On a Step: Select an execution container and/or one or more service containers for any Step in your Workflow.
- On a Step Bundle: Set default containers for an entire Step Bundle. Every Step inside the bundle inherits these containers automatically.
- Override at the call site: When referencing a Step Bundle in a Workflow (or inside another Step Bundle), you can override the bundle’s default containers without changing the original definition.
New YAML syntax
The configuration YAML reflects these changes with a unified containers block and new properties:
- All container definitions (both execution and service) now live under a single top-level
containersproperty, with atypefield (executionorservice) to distinguish them. - Steps and Step Bundles gain
execution_containerandservice_containersproperties to reference containers by ID.
Why is this useful
Docker containers give you reproducible environments — the same image that passes locally is exactly what runs in CI, eliminating “works on my machine” failures.
They also make pipelines fast and isolated: spin up a clean environment in seconds, run tests in parallel without state leaking between jobs, then throw it away.
Who is this for
Docker containers give you one environment that runs everywhere — the same image your developers build locally is exactly what Bitrise runs in CI, so a passing build actually means something.
For web and backend teams, that means no more debugging why the pipeline fails on a dependency you didn’t touch. For mobile-adjacent workflows — build tooling, SDKs, shared libraries — it means the environment your build depends on is versioned, reproducible, and not quietly drifting between runs.
The teams who care most: platform engineers managing shared build infrastructure, and backend or full-stack teams whose services get tested as part of a mobile release pipeline.
How to start
Check out the guide below:
Happy building 