Forge Container services is now in Preview, and therefore fully supported. However, it remains under active development and may be subject to shorter deprecation windows. Preview features are suitable for early adopters in production environments.
We release preview features so partners and developers can study, test, and integrate them prior to General Availability (GA). For more details, see Forge EAP, Preview, and GA.
Unlike other Forge capabilities that use a consumption-based pricing model, Forge Container services use a reservation-based pricing model. You pay for the CPU and memory capacity reserved for each container instance, regardless of whether that instance is actively handling requests. This reflects the always-on nature of container services, which must remain running to serve traffic at any time.
Forge Container services pricing is now active. See the unit pricing below for details.
No free usage allowance: Unlike other Forge capabilities, Forge Container services do not include a free monthly usage allowance. All reserved CPU and memory capacity is billed from the moment billing is enabled at Preview.
Forge Container services are billed based on two dimensions: compute (vCPU) and memory (GiB), measured per hour.
| Metric | Unit | Price (USD) |
|---|---|---|
| Compute | vCPU-hour | $0.07177 |
| Memory | GiB-hour | $0.00786 |
Charges are calculated based on the CPU and memory values declared in your service manifest, not on actual runtime utilization. Although billing uses an hourly unit, consumption is sampled at 1-minute intervals and aggregated into hourly totals.
Forge Container services are deployed across multiple Atlassian regions to deliver adequate performance for your app's users and to support data residency requirements. Because each region runs its own container instances, your costs scale with the number of regions your service is deployed in.
When Forge Container services enters Preview with billing enabled, your container services will be automatically deployed in the following 6 Atlassian regions:
| Region | Location |
|---|---|
| Asia Pacific | Singapore |
| Australia | Sydney |
| Europe | Dublin |
| Europe | Frankfurt |
| US East | North Virginia |
| US West | Oregon |
These 6 regions balance performance coverage for the widest range of customers against cost to app developers. This is a deliberate trade-off against deploying across all 12 Atlassian data residency locations. Atlassian will monitor performance and may adjust the regional footprint over time if needed.
To estimate your monthly costs, multiply the reserved CPU and memory per container instance by the unit prices above, then multiply by the number of instances per service (controlled by the min/max settings in your manifest), the number of active regions, and the hours in the month.
Example: A service configured with 0.5 vCPU and 1 GiB memory, a minimum of 1 instance per region, running in all 6 regions for a full 730-hour month:
| Dimension | Calculation | Cost |
|---|---|---|
| Compute | 0.5 vCPU × $0.07177 × 1 instance × 6 regions × 730 hrs | $157.18 |
| Memory | 1 GiB × $0.00786 × 1 instance × 6 regions × 730 hrs | $34.43 |
| Total | $191.82/month |
The cost optimizations described below can significantly reduce this figure for most apps — particularly for non-production environments and apps with a limited geographic footprint.
The following optimizations help minimize running costs for Forge Container services. Some are applied automatically by the platform; others can be configured directly by you as the app developer.
Container services in non-production environments (development and staging) automatically scale to zero running instances when they are idle. This means you are not charged for non-production container instances when they are not actively processing requests.
For production environments, a minimum of 2 running container instances per service is recommended to ensure high availability. Running fewer than 2 instances in production is not advised.
Container services are not deployed in regions where your app has no installations. If your app has no users in a given region, no container instances will run there, and no costs will be incurred for that region.
Provisioning and de-provisioning happen dynamically and automatically: when the first installation in a region is added, the service is provisioned there; when the last installation in a region is removed, the service is de-provisioned. This requires no developer intervention and no new forge deploy operation.
Automatic de-provisioning is not yet available in Preview. To de-provision a service from a region, open a support ticket. See Managing containerised services for more details.
The vertical and horizontal scaling profile of Forge Container services can be customized per environment and per region. This allows you to:
Per-environment and per-region scaling configuration is not yet available. Documentation will be added to the Forge Container services manifest reference when this capability ships.
Rate this page: