Forge Containers are now available through Forge's Early Access Program (EAP). To start testing this feature, submit your app's ID to our team through this link.
EAPs are offered to selected users for testing and feedback purposes. APIs and features under EAP are unsupported and subject to change without notice. APIs and features under EAP are not recommended for use in production environments.
For more details, see Forge EAP, Preview, and GA.
The implementation of Forge Containers varies slightly from how traditional containerised services work. The following glossary helps clarify these subtle differences:
| Term | Definition |
|---|---|
| Container | A portable, self-contained unit of software. This unit contains all of the dependencies and configurations necessary to launch an isolated process used for providing capabilities for a containerised service. Containers are packaged in images, from which they can also be deployed.
In Forge, containers are defined in the manifest through the NOTE: During EAP, you can only define one service with one container, per app. Refer to the Forge Containers roadmap for a full list of EAP-specific limitations. |
| Container instance | The resulting process that runs when you deploy a container. A service instance is made up of one or more container instances. |
| Containerised service | A logical grouping of one or more containers that provide a specific capability. In Forge, a containerised service is defined in the manifest through the top-level service property; each service contains one or more container definitions.
Containerised services handle inbound and outbound requests via REST API. NOTE: During EAP, you can only define one service with one container, per app. Refer to the Forge Containers roadmap for a full list of EAP-specific limitations. |
| Forge Containers | A set of tools and capabilities provided by Forge to manage containerised services for apps. |
| Image | A read-only, immutable, and executable package containing all the code required to deploy a container. An image contains all of the code’s dependencies, including its runtime, tools, libraries, and settings. |
| Image tag | Image versions are identified by tag; in Forge, these tags are immutable. Image tags like latest won't work; we recommend using environment variables on your tagging scheme. |
| Registry | A database of container images and their different versions. In Forge, each container instance is launched from images stored on the Forge Containers registry. The Forge Containers registry is forge-ecr.services.atlassian.com. |
| Repository | A dedicated space within the Forge Containers registry for storing different versions of a container’s image. Each container will have its own repository, and Forge apps can deploy specific image versions (identified by tag).Each container repository name follows this structure:forge-ecr.services.atlassian.com/forge/${APP_ID}/${CONTAINER_KEY} |
| Service instance | The resulting hosted service that runs when you deploy a containerised service. A service instance is made up of one or more running container instances.
NOTE: During EAP, you can only define one service with one container, per app. Refer to the Forge Containers roadmap for a full list of EAP-specific limitations. |
| Resource | Description |
|---|---|
| Reference | Explore the Forge Containers API contract, along with related manifest properties, CLI tools, and logging syntax. |
| Sample app | Clone and test a sample app that shows the fundamentals of building containerised services in Forge apps. |
| Managing a containerised service | Learn how to configure, scale, and monitor services deployed on Forge Containers. |
| Integrating with a container service | Understand how to integrate Forge functions and events with containerised services. |
Rate this page: