STACKIT Landing Zone Blueprint – We built it so you don’t have to

We looked at this in the context of newer and sovereign cloud providers, where publicly available best practices and blueprints are still emerging. Working with a new provider will always involve a learning curve, but it does not have to mean repeating avoidable work. This is the reason for this project.

We have developed a Terraform-based landing zone architecture for STACKIT as a reusable blueprint and intentionally want to share it as part of our community work. Our goal is not to replace existing guidance, but to provide an additional, directly usable starting point for other teams. Since STACKIT has also published its own Landing Zone Accelerator, our blueprint should be seen as a complementary implementation perspective based on practical project experience.

The Idea: Treat the Landing Zone as a Standardized Product

Instead of treating each project individually, we consider the landing zone as a productized foundation with clearly defined expectations. 
 
It should be automated, so we fully provision via Infrastructure as Code (Terraform). Changes to the infrastructure need to governed, so we follow the GitOps principle. Teams want self-service, so we give you a YAML template you can use to automatically provision new project resources within your landing zone. Even security and integrated guardrails (e.g., network isolation and RBAC) are there by default. 

The architecture follows established patterns such as Hub & Spoke and a multi-layer deployment model to ensure scalability and maintainability. The goal is a foundation that feels familiar, structured, and easy to extend for project teams.

What we actually built

Inside this working setup is a Terraform-based project. We made the key decision to strictly separate concerns via layered Terraform states. This keeps the setup transparent and maintainable, while reducing the risk that changes in one area unexpectedly affect the whole platform.

We enforce guardrails at provisioning time, so standards don’t have to be remembered—they are already applied.

When every change is visible through PRs and pipelines, it changes how teams work on and with the platform. Ad-hoc changes become less attractive, and quality gates are part of the normal delivery process from the beginning. The foundation is already laid out and ready to use.

None of these decisions are particularly exotic.
But taken together, they turn the landing zone from a one-time setup into something that is usable and reusable in real projects.

Community Value: Why We Share the Blueprint

The greatest value for our daily project work comes from reuse and references. By building on existing work and established standards, we can onboard teams faster, make best practices foundational in our work, and reduce drift through models and templates.

This is also why we see strong value in the official STACKIT Landing Zone Accelerator: it provides an important reference point for teams working with STACKIT. Our blueprint complements this with a practical implementation perspective, especially around project-oriented automation, GitOps-based delivery, and the current NetBird-based VPN setup, which we used before STACKIT’s own VPN servicebecame available.

For us, the broader value comes from sharing knowledge and making these experiences accessible. Experiences with new technologies are and should be shared rather than isolated. Therefore, our approach is aligned with our community-centric values.

We developed and published the blueprint through blog posts, community sessions, and LinkedIn to create a common foundation for future projects for us and others.

Key Learnings

The development resulted in a lot of expected and transferable insights:

• Standards save time—especially when onboarding new teams
• Self-service requires clear guardrails to avoid uncontrolled growth
• Modularity is a prerequisite for scaling
• Templates reduce change effort in rapidly evolving platforms

We also gained a very practical insight:

STACKIT is still evolving. Compared to some hyperscalers, services and tooling are developing quickly, and community references are still growing. Without standardization and knowledge transfer, similar implementation questions can easily appear across multiple projects.
With a template-based setup, you can adapt once centrally instead of making parallel changes in every project. And with a sample project and blog post, you can support others in adopting sovereign cloud solutions more effectively.

Conclusion

The real value of a landing zone isn’t just its architecture—it’s its reusability.

Efficiency doesn’t come from building the perfect solution once.
It comes from building something good, standard, and shareable—and using it many times.

We’re planning to make the blueprint OSS-ready soon.
Until then (and afterwards), please check out our project.

→ our project here = https://github.com/Liquid-Reply/stackit-landingzone

Take it. Use it. Adapt it. Break it if needed. But most importantly— tell us what works and what doesn’t.

Let’s keep sharing.