Rehost to STACKIT: Spring Boot with Terraform and Ansible

Migration migrate optimize rehost observability +2

Optimize Rehost Spring Boot with Observability and VM Rightsizing

STACKIT

Migration design-and-mobilize design runnable-example rehost +3

Practical Optimize runbook for a rehosted Spring Boot workload on STACKIT using managed Observability signals and controlled VM rightsizing driven by IaC.

Optimize Rehost Spring Boot with Observability and VM Rightsizing

Migration

Runbook

Rehost Spring Boot Service to VM

STACKIT

Migration design-and-mobilize design target-architecture rehost +5

Executable migration runbook for rehosting a Spring Boot JAR and PostgreSQL to one STACKIT VM with rehearsal, evidence-based cutover, validation, and rollback.

Rehost Spring Boot Service to VM

Migration

Runbook

Blueprint

Spring Boot and PostgreSQL on One VM with Observability and Backup

STACKIT

Validated Rehost architecture for a Spring Boot JAR and self-managed PostgreSQL on one STACKIT VM with restricted ingress, Observability, and Server Backup.

Spring Boot and PostgreSQL on One VM with Observability and Backup

Migration

Blueprint

Migration design-and-mobilize design runnable-example rehost +4

Rehost Spring Boot with Terraform and Ansible

STACKIT

Migration design-and-mobilize design target-architecture rehost +4

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Rehost Spring Boot with Terraform and Ansible

Migration

Runbook

Blueprint

Spring Boot hybrid access with VPN and central firewall

STACKIT

Open Source

Reference architecture for Spring Boot on STACKIT with hybrid enterprise connectivity with VPN and central firewall inspection in a hub-and-spoke model.

Spring Boot hybrid access with VPN and central firewall

Migration

Blueprint

Migration design-and-mobilize use-cases app-stack rehost +1

VM Application Migration with Controlled Cutover

STACKIT

Open Source

Template runbook for migrating an application with VM runtime to STACKIT with clear prerequisites, cutover governance, and defined rollback boundaries.

VM Application Migration with Controlled Cutover

Migration

Runbook

Guide

MI1: Rehost & Replatform Guide

STACKIT

Migration design-and-mobilize design rehost replatform +2

Managed Asset Marketplace

MI1 Rehost and Replatform guide: technical instructions for moving existing on-premises workloads to STACKIT with pragmatic, repeatable migration steps.

MI1: Rehost & Replatform Guide

Migration

Guide

The runbook asset documents the PostgreSQL flags and the optional dump-based data restore path.

Install

Describe manual installation steps for exception workloads.

Create and prepare target VM manually: Provision the VM through Portal or CLI, attach required storage, and apply OS hardening and patch baseline.
Install runtime and dependencies manually: Install required runtime packages, system libraries, and service users/groups according to product installation guidance.
Install application in the classic way: Perform guided installation steps (for example installer or setup wizard flow) to reproduce the source deployment model on the target VM.
Validate base install readiness: Confirm service startup, file permissions, required ports, DNS reachability, and outbound connectivity.
Cloud Design Patterns
Runbook Blueprint

Config

Define manual runtime configuration and controls.

Mirror source configuration for target context: Recreate application settings from the source environment and adapt them to target endpoints, DNS, certificates, and service integrations.
Apply security and access settings: Configure service credentials, secret handling, and least-privilege access for target operation.
Align operational defaults: Configure logging targets, metrics exporters, backup schedules, and retention baselines.
Validate configuration parity: Run smoke checks to confirm the target instance behaves as a functional equivalent of the source baseline.
Runbook Blueprint

Deploy

Define manual deployment sequencing and release checks.

Plan final migration window: Align freeze windows, communication checkpoints, and rollback authority for production switch.
Run final data migration: Execute last data sync or restore steps and confirm consistency checks before go-live.
Activate production traffic: Perform controlled live switch to the target environment and verify critical user and integration paths.
Confirm handover readiness: Record evidence, close open risks, and transfer ownership for Day-1 operations.
Migration Plan
Runbook Blueprint

OPS

Target Architecture

Blueprint

Spring Boot and PostgreSQL on One VM with Observability and Backup

STACKIT

Migration design-and-mobilize design target-architecture rehost spring-boot vm postgresql observability backup

Validated Rehost architecture for a Spring Boot JAR and self-managed PostgreSQL on one STACKIT VM with restricted ingress, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the repository

STACKIT

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

Overview

This pattern represents the validated low-change target for the Spring Boot Rehost example. The JAR continues to run as a systemd service, while PostgreSQL remains self-managed on the same VM. The runtime and database operating models therefore stay VM-centric.

The baseline is intentionally one VM. It demonstrates repeatable migration controls and operations readiness, not application or database high availability.

Typical use case

Low change tolerance: business behavior must remain stable during migration.
Short migration windows: runtime relocation should be predictable and repeatable.
Operations continuity: teams keep VM-centric operating procedures while moving to STACKIT.

Architecture diagram

Design best practices

Restrict ingress explicitly: allow SSH and application traffic only from approved source CIDRs; allow exporter traffic only from STACKIT service ranges.
Keep credentials out of state and inventory: pass the PostgreSQL password through the process environment and store the generated runtime environment file as root-only.
Define observability minimum set: include infrastructure and application health metrics before go-live.
Separate recovery layers: use the database pre-restore dump for cutover rollback and Server Backup for VM-level disaster recovery.
State the availability boundary: one VM with a local database has a shared failure domain. Add a load balancer or second node only with a separately designed database and consistency model.
Use explicit security groups and ingress rules: expose only required ports and protocols.

Confirm which volumes the backup policy covers and rehearse recovery independently of cutover rollback. The available server-backup features do not by themselves prove PostgreSQL consistency or the application’s recovery objectives.

From the STACKIT docsFeatures and benefits › FeaturesSource updated 13.11.2025 · copied 06.10.2026

Automated, monitored server backups with easy recovery
Create backups for one, multiple, or all volumes connected to a server at any time
The advanced custom backup schedules enable automated backups to be created
Freely select the retention period after which backups are automatically deleted
Partly restore certain files by seamlessly restoring a volume backup to a new volume

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.

Runbook Asset: Rehost Spring Boot with Terraform/OpenTofu and Ansible

Repository usage and required settings

Copy the example file: cp env.tfvars.example env.tfvars
Set required values:

create_project             = true
target_project_name        = "cmf-rehost-springboot"
target_project_owner_email = "owner@sa.stackit.cloud"
parent_container_id        = "cmf-parent-container-id"
service_account_key_path   = "/path/to/stackit-sa-key.json"

run_ansible                = true
jar_local_path             = "ansible/files/springboot-app.jar"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_observability       = true
enable_node_exporter       = true
enable_local_postgresql    = true
enable_server_backup       = true

Optional CMF feature wrapper (flags.env):

setup_project=true
setup_observability=true
setup_database=false
setup_workload=true
setup_loadgen=false
setup_dns=false

Apply:

terraform init
terraform apply -var-file=env.tfvars

Expected result: application_url serves the Spring Boot app directly from the VM on the configured application port. PostgreSQL listens for the application on localhost, Observability scrapes node exporter, and the boot volume has an enabled daily backup schedule.

Availability boundary and extensions

This baseline has no automatic failover. A load-balancer or multi-VM variant is useful only after application session handling, PostgreSQL placement, write consistency, health checks, TLS, and traffic switching have been designed and tested together. Treat that as a separate architecture decision, not as an implicit property of this Rehost path.

LIVE

Reference Implementation

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

BASE

Prepare the Workspace

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

SAFE

Configure Private Target Inputs

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

SAFE

Prepare Source Evidence

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

BASE

Provision the Target

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

STEP

Rehearse and Approve

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

LIVE

Cutover

Migration design-and-mobilize design runnable-example rehost spring-boot migration vm

Rehost Spring Boot Service to VM

STACKIT

Executable migration runbook for rehosting a Spring Boot JAR and PostgreSQL to one STACKIT VM with rehearsal, evidence-based cutover, validation, and rollback.

STACKIT

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

Controlled migration wave from readiness through cutover, validation, and handover

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

LIVE

Run the Approved Cutover

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

SAFE

Validate or Roll Back

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

SAFE

Verify Data and Runtime

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

SAFE

Retain Apply and Acceptance Evidence

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

STACKIT

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

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

GOAL

Stabilization

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

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

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

GOAL

Optimization

Return from the concrete migration example to the Migration Framework. Start optimization only after stable cutover, use representative production telemetry, implement one controlled change at a time, and validate its effect on reliability, performance, and cost.

In 7 trails

Understanding the Optimize module

Optimize starts when workloads run on STACKIT and real operating data is available. The module converts post-cutover observations into measurable improvements for performance, stability, and cost efficiency.

Optimize is not a one-time task. It is an iterative cycle that can overlap with early stabilization and post-cutover care.

Why optimization happens after migration

Many right-sizing and tuning decisions are only reliable under real load patterns. After cutover, teams can use production telemetry to separate assumptions from actual behavior.

Optimization loop

Collect runtime evidence: utilization, latency, error rates, throughput, and cost drivers.
Identify bottlenecks and waste patterns at workload, platform, and data layers.
Prioritize actions by business impact, risk reduction, and FinOps effect.
Implement tuning changes in controlled increments.
Validate outcomes against SLO, reliability, and cost targets.
Feed lessons learned into future migration waves and operating standards.

Typical optimization focus areas

Rightsizing: Align compute, storage, and network capacity with actual demand profiles.
Performance tuning: Improve latency and throughput through configuration, scaling, and architecture adjustments.
Reliability hardening: Reduce incident frequency through better resilience, observability, and failure handling.
FinOps controls: Improve cost transparency, remove waste, and optimize run-rate efficiency.

From theory to implementation

Optimization decisions should be based on runtime evidence, not assumptions. For practical implementation, combine workload telemetry, alerting, and controlled infrastructure changes.

Managed observability baseline: Use STACKIT Observability to collect metrics, logs, and traces with Grafana, Prometheus, Thanos, Loki, and Tempo.
Detection logic: Define explicit thresholds and observation windows for low utilization and overload conditions.
Run path: Apply rightsizing through IaC changes (for example VM flavor changes) with rollback checkpoints.
Validation loop: Re-measure SLO, error rates, and run-cost after each tuning increment.

Concrete example asset

Asset title

Framework

Asset type

Migration migrate optimize rehost observability +2

Optimize Rehost Spring Boot with Observability and VM Rightsizing

STACKIT

Migration design-and-mobilize use-cases migrate optimize +6

Practical Optimize runbook for a rehosted Spring Boot workload on STACKIT using managed Observability signals and controlled VM rightsizing driven by IaC.

Optimize Rehost Spring Boot with Observability and VM Rightsizing

Migration

Runbook

Optimize Replatform Spring Boot on Kubernetes with Rightsizing and Pod Scaling

STACKIT

Migration migrate optimize relocate vm +3

Optimize the same Spring Boot Replatform with measured pod and node capacity, PostgreSQL Flex tuning, scaling safeguards, and reversible infrastructure changes.

Optimize Replatform Spring Boot on Kubernetes with Rightsizing and Pod Scaling

Migration

Runbook

Optimize Relocated VMs with Evidence-Based Rightsizing

STACKIT

Open Source In 1 trail

Rightsize relocated STACKIT VMs from representative production telemetry with controlled machine-type changes, storage migration, validation, and rollback.

Optimize Relocated VMs with Evidence-Based Rightsizing

Migration

Runbook

Optimize Replatform Spring Boot on Cloud Foundry with autoscaling and rightsizing

STACKIT

Migration migrate optimize replatform cloud-foundry +3

Open Source

Optimize runbook for a replatformed Spring Boot workload on STACKIT Cloud Foundry using observability signals, autoscaling policies, and safe validation.

Optimize Replatform Spring Boot on Cloud Foundry with autoscaling and rightsizing

Migration

Runbook

Replatform optimization dimensions

For Replatform workloads on Kubernetes, optimization spans multiple layers and should be coordinated as one control loop.

Pod scaling: Use HPA to adapt replica count to workload pressure with explicit min/max limits.
Node pool scaling: Keep sufficient cluster headroom and tune machine type (flavor) for CPU/memory density requirements.
Ingress scaling: Re-evaluate load balancer service plan when ingress throughput or connection behavior becomes a bottleneck.
Storage rightsizing: Select storage classes based on performance requirements for persistent workloads.
Validation discipline: Re-check latency, error rate, and cost after every incremental tuning change.

Inputs and outputs

Primary inputs

Cutover reports, incident trends, SLO measurements, telemetry baselines, and cost reports.

Optimization outputs

Prioritized improvement backlog, validated tuning changes, and updated runbook standards.

Governance outcome

Clear trade-off decisions between performance, resilience, and cost with documented ownership.

Boundary to other modules

Optimize follows technical migration delivery in Migrate.
Optimize can run in parallel with early post-cutover care activities, while ownership for this care model is covered in the Run phase.
Deeper architectural redesign remains in Refactor.

OPS

Continue the Same Reference Implementation

Migration migrate optimize rehost observability rightsizing spring-boot

Optimize Rehost Spring Boot with Observability and VM Rightsizing

STACKIT

Practical Optimize runbook for a rehosted Spring Boot workload on STACKIT using managed Observability signals and controlled VM rightsizing driven by IaC.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation asset

STACKIT

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

Continue the reference implementation

This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.

The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.

Observability setup used for optimization

Use the managed STACKIT Observability stack as evidence source.

Prometheus: metric collection
Thanos: long-term metric retention
Grafana Loki: log analysis
Grafana Tempo: distributed traces
Grafana: dashboards and visualization

Architecture reference:

Observability decision dashboard

Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.

Grafana dashboard for Rehost Spring Boot observability and VM rightsizing decisions

Signals and thresholds for rightsizing

Define technical thresholds before changing capacity.

Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.

Keep thresholds workload-specific and validate with business traffic patterns.

Database visibility for optimize decisions

For stateful Rehost workloads, include database signals in the same dashboard review cycle.

Connection pressure: active connection trend and burst behavior.
Database growth: database size progression over time.
Transaction behavior: commit/rollback trend for stability checks.

Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.

PostgreSQL Flex optimization path for migrated data tiers

If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.

Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.

Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.

From the STACKIT docsFlavors and performance classes › FlavorsSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	CPU	RAM	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Notes

CPU and RAM is always per node.
The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the max_connections limit.

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.

From the STACKIT docsFlavors and performance classes › Performance ClassesSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	Max. IOPS	Max. throughput (MB/s)
Performance class 2	`premium-perf2-stackit`	1000	100
Performance class 4	`premium-perf4-stackit`	2000	150
Performance class 6	`premium-perf6-stackit`	5000	200
Performance class 8	`premium-perf8-stackit`	10000	250
Performance class 10	`premium-perf10-stackit`	15000	300
Performance class 12	`premium-perf12-stackit`	20000	350

Currently, we offer three types of instances. For each type there is a different set of flavors available.

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.

Rightsizing workflow

Collect baseline metrics and traces for a representative period.
Confirm optimization candidate with dashboards and alert history.
Plan capacity change and rollback checkpoint.
Apply VM size change with Terraform/OpenTofu.
Re-validate latency, error rates, throughput, and cost.
Keep or revert based on objective acceptance criteria.

Technical implementation example

Example A: Downsize after sustained low utilization

Update VM sizing in env.tfvars:

machine_type = "g3i.2"

Apply and inspect plan output:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Then validate:

Service health (systemctl status, synthetic checks)
p95 latency and error-rate trend
Cost delta in reporting window

Example B: Scale up under sustained overload

Update VM sizing in env.tfvars:

machine_type = "g3i.4"

Apply and validate with the same post-change checks.

Rollback pattern

If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC. Treat rollback as a standard runbook step, not as an emergency-only path.

Notes

Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in terraform plan before apply.

Storage as optimization dimension

In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.

When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
Guidance: Block Storage service plans

Select the performance class before provisioning

A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.

From the STACKIT docsService plans › Currently available Service Plans (performance classes)Source updated 22.04.2026 · copied 05.10.2026

The following table lists currently available performance classes for the EU01 region:

Swipe sideways to see the whole table

Performance class	Name	Max. IOPS	Max. Throughput (MB/s)
Performance class 0	storage_premium_perf0	120	25
Performance class 1	storage_premium_perf1	500	50
Performance class 2	storage_premium_perf2	1000	100
Performance class 4	storage_premium_perf4	2000	150
Performance class 6	storage_premium_perf6	5000	200
Performance class 8	storage_premium_perf8	10000	250
Performance class 10	storage_premium_perf10	15000	300
Performance class 12	storage_premium_perf12	20000	350
Performance class 13	storage_premium_perf13	20000	700
Performance class 14	storage_premium_perf14	25000	400
Performance class 15	storage_premium_perf15	25000	800
Performance class 16	storage_premium_perf16	30000	450
Performance class 17	storage_premium_perf17	30000	900
Performance class 18	storage_premium_perf18	35000	500
Performance class 19	storage_premium_perf19	35000	1000
Performance class 20	storage_premium_perf20	40000	550
Performance class 21	storage_premium_perf21	40000	1100
Performance class 29	storage_premium_perf29	60000	1500

IOPS - Input/Output Operations per second

Throughput - Throughput in Megabytes per second

Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.

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.

For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:

Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
Verify backup and database-level rollback readiness.
Provision the replacement VM and boot volume through IaC with the selected class.
Reapply the Ansible configuration and restore or migrate the workload data.
Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.

Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation asset

Treat storage checks as part of the same Optimize loop and validate latency, error behavior, recovery, and cost impact after any change.

Continue the reference implementation

This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.

The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.

Observability setup used for optimization

Use the managed STACKIT Observability stack as evidence source.

Prometheus: metric collection
Thanos: long-term metric retention
Grafana Loki: log analysis
Grafana Tempo: distributed traces
Grafana: dashboards and visualization

Architecture reference:

Observability decision dashboard

Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.

Signals and thresholds for rightsizing

Define technical thresholds before changing capacity.

Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.

Keep thresholds workload-specific and validate with business traffic patterns.

Database visibility for optimize decisions

For stateful Rehost workloads, include database signals in the same dashboard review cycle.

Connection pressure: active connection trend and burst behavior.
Database growth: database size progression over time.
Transaction behavior: commit/rollback trend for stability checks.

Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.

PostgreSQL Flex optimization path for migrated data tiers

If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.

Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.

Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.

From the STACKIT docsFlavors and performance classes › FlavorsSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	CPU	RAM	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Notes

CPU and RAM is always per node.
The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the max_connections limit.

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.

From the STACKIT docsFlavors and performance classes › Performance ClassesSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	Max. IOPS	Max. throughput (MB/s)
Performance class 2	`premium-perf2-stackit`	1000	100
Performance class 4	`premium-perf4-stackit`	2000	150
Performance class 6	`premium-perf6-stackit`	5000	200
Performance class 8	`premium-perf8-stackit`	10000	250
Performance class 10	`premium-perf10-stackit`	15000	300
Performance class 12	`premium-perf12-stackit`	20000	350

Currently, we offer three types of instances. For each type there is a different set of flavors available.

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.

Rightsizing workflow

Collect baseline metrics and traces for a representative period.
Confirm optimization candidate with dashboards and alert history.
Plan capacity change and rollback checkpoint.
Apply VM size change with Terraform/OpenTofu.
Re-validate latency, error rates, throughput, and cost.
Keep or revert based on objective acceptance criteria.

Technical implementation example

Example A: Downsize after sustained low utilization

Update VM sizing in env.tfvars:

machine_type = "g3i.2"

Apply and inspect plan output:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Then validate:

Service health (systemctl status, synthetic checks)
p95 latency and error-rate trend
Cost delta in reporting window

Example B: Scale up under sustained overload

Update VM sizing in env.tfvars:

machine_type = "g3i.4"

Apply and validate with the same post-change checks.

Rollback pattern

If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC. Treat rollback as a standard runbook step, not as an emergency-only path.

Notes

Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in terraform plan before apply.

Storage as optimization dimension

In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.

When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
Guidance: Block Storage service plans

Select the performance class before provisioning

A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.

From the STACKIT docsService plans › Currently available Service Plans (performance classes)Source updated 22.04.2026 · copied 05.10.2026

The following table lists currently available performance classes for the EU01 region:

Swipe sideways to see the whole table

Performance class	Name	Max. IOPS	Max. Throughput (MB/s)
Performance class 0	storage_premium_perf0	120	25
Performance class 1	storage_premium_perf1	500	50
Performance class 2	storage_premium_perf2	1000	100
Performance class 4	storage_premium_perf4	2000	150
Performance class 6	storage_premium_perf6	5000	200
Performance class 8	storage_premium_perf8	10000	250
Performance class 10	storage_premium_perf10	15000	300
Performance class 12	storage_premium_perf12	20000	350
Performance class 13	storage_premium_perf13	20000	700
Performance class 14	storage_premium_perf14	25000	400
Performance class 15	storage_premium_perf15	25000	800
Performance class 16	storage_premium_perf16	30000	450
Performance class 17	storage_premium_perf17	30000	900
Performance class 18	storage_premium_perf18	35000	500
Performance class 19	storage_premium_perf19	35000	1000
Performance class 20	storage_premium_perf20	40000	550
Performance class 21	storage_premium_perf21	40000	1100
Performance class 29	storage_premium_perf29	60000	1500

IOPS - Input/Output Operations per second

Throughput - Throughput in Megabytes per second

Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.

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.

For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:

Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
Verify backup and database-level rollback readiness.
Provision the replacement VM and boot volume through IaC with the selected class.
Reapply the Ansible configuration and restore or migrate the workload data.
Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.

Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.

Treat storage checks as part of the same Optimize loop and validate latency, error behavior, recovery, and cost impact after any change.

OPS

Right-size the VM Flavor

Migration migrate optimize rehost observability rightsizing spring-boot

Optimize Rehost Spring Boot with Observability and VM Rightsizing

STACKIT

Practical Optimize runbook for a rehosted Spring Boot workload on STACKIT using managed Observability signals and controlled VM rightsizing driven by IaC.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation asset

STACKIT

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

Continue the reference implementation

This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.

The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.

Observability setup used for optimization

Use the managed STACKIT Observability stack as evidence source.

Prometheus: metric collection
Thanos: long-term metric retention
Grafana Loki: log analysis
Grafana Tempo: distributed traces
Grafana: dashboards and visualization

Architecture reference:

Observability decision dashboard

Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.

Signals and thresholds for rightsizing

Define technical thresholds before changing capacity.

Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.

Keep thresholds workload-specific and validate with business traffic patterns.

Database visibility for optimize decisions

For stateful Rehost workloads, include database signals in the same dashboard review cycle.

Connection pressure: active connection trend and burst behavior.
Database growth: database size progression over time.
Transaction behavior: commit/rollback trend for stability checks.

Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.

PostgreSQL Flex optimization path for migrated data tiers

If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.

Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.

Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.

From the STACKIT docsFlavors and performance classes › FlavorsSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	CPU	RAM	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Notes

CPU and RAM is always per node.
The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the max_connections limit.

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.

From the STACKIT docsFlavors and performance classes › Performance ClassesSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	Max. IOPS	Max. throughput (MB/s)
Performance class 2	`premium-perf2-stackit`	1000	100
Performance class 4	`premium-perf4-stackit`	2000	150
Performance class 6	`premium-perf6-stackit`	5000	200
Performance class 8	`premium-perf8-stackit`	10000	250
Performance class 10	`premium-perf10-stackit`	15000	300
Performance class 12	`premium-perf12-stackit`	20000	350

Currently, we offer three types of instances. For each type there is a different set of flavors available.

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.

Rightsizing workflow

Collect baseline metrics and traces for a representative period.
Confirm optimization candidate with dashboards and alert history.
Plan capacity change and rollback checkpoint.
Apply VM size change with Terraform/OpenTofu.
Re-validate latency, error rates, throughput, and cost.
Keep or revert based on objective acceptance criteria.

Technical implementation example

Example A: Downsize after sustained low utilization

Update VM sizing in env.tfvars:

machine_type = "g3i.2"

Apply and inspect plan output:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Then validate:

Service health (systemctl status, synthetic checks)
p95 latency and error-rate trend
Cost delta in reporting window

Example B: Scale up under sustained overload

Update VM sizing in env.tfvars:

machine_type = "g3i.4"

Apply and validate with the same post-change checks.

Rollback pattern

If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC. Treat rollback as a standard runbook step, not as an emergency-only path.

Notes

Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in terraform plan before apply.

Storage as optimization dimension

In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.

When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
Guidance: Block Storage service plans

Select the performance class before provisioning

A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.

From the STACKIT docsService plans › Currently available Service Plans (performance classes)Source updated 22.04.2026 · copied 05.10.2026

The following table lists currently available performance classes for the EU01 region:

Swipe sideways to see the whole table

Performance class	Name	Max. IOPS	Max. Throughput (MB/s)
Performance class 0	storage_premium_perf0	120	25
Performance class 1	storage_premium_perf1	500	50
Performance class 2	storage_premium_perf2	1000	100
Performance class 4	storage_premium_perf4	2000	150
Performance class 6	storage_premium_perf6	5000	200
Performance class 8	storage_premium_perf8	10000	250
Performance class 10	storage_premium_perf10	15000	300
Performance class 12	storage_premium_perf12	20000	350
Performance class 13	storage_premium_perf13	20000	700
Performance class 14	storage_premium_perf14	25000	400
Performance class 15	storage_premium_perf15	25000	800
Performance class 16	storage_premium_perf16	30000	450
Performance class 17	storage_premium_perf17	30000	900
Performance class 18	storage_premium_perf18	35000	500
Performance class 19	storage_premium_perf19	35000	1000
Performance class 20	storage_premium_perf20	40000	550
Performance class 21	storage_premium_perf21	40000	1100
Performance class 29	storage_premium_perf29	60000	1500

IOPS - Input/Output Operations per second

Throughput - Throughput in Megabytes per second

Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.

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.

For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:

Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
Verify backup and database-level rollback readiness.
Provision the replacement VM and boot volume through IaC with the selected class.
Reapply the Ansible configuration and restore or migrate the workload data.
Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.

Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.

Treat storage checks as part of the same Optimize loop and validate latency, error behavior, recovery, and cost impact after any change.

SAFE

Decide the Storage Path

Migration migrate optimize rehost observability rightsizing spring-boot

Optimize Rehost Spring Boot with Observability and VM Rightsizing

STACKIT

Practical Optimize runbook for a rehosted Spring Boot workload on STACKIT using managed Observability signals and controlled VM rightsizing driven by IaC.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation asset

STACKIT

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

Continue the reference implementation

This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.

The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.

Observability setup used for optimization

Use the managed STACKIT Observability stack as evidence source.

Prometheus: metric collection
Thanos: long-term metric retention
Grafana Loki: log analysis
Grafana Tempo: distributed traces
Grafana: dashboards and visualization

Architecture reference:

Observability decision dashboard

Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.

Signals and thresholds for rightsizing

Define technical thresholds before changing capacity.

Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.

Keep thresholds workload-specific and validate with business traffic patterns.

Database visibility for optimize decisions

For stateful Rehost workloads, include database signals in the same dashboard review cycle.

Connection pressure: active connection trend and burst behavior.
Database growth: database size progression over time.
Transaction behavior: commit/rollback trend for stability checks.

Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.

PostgreSQL Flex optimization path for migrated data tiers

If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.

Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.

Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.

From the STACKIT docsFlavors and performance classes › FlavorsSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	CPU	RAM	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Notes

CPU and RAM is always per node.
The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the max_connections limit.

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.

From the STACKIT docsFlavors and performance classes › Performance ClassesSource updated 06.07.2026 · copied 05.10.2026

Swipe sideways to see the whole table

Description	ID	Max. IOPS	Max. throughput (MB/s)
Performance class 2	`premium-perf2-stackit`	1000	100
Performance class 4	`premium-perf4-stackit`	2000	150
Performance class 6	`premium-perf6-stackit`	5000	200
Performance class 8	`premium-perf8-stackit`	10000	250
Performance class 10	`premium-perf10-stackit`	15000	300
Performance class 12	`premium-perf12-stackit`	20000	350

Currently, we offer three types of instances. For each type there is a different set of flavors available.

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.

Rightsizing workflow

Collect baseline metrics and traces for a representative period.
Confirm optimization candidate with dashboards and alert history.
Plan capacity change and rollback checkpoint.
Apply VM size change with Terraform/OpenTofu.
Re-validate latency, error rates, throughput, and cost.
Keep or revert based on objective acceptance criteria.

Technical implementation example

Example A: Downsize after sustained low utilization

Update VM sizing in env.tfvars:

machine_type = "g3i.2"

Apply and inspect plan output:

terraform plan -var-file=env.tfvars
terraform apply -var-file=env.tfvars

Then validate:

Service health (systemctl status, synthetic checks)
p95 latency and error-rate trend
Cost delta in reporting window

Example B: Scale up under sustained overload

Update VM sizing in env.tfvars:

machine_type = "g3i.4"

Apply and validate with the same post-change checks.

Rollback pattern

If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC. Treat rollback as a standard runbook step, not as an emergency-only path.

Notes

Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in terraform plan before apply.

Storage as optimization dimension

In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.

When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
Guidance: Block Storage service plans

Select the performance class before provisioning

A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.

From the STACKIT docsService plans › Currently available Service Plans (performance classes)Source updated 22.04.2026 · copied 05.10.2026

The following table lists currently available performance classes for the EU01 region:

Swipe sideways to see the whole table

Performance class	Name	Max. IOPS	Max. Throughput (MB/s)
Performance class 0	storage_premium_perf0	120	25
Performance class 1	storage_premium_perf1	500	50
Performance class 2	storage_premium_perf2	1000	100
Performance class 4	storage_premium_perf4	2000	150
Performance class 6	storage_premium_perf6	5000	200
Performance class 8	storage_premium_perf8	10000	250
Performance class 10	storage_premium_perf10	15000	300
Performance class 12	storage_premium_perf12	20000	350
Performance class 13	storage_premium_perf13	20000	700
Performance class 14	storage_premium_perf14	25000	400
Performance class 15	storage_premium_perf15	25000	800
Performance class 16	storage_premium_perf16	30000	450
Performance class 17	storage_premium_perf17	30000	900
Performance class 18	storage_premium_perf18	35000	500
Performance class 19	storage_premium_perf19	35000	1000
Performance class 20	storage_premium_perf20	40000	550
Performance class 21	storage_premium_perf21	40000	1100
Performance class 29	storage_premium_perf29	60000	1500

IOPS - Input/Output Operations per second

Throughput - Throughput in Megabytes per second

Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.

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.

For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:

Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
Verify backup and database-level rollback readiness.
Provision the replacement VM and boot volume through IaC with the selected class.
Reapply the Ansible configuration and restore or migrate the workload data.
Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.

Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.