Cdk8s is a great tool to write your Kubernetes IaC templates using standard programming languages. But unlike the AWS cdk, which is tightly integrated with CloudFormation to manage stack deployment, cdk8s has no native deployment mechanism.

By default, it allows you to synthesize manifests and deploy them using kubectl apply, or optionally through Helm. While both approaches can work, they often fall short for more advanced use cases — for example, when you want to programmatically chain deployments, export values from the chart, or implement a custom rollback and prune strategy.

In this blog post, we’ll explain how we built a model-driven orchestrator for cdk8s using Orbits — a lightweight framework for orchestrating cloud resources and workflows. We’ll show how you can use it, adapt it to your own needs, or even build your own orchestrator based on the same principles. If Orbits fits your use case, you can directly reuse what we’ve built.

If you've ever tried to build a multi-account AWS architecture using CDK or CloudFormation, you've probably hit the same frustrating wall: cross-account resource references don't work without manual coordination and hardcoded values. What should be a simple task—like reading a parameter from Account A in a Lambda function deployed to Account B—becomes a tedious manual process. This behaviour is already documented and while AWS also documents workarounds, there’s no indication that this is going to change anytime soon. However, these approaches don't scale when you have multiple services and resources spanning different accounts across your organization.

This post walks through a practical example that demonstrates both the problem and a solution using orbits, a tool designed to seamless orchestrate all of your IaC with code.

Infra is code! At first glance, this slogan might be the most stupid one ever read for a long time — if not on the entire planet, then at least in the web sphere. Yes, infrastructure has always been code: from the Ubuntu web server to the Cockroach database, it is nothing but code controlled by code. But if the Ops field has progressively shifted towards the notion of Infrastructure as Code, it is precisely because there is a substantial difference: the DevOps domain is better formalized as a description of reproducible artifacts rather than as a prescription of successive commands to execute. Thus, boldly displaying this slogan Infra is code! on any article should make any somewhat experienced DevOps practitioner pause.

Yet, friend reading these lines, don’t go away so quickly! Haven’t you already felt that while DevOps improved developers’ lives with democratization of virtualization, convergence of interfaces, and unprecedented deployment speed, infrastructure itself remained, tucked away in some Git annex, a poor relative of computer code — difficult to edit, inflexible, and slow to test? The popular wisdom among developers seems to say: the less you touch infrastructure, the better off you are. With this, tirelessly, we arrive at a state-of-the-art where:

• every project restarts infrastructure work as if its neighbor didn’t exist
• building a service stack remains a patchwork, a conglomerate of loosely connected elements
• it is difficult, without manual intervention, to redeploy an app from scratch on a new environment.
• apps are hardly portable from one cloud to another — and the question of sovereignty is, out of frustration, abandoned.

Finally, all in all, a large part of DevOps activity remains manual, and the trust chain in the system relies on a chain of responsibility and a comprehensive understanding of the system by a few operators in the team (which is positive) rather than on appropriate tooling (which is disappointing because, as system complexity grows, relying solely on knowledge leads to rigid systems).

Consequently, we unanimously demand that infrastructure specifications have the same rights and level of citizenship as any other piece of code in the stack.

A demand that could remain dead letter if it were not accompanied by two recommendations:

orchestrators offer infrastructure an opportunity for liberation that it can seize to obtain its citizenship rights. The engineering platform movement has made a strong commitment in this direction and orchestration must be at the center of efforts.

increasingly, infrastructure benefits from being written in standard code: CDKs bear witness to the direction to follow. This allows a convergence of best practices between infrastructure and code.

Thus, IaC must be enhanced, orchestrated, and managed — as much as possible through standard code. We began working under these assumptions three years ago, and it has allowed us to build numerous engineering platforms since then. As we found nothing that met our criteria, we built our own orchestration framework: Orbits (aka Orbi.ts). It is now mature enough to fly on its own: since freedom is not won alone, we present it today to the community, hoping it can help build infrastructures and deployment pipelines that are more flexible, more robust, and more sovereign.