Skip to content
Beta

Enterprise Cloud Onboarding Blueprint

Last updated on

TM LogoTM Logo
TM Solutions Corp. Inc.

Enterprise Cloud Onboarding Blueprint

Standardized multi-layer blueprint guiding product teams through secure, compliant platform onboarding into localized STACKIT environments and Network Areas.

PLAN

Strategic Alignment & Maturity

Every successful project journey starts with a maturity check. Product teams use our automated assessment to map their target application architecture against organizational cloud compliance guidelines.

Includes initial assessment questionnaires, team mapping templates, and kick-off workshop assets.

BASE

Understand the Two Landing-Zone Layers

Before provisioning starts, teams align on the split between the platform landing zone (organization-wide guardrails, connectivity, identity) and the application landing zone their workload will live in.

Design and mobilizeLanding zonesOverview In 5 trails

Understanding Landing Zones

Section titled “Understanding Landing Zones”

A landing zone is the structured cloud foundation that defines how your organization operates on STACKIT from day 1. It combines governance, identity, security, network design, cost controls, and automation into one coherent baseline.

Without this foundation, migration waves typically stall due to missing approvals, inconsistent controls, and repeated platform decisions.

Core components

Section titled “Core components”

The following visual summarizes the core components that should be addressed for a reliable platform baseline.

Landing zone core components Six building blocks of a secure landing zone. Landing zone core componentsThe six building blocks of a secure platform foundation on STACKIT.Account GovernanceAccount GovernanceHow do I structure my projects?Identity & Access ManagementIdentity & Access ManagementWho can do what on the platform?Security & ComplianceSecurity & ComplianceHow do I monitor and protect?Network ArchitectureNetwork ArchitectureHow are components securely connected?Cost Management and ControlCost Management and ControlHow do I keep spending in control?Automation (IaC)Automation (IaC)How is everything delivered and managed?

Why you need a landing zone

Section titled “Why you need a landing zone”
  • Control and risk reduction: Enforce security and compliance controls consistently across teams.
  • Scalable delivery baseline: Enable repeatable provisioning patterns for multiple migration waves.
  • Clear responsibilities: Define ownership boundaries for platform, security, and application teams.
  • Faster migration throughput: Avoid redesigning core controls for each application move.

When to start

Section titled “When to start”

Start the landing-zone stream as early as possible, in parallel with discovery.

  • Too late: Productive migrations are blocked because mandatory controls are not yet available.
  • Too early without discovery feedback: Application constraints are missed and later cause rework.

The practical model is a dual track: establish the platform baseline early, then refine application landing zone templates as discovery insights mature.

Two layers: Platform and Application Landing Zones

Section titled “Two layers: Platform and Application Landing Zones”

Platform Landing Zone

Company-wide foundation for governance, identity, security, networking, cost controls, and automation.

Open Platform Landing Zone

Application Landing Zone

Workload-specific implementation patterns derived from the platform baseline and discovery findings.

Open Application Landing Zone

Typical enterprise inputs

Section titled “Typical enterprise inputs”

To design a landing zone effectively, enterprises usually provide:

  • Organization and ownership model: Entities, project boundaries, and accountability model.
  • Compliance and policy requirements: Regulatory obligations and internal control policies.
  • Security requirements: IAM standards, network segmentation, encryption, and logging expectations.
  • Operations and support constraints: Incident handling, escalation paths, and handover model.
  • Application portfolio insights: Discovery findings about workload archetypes and dependencies.

Delivery model

Section titled “Delivery model”
  1. Define enterprise guardrails and target control model.
  2. Build and validate the platform landing zone baseline as code.
  3. Derive application landing zone templates from discovery and migration design.
  4. Pilot with selected workloads, then scale through migration factory runbooks.

STACKIT acceleration assets

Section titled “STACKIT acceleration assets”

To accelerate delivery, STACKIT provides concrete best practices and reusable templates:

Asset title
Framework
Asset type
STACKIT LogoSTACKIT Logo
Blueprint

STACKIT Landing Zone Accelerator

STACKIT

Migration design-and-mobilize landing-zone opentofu terraform +1
Open Source In 2 trails

STACKIT base asset for building a platform landing zone with reusable OpenTofu/Terraform modules, enterprise baseline patterns, and central Kubernetes.
stackit Logostackit Logo
STACKIT Landing Zone Accelerator
Migration
Blueprint
STACKIT LogoSTACKIT Logo
Blueprint

VM Application Landing Zone for Relocate

STACKIT

Migration design-and-mobilize landing-zone relocate vmware +4
Open Source In 1 trail

Technical blueprint for creating a VM application landing zone with the STACKIT Accelerator, manual security groups, and Coriolis or Acura handoff.
stackit Logostackit Logo
VM Application Landing Zone for Relocate
Migration
Blueprint
STACKIT LogoSTACKIT Logo
Guide

Control Plane & GitOps

STACKIT

Migration design-and-mobilize landing-zone dev-platform crossplane +3
Open Source

Manage STACKIT cloud resources natively through Kubernetes manifests and automate GitOps synchronization workflows using Crossplane, ArgoCD, and Flux CD.
stackit Logostackit Logo
Control Plane & GitOps
Migration
Guide
STACKIT LogoSTACKIT Logo
Blueprint

Custom Automation

STACKIT

Migration design-and-mobilize landing-zone dev-platform golang +3
Open Source

Build custom STACKIT operators, comprehensive CLI extensions, or bespoke platform automation tools leveraging the official STACKIT SDKs for Go and Python.
stackit Logostackit Logo
Custom Automation
Migration
Blueprint
STACKIT LogoSTACKIT Logo
Guide

Developer Portals & Catalogs

STACKIT

Migration design-and-mobilize landing-zone dev-platform backstage +3
Open Source

Discover how Backstage and Port provide developers with customizable software catalogs, golden paths, and centralized visibility for STACKIT deployments.
stackit Logostackit Logo
Developer Portals & Catalogs
Migration
Guide
STACKIT LogoSTACKIT Logo
Guide

IaC Orchestration

STACKIT

Migration design-and-mobilize landing-zone dev-platform terragrunt +2
Open Source

Keep your Infrastructure as Code DRY and seamlessly manage complex multi-environment STACKIT deployments with Terragrunt for advanced IaC orchestration.
stackit Logostackit Logo
IaC Orchestration
Migration
Guide
STACKIT LogoSTACKIT Logo
Guide

Infrastructure as Code (IaC)

STACKIT

Migration design-and-mobilize landing-zone dev-platform terraform +3
Open Source

Learn to provision fundamental STACKIT landing zone resources like SKE clusters and networks using Terraform, OpenTofu, and Pulumi for reliable setups.
stackit Logostackit Logo
Infrastructure as Code (IaC)
Migration
Guide
STACKIT LogoSTACKIT Logo
Service

Managed Landing Zone Service

STACKIT

Migration design-and-mobilize landing-zone managed-service opentofu +1
Managed Asset Marketplace In 1 trail

STACKIT managed service for consulting, setup, and implementation of enterprise landing zones using OpenTofu, `Terragrunt`, and boilerplate accelerators.
stackit Logostackit Logo
Managed Landing Zone Service
Migration
Service
meshcloud Logomeshcloud Logo
Blueprint

meshStack Self-Service Landing Zone

meshcloud

Migration design-and-mobilize landing-zone dev-platform opentofu
Open Source

Reference architecture that adds governed self-service on top of a STACKIT landing zone, so application teams order projects and routed networks themselves.
meshcloud Logomeshcloud Logo
meshStack Self-Service Landing Zone
Migration
Blueprint
STACKIT LogoSTACKIT Logo
Software

pfSense Firewall Connectivity Pattern

STACKIT

Migration design-and-mobilize landing-zone network network-area +3
Open Source

Guidance for using the STACKIT Quick Deployment pfSense firewall as the central control point in hub-and-spoke network area architectures on the STACKIT Cloud.
stackit Logostackit Logo
pfSense Firewall Connectivity Pattern
Migration
Software
PRODYNA LogoPRODYNA Logo
Service

CAF Landing Zones Implementation (PRODYNA)

PRODYNA

Migration design-and-mobilize landing-zone caf managed-service +1
Managed Asset Marketplace In 1 trail

CAF landing zones implementation by PRODYNA: managed landing zone delivery service for enterprise cloud adoption and migration enablement on the STACKIT Cloud.
prodyna Logoprodyna Logo
CAF Landing Zones Implementation (PRODYNA)
Migration
Service
STACKIT LogoSTACKIT Logo
Guide

Full IDPs & Cloud Foundations

STACKIT

Migration design-and-mobilize landing-zone dev-platform crossplane +4
Open Source

Explore how open source solutions like Crossplane and Backstage provide a fully managed central control plane for landing zone orchestration, automated compliance, and FinOps on STACKIT.
stackit Logostackit Logo
Full IDPs & Cloud Foundations
Migration
Guide
REWION LogoREWION Logo
Service

5-Day STACKIT Landing Zone Integration & Setup

REWION

Advisory landing-zone setup governance security
Managed Asset

REWION delivers a rapid five-day STACKIT landing zone setup with organization, IAM, network, security, governance, automation, and onboarding foundations.
rewion Logorewion Logo
5-Day STACKIT Landing Zone Integration & Setup
Advisory
Service

BASE

Basecamp: Platform Provisioning

STACKIT LogoSTACKIT Logo
Blueprint

STACKIT Landing Zone Accelerator

STACKIT

Migration design-and-mobilize landing-zone opentofu terraform template
Open Source In 2 trails

STACKIT base asset for building a platform landing zone with reusable OpenTofu/Terraform modules, enterprise baseline patterns, and central Kubernetes.
STACKIT LogoSTACKIT Logo
Owner

STACKIT

The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.

Accelerator architecture

Section titled “Accelerator architecture”

Architecture overview of the STACKIT Landing Zone Accelerator, from bootstrap through platform capabilities to application landing zones and workloads

Overview

Section titled “Overview”

This asset provides a reusable foundation for implementing a STACKIT platform landing zone. It is designed for enterprise environments that need a structured baseline for governance, security, networking, cost controls, and automation.

Repository:

How the repository works

Section titled “How the repository works”

This repository is a single root-module accelerator with modular submodules.

  • The root module in src/main.tf orchestrates all platform and landing-zone building blocks.
  • Configuration is provided through flavor-specific variable files in src/config/.
  • You can deploy with OpenTofu or Terraform (same module graph).
  • The initial deployment uses a temporary bootstrap service account, then migrates to a managed backend and managed credentials.

Deployment flavours and what they enable

Section titled “Deployment flavours and what they enable”

The repository provides eight reference configurations in src/config/. Choose the simplest topology that satisfies the required network, security, organizational, tenant, and regional boundaries.

Standalone

Section titled “Standalone”

Standalone topology with a management foundation, sandbox, and public application landing zone

Use standalone.tfvars for the smallest foundation: governance, management, a sandbox, and a public application landing zone with its own network and direct internet access. It creates no shared Network Area or connectivity hub, making it suitable when workloads do not require private east-west connectivity or central DNS.

Hub-and-spoke

Section titled “Hub-and-spoke”

Hub-and-spoke topology with a shared Network Area and separate public landing zone

Use hub-and-spoke.tfvars when corporate workloads need shared private connectivity. A central connectivity project provides the Network Area and DNS, the corporate data platform joins that private domain, and public workloads retain independent networks with direct internet access.

Hub-and-spoke with firewall

Section titled “Hub-and-spoke with firewall”

Hub-and-spoke topology with centralized OPNsense firewall inspection

Use hub-and-spoke-firewall.tfvars when corporate egress needs a consistent inspection and control point. It extends the shared Network Area with an OPNsense firewall and steers corporate default routes through the appliance, while public landing zones remain directly connected.

Finance and research separation

Section titled “Finance and research separation”

Finance and research topology with independent private connectivity domains

Use hub-and-spoke-finance-research.tfvars when business units require independent ownership and private connectivity. Finance and research each receive their own address plan, connectivity project, Network Area, and workload landing zone within the same STACKIT organization.

Regulated and shared network areas

Section titled “Regulated and shared network areas”

Multi-area topology separating regulated and shared workloads

Use hub-and-spoke-multi-area.tfvars when regulated and shared workloads must occupy separate private connectivity domains. Each domain has its own Network Area and DNS zone, with no implicit routing between them.

Independent regional hubs

Section titled “Independent regional hubs”

Multi-region topology with independent hubs in eu01 and eu02

Use hub-and-spoke-multi-region.tfvars for regional foundations in eu01 and eu02. Each region receives an independent hub, Network Area, workload landing zone, and optional platform Kubernetes cluster. Inter-region connectivity is deliberately not created and must be designed explicitly.

Production and non-production isolation

Section titled “Production and non-production isolation”

Production and non-production topology with separate Network Areas and firewalls

Use hub-and-spoke-prod-nonprod-firewall.tfvars when production must be isolated from non-production. Each domain receives a dedicated Network Area and OPNsense firewall; development and test share the non-production domain while remaining separate landing zones.

Tenant isolation

Section titled “Tenant isolation”

Tenant isolation topology with three independent private tenant domains

Use hub-and-spoke-tenant-isolation.tfvars for multiple tenants inside one organization. Every tenant receives an independent owner, address plan, Network Area, connectivity project, and workload landing zone, without private routing to the other tenant domains.

Code & registry github.com Landing Zone Accelerator architecture Review the implementation architecture, deployment configurations, and network behavior in the source repository. Open the repository

Module-by-module breakdown

Section titled “Module-by-module breakdown”

1. Governance module (src/modules/governance)

Section titled “1. Governance module (src/modules/governance)”

Purpose:

  • Creates RM folder structure (platform, landing_zones_corporate, landing_zones_public, sandboxes).
  • Assigns folder-level owners and auditors.
  • Assigns organization-level owners and auditors.
  • Creates custom roles at organization scope.

Landing-zone classification:

  • Platform Landing Zone: core governance baseline.

2. Management module (src/modules/management)

Section titled “2. Management module (src/modules/management)”

Purpose:

  • Creates a central management project.
  • Provisions Secrets Manager and default access user.
  • Provisions object storage buckets (including a remote state bucket).
  • Creates object-storage credentials and stores them in Secrets Manager.
  • Creates automation service account + rotating keys, stores key in Secrets Manager.
  • Optionally provisions observability and stores observability credentials in Secrets Manager.
  • Optionally configures federated identity providers for the automation service account.

Landing-zone classification:

  • Platform Landing Zone: shared operations and automation control plane.

3. Connectivity module (src/modules/connectivity)

Section titled “3. Connectivity module (src/modules/connectivity)”

Purpose:

  • Creates a dedicated connectivity project.
  • Creates network area and regional network-area configuration.
  • Creates DNS zones for shared naming domains.
  • Optionally creates firewall image, volume, server, interfaces, public IP.
  • Exposes firewall next-hop IP for route injection into corporate landing zones.

Landing-zone classification:

  • Platform Landing Zone: shared network and routing baseline.

4. DevOps module (src/modules/devops)

Section titled “4. DevOps module (src/modules/devops)”

Purpose:

  • Creates a dedicated DevOps project.
  • Optionally creates a central STACKIT Git instance with ACL ranges.

Landing-zone classification:

  • Platform Landing Zone in this accelerator’s architecture.
  • Rationale: it provides shared delivery tooling and central CI/CD source-control capability across landing zones.

5. Landing-Zone module (src/modules/landing-zone)

Section titled “5. Landing-Zone module (src/modules/landing-zone)”

Purpose:

  • Creates application-facing landing-zone projects (iterative via for_each).
  • Supports corporate landing zones (network area-connected) and public landing zones.
  • Creates routed networks, optional routing-table default route via firewall next hop.
  • Optionally creates per-project child DNS zones.
  • Creates project-level custom roles and role assignments.
  • Creates Secrets Manager, object-storage buckets, and automation service-account key material per landing zone.

Landing-zone classification:

  • Application Landing Zone: primary ALZ implementation module.

6. Sandboxes module (src/modules/sandboxes)

Section titled “6. Sandboxes module (src/modules/sandboxes)”

Purpose:

  • Creates lightweight sandbox projects in the dedicated sandboxes folder.
  • Assigns project owners.

Landing-zone classification:

  • Application Landing Zone (supporting): non-production experimentation space close to ALZ usage patterns.

Newly implemented scope in this asset

Section titled “Newly implemented scope in this asset”

The current implementation now includes an end-to-end path for a central Kubernetes platform and namespace-based application onboarding.

Platform landing zone for central Kubernetes

Section titled “Platform landing zone for central Kubernetes”

The platform scope now includes a dedicated central Kubernetes foundation that can be operated as a shared platform service.

  • Central cluster foundation: A dedicated platform Kubernetes project with SKE cluster life cycle, DNS extension integration, and optional observability wiring.
  • Secrets policy readiness: Namespace-level Secret Manager policy enforcement supports staged rollout modes such as audit and strict.
  • Shared service model: Platform teams can expose central capabilities while keeping project and namespace boundaries explicit.
  • Operational baseline: Cluster-level outputs and access information are exposed for automation and controlled platform operations.

Application landing zone for namespace tenants

Section titled “Application landing zone for namespace tenants”

Application landing zones can now consume namespace service from the central Kubernetes platform cluster.

  • Namespace onboarding: Landing-zone configuration can request namespace creation for an application team in the shared cluster.
  • Developer access path: Namespace-scoped Kubernetes users and role bindings are provided for tenant-level operations.
  • Service exposure: DNS and ingress patterns are preconfigured for application endpoints based on landing-zone and namespace context.
  • Secrets integration: Workloads can consume centrally governed secret flows while staying in namespace scope.

Extra platform features used in this setup

Section titled “Extra platform features used in this setup”
  • External DNS automation: DNS records for namespace services are managed from Kubernetes annotations and extension-zone integration.
  • Central Kubernetes monitoring: Platform observability integration includes Grafana access and metrics push wiring for cluster-level telemetry.
  • Dashboard provisioning workflow: Example dashboards are provisioned and imported for faster operational handover.
  • Encrypted volumes option: Platform module support for encrypted volume patterns helps align with stricter data-protection requirements.
  • Flexible network posture: The platform Kubernetes module supports SNA-oriented network setups for controlled enterprise connectivity.

What developers get in an application landing zone

Section titled “What developers get in an application landing zone”
  • Ready-to-use namespace: A preconfigured namespace in the central cluster instead of a full cluster-per-team model.
  • Least-privilege access: Namespace-scoped identities and permissions aligned to day-2 developer tasks.
  • Consistent endpoint model: Predictable DNS and ingress patterns for service publication.
  • Governed secret usage: Central secret governance with namespace-level consumption patterns.
  • Observability visibility: Shared metrics and dashboard views that help teams validate rollout and runtime behavior.

Platform vs application landing zone scope in this repository

Section titled “Platform vs application landing zone scope in this repository”
  • Platform Landing Zone focus (majority of implementation):
    • governance
    • management
    • connectivity
    • devops
  • Application Landing Zone scope (narrower by design):
    • landing-zone (core ALZ provisioning)
    • sandboxes (supporting ALZ-adjacent environments)

This means the repository delivers a strong platform baseline first, while ALZ capabilities are intentionally focused on project landing-zone provisioning and team sandbox enablement.

How to use this asset in migration programs

Section titled “How to use this asset in migration programs”
  • Start the platform baseline early (governance, management, connectivity, optional DevOps).
  • Define corporate vs public ALZ patterns based on connectivity and compliance needs.
  • Instantiate application landing zones with the landing-zone map in your variable files.
  • Use sandboxes for team onboarding and controlled early experiments.
  • Move state to the managed backend after first apply and switch from bootstrap credentials to managed automation credentials.

What you get

Section titled “What you get”
  • Reusable baseline modules: Building blocks for account/project structure, IAM, network, and controls.
  • Policy-oriented setup: Guardrails and conventions for secure and governed cloud usage.
  • IaC-first approach: OpenTofu/Terraform implementation model for repeatable provisioning.
  • Enterprise extensibility: Designed as a baseline to be adapted to customer-specific requirements.

Typical use in migration programs

Section titled “Typical use in migration programs”
  • Early platform stream: Start foundation setup in parallel with discovery.
  • Control baseline before production move: Ensure mandatory controls are in place before productive migrations.
  • Template source for application landing zones: Reuse and refine baseline modules for workload archetypes.
Section titled “Recommended prerequisites”
  • Organization and ownership model for projects/environments.
  • Security and compliance requirements (identity, logging, evidence, segmentation).
  • Connectivity constraints and integration requirements.
  • Operating model alignment across platform, security, and application teams.
SAFE

Governance & Guardrails Scan

Open Contributors LogoOpen Contributors Logo
WIP
Guide

TM1: Security Big Picture

Open Contributors

Architecture security sentinelone
Open Source

Security big picture for STACKIT Kubernetes: an overview of the layered security architecture across build, network, and runtime in the SKE environment.
Open Contributors LogoOpen Contributors Logo

Open Contributors

The shared entry for everyone contributing to the STACKIT Cloud Framework in a personal capacity, without a company profile standing behind their work.

1. Motivation: Why Cloud Security is Different

Section titled “1. Motivation: Why Cloud Security is Different”

Unlike traditional on-premise environments (“Boundary Security”), the cloud operates on the Shared Responsibility Model:

  • STACKIT Responsibility: Security of the Cloud (Data centers, Hardware, Host OS).
  • User Responsibility: Security in the Cloud (Network config, Encryption, App Security, Data).

2. The Security Big Picture (Lines of Defense)

Section titled “2. The Security Big Picture (Lines of Defense)”

Code & Supply Chain Security * 4-Eye-Principle: Mandatory reviews for every Pull Request. * Vulnerability Scanning: Using Snyk to identify vulnerabilities in libraries.

3. Modular Pipeline Concept for Security

Section titled “3. Modular Pipeline Concept for Security”

Security is defined as code and rolled out automatically:

  1. Templates: Integration of pre-built security modules in the CI/CD pipeline.
  2. Secrets Manager: Secure credential retrieval via Hashicorp Vault. 3. Automated Guardrails: Temporary opening and automatic resealing of ACLs during deployment.

4. Reference Matrix

Section titled “4. Reference Matrix”
Swipe sideways to see the whole table
LayerMeasurePolicy / Tool
CodeSnyk, ReviewsVulnerability Management
Control PlaneSTACKIT SKE ACLsSKE Access Control
NetworkTLS, mTLSCert-Manager / Istio
WorkloadSentinelOneEndpoint Protection
AUTO

Continuous Delivery Automation

Connecting your workspace to the centralized CI/CD infrastructure. Secure repository mirroring, dynamic runner registration, and enterprise Helm delivery blueprints are configured out-of-the-box.

LIVE

Container Platform Bootstrapping

STACKIT LogoSTACKIT Logo
Runbook

Replatform Spring Boot from VM to Kubernetes with Terraform

STACKIT

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql
Open Source In 1 trail

Run the same Spring Boot JAR on STACKIT Kubernetes with PostgreSQL Flex, Gateway API, DNS, managed telemetry, and rehearsed database cutover and rollback.
STACKIT LogoSTACKIT Logo
Owner

STACKIT

The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.

Overview

Section titled “Overview”

This asset applies the Migration Framework to a Spring Boot and PostgreSQL Replatform: the application moves from a VM service to STACKIT Kubernetes Engine (SKE), and its database moves from self-managed PostgreSQL to STACKIT PostgreSQL Flex. The business function and application JAR stay unchanged; the runtime and database operating models change.

Reference implementation

Section titled “Reference implementation”

The reference repository is the source of truth for Terraform, Helm charts, pinned artifacts, migration scripts, and validation. Use a reviewed revision containing the Gateway API and scripts/migrate_postgres.py workflows described here; an older revision with a direct database-import Job does not implement this procedure.

Code & registry github.com STACKIT Spring Boot Kubernetes Replatform repository Open the Terraform, Gateway API, PostgreSQL migration, and Observability implementation used throughout this asset. Open the repository

Replatform scope in this asset

Section titled “Replatform scope in this asset”
  • Runtime: the identical Spring Music Spring Boot 2.4.0 JAR runs on Java 11 in a Kubernetes Deployment instead of under systemd.
  • Data: PostgreSQL Flex supplies dedicated application and rehearsal databases; JDBC and migration clients require TLS.
  • Traffic: Envoy Gateway, Gateway API HTTPRoutes, and SKE-managed ExternalDNS replace the VM endpoint.
  • Operations: Kubernetes health and resource controls replace host-service management; managed telemetry covers cluster, application, and database signals.
  • Migration: source evidence, isolated rehearsal, an explicitly approved cutover, and verified database rollback remain separate from infrastructure provisioning.

Cloud Foundry, Object Storage, microservice decomposition, and application modernization are not part of this implementation. The old sample application demonstrates platform substitution, not a recommendation to deploy an unsupported application stack in production.

Reference architecture diagram

Section titled “Reference architecture diagram”

Review the architecture asset before choosing capacity and network controls. It separates the implemented topology from production extensions such as public HTTPS, highly available workers, and protected metrics.

Cloud Framework Spring Boot on SKE with PostgreSQL Flex and Gateway API Review the implemented topology, runtime and data boundaries, and separately qualified production extensions. Open page

End-to-end flow

Section titled “End-to-end flow”
  1. Confirm Replatform suitability, source compatibility, landing-zone readiness, and ownership.
  2. Prepare a trusted PostgreSQL dump and integrity manifest independently of target provisioning.
  3. Review and apply Terraform for SKE, PostgreSQL Flex, Gateway, DNS, workload, and Observability.
  4. Validate the target, then rehearse the final source dump in the isolated rehearsal database.
  5. Freeze source writes, approve downtime, and run the gated cutover with a protected target backup.
  6. Accept application and data evidence or restore the pre-cutover target; switch traffic through the approved operator procedure.
  7. Retain evidence through stabilization and use representative telemetry for later optimization.

Prepare the walkthrough workspace

Section titled “Prepare the walkthrough workspace”

Use an isolated Linux lab environment with Git, Terraform, kubectl, curl, jq, getent, Python 3.11 or newer, and the PostgreSQL server and client tools. The Rehost sample scripts also require runuser, sha256sum, a postgres OS account, and root privileges to create and validate a temporary local database. Run the sample commands in that prepared lab environment, not on a production database host. Keep the generated private artifacts readable by the operator running the migration; do not make them world-readable.

Obtain reviewed commit IDs for both repositories from the reference maintainer and export them as REHOST_REVISION and REPLATFORM_REVISION before continuing. The Replatform revision must contain the Gateway API and gated migration workflow. Do not assume the remote default branch already contains the locally tested implementation; if the approved revision is not available, stop and obtain it before attempting the walkthrough.

Replace both placeholders with the reviewed full 40-character commit IDs, then set them in the same Bash terminal:

Terminal window
export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Run the following complete block from an empty working directory. The if check rejects missing, empty, or malformed IDs, including unchanged placeholders. Each && runs the next command only if the previous one succeeded. Git checks whether the commits are available; the format check alone does not verify approval or repository contents.

Terminal window
if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Continue only after Workspace ready appears. On failure the terminal stays open; later preparation commands are skipped. Existing or partially cloned directories are not removed or overwritten: inspect them and preserve local changes before retrying in a new empty working directory. On success, the terminal is in the Replatform checkout for the next steps.

Use an approved STACKIT project, service account, DNS delegation, SKE capacity, and protected Terraform backend. Obtain credentials through the approved secret channel, never from this Trail. The following commands assume this directory layout and a reviewed configuration; they do not establish a validated greenfield production deployment.

Prepare source evidence

Section titled “Prepare source evidence”

Qualify a consistent source dump and its manifest before data enters the migration workflow.

The Rehost reference supplies scripts/create_source_dump.sh and scripts/validate_source_dump.sh for its reproducible sample. Run them from that repository. Its artifacts directory supplies source-postgresql.dump and source-postgresql.manifest to the Replatform workflow. The manifest records version 1, table=public.album, row_count, album_fingerprint, and dump_sha256.

For the reproducible sample only, run the following from the Replatform checkout in the prepared lab environment. The scripts create a temporary PostgreSQL instance from the versioned sample SQL, export it, then perform an independent test restore. Use a fresh artifact directory; do not overwrite evidence from a migration already in progress.

Terminal window
umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Expect successful validation of eight rows and a matching fingerprint. These commands do not read a source VM. Keep using these exact artifacts for rehearsal and cutover.

For a real source, replace the sample generator with an approved export procedure: freeze all writers and derive the custom-format dump and manifest from the same consistent source snapshot. Do not mistake the generated eight-album sample for an export of an arbitrary running VM. Verify PostgreSQL compatibility, extensions, ownership, and schema dependencies before export.

Only trusted dumps may be restored because they execute SQL. This implementation migrates the public application schema and checks public.album; it deliberately excludes Flex-managed schemas. Other workloads require their own invariants and an adapted schema scope.

Code & registry github.com Spring Boot Rehost source and sample export Use the Rehost repository for the identical application artifact and reproducible PostgreSQL source-evidence tools. Open the repository

Provision the target

Section titled “Provision the target”

Provision the target from a reviewed plan with explicit project, capacity, access, and DNS inputs.

Use Terraform, kubectl, curl, jq, getent, and Python 3.11 or newer on Linux. Copy env.tfvars.example to env.tfvars and adapt the actual variables in that file. Keep the tested provider lock file and immutable image and JAR references. Confirm SKE version availability, node-pool capacity, project permissions, and DNS delegation before planning.

From the STACKIT docsLifecycle of Kubernetes Engine › Kubernetes end-of-life datesSource updated 24.08.2026 · copied 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Swipe sideways to see the whole table
Kubernetes minor versionEnd-of-life dateExpiration in SKE
v1.322026-02-282026-04-15
v1.332026-06-282026-06-10
v1.342026-10-272026-10-14
v1.352027-02-282027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Prefer an approved Application Landing Zone project. Set create_project = false and provide its project ID and service account key path. Project creation is an alternative requiring an approved parent container and permissions; it is not a replacement for landing-zone governance. Never put credentials, state, saved plans, or migration evidence in version control.

For a new checkout, create the private variable file without overwriting an existing one:

Terminal window
umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Edit this file before planning: supply the approved project and service-account path, region, supported SKE version, available node-pool flavor and zone, and delegated DNS settings from the repository example. Review backend access and locking, quotas, costs, and the HTTP/public-metrics limitations. The next section’s feature flags are not a complete environment configuration.

Unified automation flags

Section titled “Unified automation flags”

The optional common wrapper maps setup_project, setup_observability, setup_database, setup_workload, setup_loadgen, and setup_dns to the repository’s Terraform switches. These select provisioning scope only: enabling the database does not authorize data replacement and never replaces the separate migration approval gate.

Minimal target configuration

Section titled “Minimal target configuration”

These values select the complete workload and database path. They supplement, rather than replace, the project, region, node-pool, and DNS values in the repository example.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Keep HPA and load generation disabled during migration. Choose alert settings deliberately; the end-to-end test did not validate alert delivery. springboot_image selects the Java runtime, not an unrelated prebuilt application image. The init container downloads the commit-pinned Rehost JAR and verifies its SHA-256 before startup. Mirror immutable artifacts into approved artifact and image services for production.

Run from the Replatform repository and review the saved plan before applying:

Terminal window
umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Access control and temporary migration ACL extension

Section titled “Access control and temporary migration ACL extension”

With empty application ACL inputs, Terraform uses the SKE cluster’s actual egress CIDRs for PostgreSQL Flex. Explicit application or legacy ACL values override that default and must be reviewed. Do not permit 0.0.0.0/0.

The temporary PostgreSQL client runs inside SKE and receives the dump through kubectl. It does not connect directly to the source VM, and no source or workstation CIDR needs temporary Flex access. JDBC and database tools use sslmode=require; this requires encryption but does not provide the hostname verification of verify-full. Protect credentials in Kubernetes Secrets and the Terraform backend, and validate stronger certificate verification where required.

Rehearse the migration

Section titled “Rehearse the migration”

Restore the final dump into the isolated rehearsal database and require matching evidence less than 24 hours old.

After infrastructure apply completes, run an isolated restore into springmusic_rehearsal. Adjust the source directory to the approved artifacts; keep the evidence path private.

Terminal window
python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Rehearsal validates the manifest, dump checksum, target identity, row count, and fingerprint without replacing the application database. After the source write freeze, rehearse the final dump again. Cutover requires matching evidence from less than 24 hours ago. A successful rehearsal of an older or different dump is not approval for the final input.

VM PostgreSQL to PostgreSQL Flex migration option

Section titled “VM PostgreSQL to PostgreSQL Flex migration option”

The old deploy_postgres_migration_job = true path is disabled by validation. Use the gated workflow instead. Stop HPA, load generation, and all other target writers. Suspend Terraform and GitOps reconciliation while the script controls the Deployment replica count. Its local lock protects one checkout, not concurrent operators on different machines.

Terminal window
python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

The source-write flag is an operator attestation, not an automatic source shutdown. Cutover scales the application to zero, saves and checksums the pre-cutover target, proves that backup by restoring it into the rehearsal database, and only then restores the source transactionally. It verifies data before restarting the original replica count. Failure leaves the application stopped for investigation. Preserve the evidence journal and backup; do not overwrite them to retry.

Validate and roll back

Section titled “Validate and roll back”

Compare the database evidence with the source manifest, check application behavior through the Gateway, and confirm both metrics jobs are healthy. Traffic switching and business acceptance remain operator-controlled steps; the script does not change the source application’s endpoint.

To restore the protected pre-cutover target database:

Terminal window
python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Rollback checks target identity and backup integrity, saves the current target separately, restores the original data, and verifies its fingerprint before restarting. Post-cutover writes are not merged; retain the pre-rollback dump for explicit reconciliation. This is target-database rollback, not automatic failback to the source VM.

Database metrics visibility in Observability

Section titled “Database metrics visibility in Observability”

Terraform manages the SCF Replatform Grafana folder and eight-panel dashboard against the existing Thanos datasource. Use grafana_dashboard_url to open it. Cluster CPU, cluster memory, running pods, application requests, and PostgreSQL health and pressure support acceptance and later optimization. No manual dashboard import is required.

Application metrics come from the pod-local Boot 2 Actuator through the metrics adapter on port 9090; the PostgreSQL exporter serves port 9187. Check both actual scrape results, not only dashboard rendering. Missing telemetry is an investigation trigger, never proof of zero load.

Validation with kubectl

Section titled “Validation with kubectl”

Export a short-lived kubeconfig with private permissions and inspect the default namespace:

Terminal window
umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

The Gateway validator checks acceptance, resolved route references, DNS, and the application response. Remove the local kubeconfig after use and obtain a fresh one when it expires. Do not treat successful rollout alone as data or business acceptance.

Backup and recovery boundary

Section titled “Backup and recovery boundary”

Keep migration rollback distinct from Flex service recovery and retain protected evidence outside ephemeral execution environments.

Flex retention is configured explicitly, with a 32-day default in this reference. Managed database backups and the migration pre-cutover dump serve different purposes. Rehearsing the latter does not prove managed-service restore, point-in-time recovery, or application disaster recovery. Assign recovery ownership and test the required service recovery path separately.

Retain protected evidence and backups outside an ephemeral dev container until the rollback window closes. After a killed migration process, inspect leftover springmusic-migration-* pods before resuming; do not use Terraform to restart an unverified target.

What this asset demonstrates

Section titled “What this asset demonstrates”

This asset demonstrates how to preserve application behavior while changing the runtime and database operating models:

  • Platform substitution: run the same Spring Boot JAR on SKE, connect it to PostgreSQL Flex over TLS, and expose it through Gateway API and DNS.
  • Controlled data migration: qualify a source dump and manifest, rehearse an isolated restore, and require explicit approval and a verified target backup before cutover. Restore the pre-cutover target when rollback is required.
  • Independent validation: check data integrity, application responses, Gateway and DNS readiness, and actual scrape results. Review the Terraform plan for unexplained drift rather than treating successful provisioning as migration acceptance.
  • Repeatable observability: manage the Observability integration and eight-panel Grafana dashboard through Terraform. Use application and database signals for acceptance, stabilization, and later optimization.

Out of scope

Section titled “Out of scope”

This evidence does not establish a complete greenfield replay, migration from a live production source, zero downtime, high availability, public Gateway TLS, interactive IDP login, alert delivery, or managed Flex recovery. The tested single-worker HTTP setup exposes unauthenticated metrics; resolve those production requirements before using sensitive data. Upgrade the sample application and validate an appropriate supported Kubernetes release as separate controlled changes.

Code & registry github.com Reference configuration, scripts, and validation evidence Use the repository README and versioned implementation for exact prerequisites, variables, commands, and supported recovery boundaries. Open the repository
Trail historyActive 6 of the last 12 weeksTMUpdatedNo updates · 1 bar = 1 week i
Maintainers
TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172??Name not publicThe Cloud Framework team knows who this is. The name is not shown on the site.Contributed in TM Solutions Corp. Inc.
Show full history (7 more)