threeport: a platform engineering foundation

Threeport: A Platform Engineering Foundation

By Richard Lander, CTO | May 3, 2024

Threeport is an open source application orchestrator. It is used to manage and coordinate the delivery of your applications. Application delivery, to be useful, must include the dependencies your app needs to run. Threeport manages the following dependencies for your application:

  • Cloud provider infrastructure.
  • Kubernetes clusters.
  • Managed service dependencies in your app stack, such as managed databases.
  • Support service dependencies that run in your Kubernetes clusters to handle network ingress, TLS termination, DNS record management, observability, secrets, etc.

You can think of Threeport as a programmable delivery engine. It is an alternative to pipeline-based delivery with continuous delivery or GitOps.

Threeport is also a foundational component for a modern cloud native application platform. Let's explore what an app platform is to expand on that idea.

What is an Application Platform?

This topic warrants its own blog post, but the TL;DR is that an app platform exists to deliver your software to its end users.

We're not talking about development here. Development platforms such as GitHub provide the code repositories, CI pipelines and collaboration tools to enable your teams to produce releases of their software. The end result of the development cycle is a deliverable asset. In a cloud native environment, that deliverable asset is usually a container image that has been pushed to a registry.

This is where the app platform comes in. The job of an app platform is to pull the deliverable asset - the container image - and start the workloads in their runtime environment with their dependencies satisfied so that end users can access the application. Naturally, the app needs to be monitored and maintained, and any problems that come up must be attended to. So, an app platform must support the ongoing care and feeding of an application, including fixes and upgrades.

Many organizations use Platform-as-a-Service (PaaS) offerings to access these capabilities. Good PaaS offerings make this process smooth and fast. The challenge is that many teams eventually encounter the limitations that are inevitably inherent to the system. As their application accumulates requirements to satisfy the needs of its end users, the app architecture must evolve to accommodate those requirements. A PaaS offering will always have a finite set of use cases they support, and if you find you need features they don't offer, you have to find a solution. This is why platform engineering as a discipline has been growing more prevalent.

What is Platform Engineering?

Platform engineering is the engineering of an application platform. Many organization have turned to platform engineering to meet the delivery needs of the software they build. As their software becomes more sophisticated, it commonly requires custom features in the application platform that delivers it. And when those features are not available out of the box with a particular service, they are increasingly turning to building those features themselves. If you'd like to dive into the topic of platform engineering some more, check out our blog post: What is Platform Engineering?

Kubernetes is Not an Application Platform

Kubernetes is a very capable container orchestrator and is commonly used in platform engineering. However, at the risk of stating the obvious, Kubernetes is not an app platform in and of itself. Not even close. It is really just the foundation for a cloud native runtime environment. There are many support services that need to be installed on Kubernetes to make it ready for an application to run there.

Kubernetes provides an API and abstraction layer to manage your workloads for a single environment in a single geographical location. It provides automated scheduling of workloads to machines in a cluster and gives you integration points to enable features such as autoscaling and resilience to machine failures.


To summarize, Kubernetes allows a cloud native runtime environment in a location to be managed through an API. It is a wonderfully useful system, but it is a container orchestrator, not an app platform. It is just a component of an application platform.

If you'd like to dive into the topic of Kubernetes, checkout the following blog posts:

Last, but certainly not least, Kubernetes is extensible. It can be programmed to provide features that service your high value workloads specifically. The Kubernetes operator pattern is a powerful way to massively increase the reliability of your software while reducing the operational toil required to manage cloud native apps. For more information on this topic, see our blog post: What is a Kubernetes Operator?

Threeport is Not an Application Platform

As I said at the beginning of this post, Threeport is an open source application orchestrator. Its job is to provide an abstraction to all your runtime environments and satisfy the dependencies to your applications.


With Threeport you get a global abstraction that allows you to manage the infrastructure and Kubernetes clusters for every environment in every region where you need to have a presence. It also orchestrates the provisioning and installation of the support services you need on Kubernetes to support your workloads as well as the managed services for your apps.

Threeport is the place to orchestrate concerns that span clusters and regions. This includes variations in configuration between dev, test, and prod to provide smooth promotion of versions across environments. It also includes cross regional failovers where needed. It allows for elegant coordination of configurations across your regions and Kubernetes clusters. It provides a unified system for integrating all these components so your application runs happily with all of its dependencies satisfied.

Threeport provides orchestration of application delivery but it is still not a complete application platform for most use cases. A complete app platform will also require the following:

  • AuthZ and AuthN: Integration with 3rd party identity providers, role-based access control (RBAC) and attribute-based access control (ABAC) are necessary to provide the appropriate secure access to team members. But they also vary widely in their implementations and requirements between organizations. Therefore, Threeport does not implement these systems and recommends using a proxy to the Threeport API to implement these systems.
  • Graphical User Interface: Threeport provides a command line interface to interact with Threeport, but that is not satisfactory for all users. Again different organizations have varying requirements for this. A backstage plugin may be appropriate for some. Or a custom front end that makes calls to the Threeport API may be the preferred interface for others.

Once again, last but not least, Threeport is extensible. Threeport can be programmed to provide the custom abstractions many organizations need. A full-featured application platform is not complete without the ability to extend it to meet custom requirements. Threeport has a (soon to be released) software development kit (SDK) that offers the opportunity to do this. Threeport can be extended today, but there are currently limitations to pluggability with custom controllers. We are working hard to make the SDK generally available with a fully pluggable system that allows you to integrate any number of custom integrations.

One Size Never Fits All

PaaS offerings are an endangered species. Their inherent limitations to extensibility will consistently lead growing organizations to one of these places:

  • Abandoning features that are too difficult (or impossible) to implement on the platform.
  • Awkward workarounds to meet requirements not supported - or partially supported - by the platform.
  • Re-platforming to a custom platform that meets their requirements. This can be a crippling mountain of toil today. The work to build the custom platform is just the beginning. The configurations for the workloads need to be migrated and the workloads themselves need to be moved without disrupting users.

When open source platform engineering tools make it as easy to get started with an extensible system as it is with a PaaS, the value proposition for a PaaS diminishes and even evaporates entirely. If you can get up and running quickly on a vastly capable platform with a simple use case, and never have to worry that the platform won't support your growing needs, why would you pay for something you could outgrow?

Kubernetes is extensible and open sourced. There are now many managed service providers that offer Kubernetes services. SDKs like Kubebuilder and Operator Builder make it faster than ever to get useful Kubernetes operators into action.

Threeport is extensible and open sourced. Currently, there is only one managed service provider for Threeport but that will change with growing adoption. And we'll soon be releasing the Threeport SDK for custom abstractions that will provide the customizations needed for growing organizations to succeed in bringing truly self-service app platforms to their developers and operations teams.

Platform engineers are very close to having the complete toolkit needed to make PaaS extinct.


Qleet is currently the only provider of managed Threeport control planes. At Qleet, we can help you get up and running with Threeport in short order. If you are developing cloud native applications and looking for the optimum way to seamlessly deliver them, visit our website and click the button to get started.