Today, we’re excited to announce a big milestone for Forge container services: the official Preview release. Apps using containerised services can now be deployed to production environments, published on the Atlassian marketplace, and distributed to customers.
Forge container services does what it says on the tin—you can run container images directly on Forge infrastructure as persistent web services. Now, you can choose the runtime that makes sense for you: Forge functions for event-driven tasks or containers for long-running processes and multi-language support.
Forge container services opens up a much wider range of backend architectures on Forge. That’s good news for developers with existing apps because you don’t need to completely refactor them for serverless. You can run microserviced apps in the languages and frameworks you already use, while still getting the benefits of Forge’s automatic data residency and the Runs on Atlassian badge.
For the past few months, the developer community has put container services through its paces in Early Access, and we’ve done our own large-scale dogfooding at Atlassian. We’re excited to make Forge container services available for broader adoption and production use.
Choose the runtime that works for you
Forge container services is a major evolution of Forge’s compute capabilities. When we originally built Forge, we optimized for a frictionless developer experience. The original runtime, based on serverless functions, made it quick and easy for developers to ship code without having to think about provisioning, scaling, or maintenance.
While functions are great for event-driven tasks, they aren’t the right fit for every workload. Over time, we added features to make Forge functions more robust, including async processing, longer timeouts, and more resources inside the Lambda.
But many developers build backends in languages Forge functions don’t support, or their architectures may rely on long-running processes that just don’t map well to a serverless model. That’s where Forge container services come in.
Who’s a good fit for Forge container services?
Forge container services is a great choice for developers who want to run existing services on Forge infrastructure without a complete backend rewrite. It’s also ideal for developers who want to build new use cases on Forge that can’t be satisfied with Forge functions.
This is especially relevant for:
- Partners migrating from Connect with existing backends that can’t feasibly be rewritten for serverless functions
- Developers using languages and runtime dependencies outside the current Node.js runtime supported by Forge functions
- High-volume or resource-intensive workloads that need sustained compute rather than short-lived invocations
What’s available in Preview
With Forge container services, you get a full container lifecycle managed end-to-end on Atlassian infrastructure. It includes a private container repository you can push images to, a manifest-driven deployment model, observability of deployed services via the Forge developer console, and a comprehensive REST API your container image can use to interact with the rest of the Forge platform and the outside world.
At a high level, you build a container image that packages your code and dependencies (you can choose your own platform and tools for this, such as Docker desktop). Then, you upload the image to Forge’s private container registry using docker push. When you deploy your app, Forge launches your containerised service based on the image in the registry, selected by the tag specified in your manifest.
Forge container services includes built-in features for security and reliability. To ensure zero downtime, we use a blue/green deployment strategy between stable and canary versions, and all container instances are deployed with restricted file system permissions for enhanced security.
Forge container services can support any language or framework that can run on Linux/amd64, but there are image security requirements to be aware of. Check the docs to explore the full set of capabilities as well as platform constraints.
It’s also important to note that the Forge container service is now a billable capability. Visit the pricing page to learn more.
Signals and examples from the Early Access Program
During the Early Access program, we worked closely with developers to co-design Forge container service according to their requirements and test stability and readiness. The Early Access program has shown steady developer activity, as teams built and iterated on apps for real world use:
- 56 apps deployed in the last 30 days
- Over 30 developers working with containers each week
- 500 deployments per week, with over 2,000 container service deployment events in the last 30 days
For some, a path to isolated cloud
Several partners in the Early Access Program have used containers to build isolated cloud versions of their applications on Forge. This is a practical path for existing Connect apps or apps with complex architectures to become compatible with isolated cloud, where data egress vectors are subject to higher customer scrutiny. These examples show that sophisticated architectures can run on Forge and meet the advanced requirements of isolated cloud customers.
Here are a few early adopter apps, already using container services in isolated cloud:
- Rich Filters for Jira Dashboards by Appfire
- Include from GitHub to Confluence by Elevatic
- Structure by Tempo, Gantt charts for Structure PMM, and Tableau Connector for Jira by Tempo
- Refined Sites for Confluence by Refined
Dogfooding containers with the ShipIt app
Atlassian’s Hackathon for Jira App powers Atlassian’s regular ShipIt ritual. It was previously an Atlassian Connect app with a Haskell backend. Migrating the app to Forge was challenging, because rewriting the backend for Forge functions was not realistic. Containers enabled the Atlassian team to migrate to Forge without replacing the existing backend, allowing it to run on Forge for the first time.
We put it to the test during our 62nd global ShipIt, where the app served hackathon teams and thousands of Atlassian staff worldwide as they voted for their favorite projects. Running on Forge container service provided an opportunity to rightsize resource provisioning and reduce costs, and we saw a 0.003% error rate under sustained regional voting waves.
What’s next
We’re excited for more developers to use Forge Container services in production and help shape the service ahead of general availability.
Over the next few months, we have lots more goodness coming on the roadmap: further observability enhancements, support for Bitbucket Cloud modules, and further iterations based on your valuable feedback. We’re also targeting a release of Forge Container services in Atlassian Government Cloud next year.
Get started now and help shape what ships next.
