Spring Boot and PostgreSQL on One VM with Observability and Backup

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.

Related migration assets

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

Repository usage and required settings

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

1. Copy the example file: cp env.tfvars.example env.tfvars
2. 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

3. Optional CMF feature wrapper (flags.env):

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

4. 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.