Template versioning allows you to maintain multiple versions of the same template using tags. This enables workflows like semantic versioning, environment-based deployments, and gradual rollouts.
Tags follow the name:tag format, where name is your template’s identifier and tag is the version label.
The default tag
When you build or reference a template without specifying a tag, E2B uses the default tag automatically. This means:
my-template is equivalent to my-template:default
- Existing templates without tags continue to work seamlessly
Referencing a specific build
Instead of using a named tag, you can start a sandbox from a specific build by passing its build_id directly. This is useful when you need to pin a sandbox to an exact build artifact — for example, during debugging or when reproducing an issue from a known build.
The format follows the same colon syntax as tags: <template>:<build_id> or <namespace>/<template>:<build_id>.
You can find the build_id from the return value of Template.build() or by listing tags with Template.getTags() / Template.get_tags().
You can build templates with one or more tags to create versioned builds.
Single tag
Build with multiple tags to assign several version labels to the same build artifact.
You can manage tags on existing template builds without rebuilding.
Assign new tag(s) to an existing build. This is useful for promoting a tested version to production or marking a version as stable.
Remove a tag from a template. The underlying build artifact remains accessible via other tags.
Removing a tag does not delete the build artifact. Other tags pointing to the same build will continue to work.
Retrieve all tags for a template. Each tag includes the tag name, the associated build ID, and when the tag was assigned.
Use cases
Semantic versioning
Use semantic version tags to track releases and enable rollbacks.
Use environment tags for deployment pipelines.
Maintain rolling tags that always point to specific versions.