Skip to content
Beta

Spring Boot on Cloud Foundry with PostgreSQL and Autoscaler

Last updated on

Overview

Section titled “Overview”

This pattern uses STACKIT Cloud Foundry as the primary runtime for Spring Boot applications. The design focuses on fast delivery through platform-managed runtime, managed PostgreSQL, and autoscaling.

Typical use case

Section titled “Typical use case”
  • Application-first delivery model: teams prioritize deployment speed over infrastructure management.
  • PaaS operating preference: runtime life cycle, scaling, and health management are delegated to the platform.
  • Service binding model: application credentials are provided through Cloud Foundry service bindings and native marketplace integrations.

Architecture diagram

Section titled “Architecture diagram”
UsersCloud FoundryPostgreSQL Flex serviceObservabilityCF RouterApp AutoScaler serviceSpring Boot app instances (1..N) HTTPSroute to appscale by loadservice bindingmetrics/logs

Design best practices

Section titled “Design best practices”
  • Use service binding patterns consistently: keep service credentials and endpoints managed by platform binding workflows.
  • Define stateless deployment behavior: externalize data state to PostgreSQL and keep app instances disposable.
  • Keep fallback plans for service limits: define operational runbook paths for quota and plan transitions.
  • Align route strategy with environment model: separate routes and service instances by stage or tenant boundary.

Check the per-instance resource limits and persistence requirements before selecting Cloud Foundry as the migration target. Keep application state in the backing service rather than relying on local container files surviving restart, redeployment, or scaling.

From the STACKIT docsRequirements for applications › Limitations of application instancesSource updated 13.03.2026 · copied 06.10.2026

Individual instances of application processes or executions (tasks) can consume up to 32 GB RAM and up to 6 GB ephemeral local disk storage, including additional processes (sidecars).

If nothing else is specified, a single web process with 256 MB RAM and 512 MB ephemeral local disk storage is assumed. These values can be changed, for example, using the manifest file.

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 docsRequirements for applications › Don’t write to the local filesystemSource updated 13.03.2026 · copied 06.10.2026

Since your applications run in containers, their local filesystem is not persistent. As soon as the container is stopped or crashes, the storage is assigned to other containers. This means that if an application writes data to the local filesystem and the container is redeployed due to an update or crash, all locally stored data is lost.

Also, the local filesystem of a container is not shared between all instances. So if an application keeps data on the local filesystem, only that one instance knows about it. If the user then refreshes the page and is routed to another instance, access to the data is no longer possible.

Instead of persisting data on the local filesystem, you can use data services from the marketplace or volumes as a service from the STACKIT Portal. Learn more at Create a service instance.

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.

Automation repository

Section titled “Automation repository”
Code & registry github.com STACKIT CMF Replatform Cloud Foundry repository Open the repository

Use this repository when the target runtime is Cloud Foundry with PostgreSQL, App Autoscaler, and Observability.

Repository usage (rollout and update)

Section titled “Repository usage (rollout and update)”
  1. Copy the example file:
Terminal window
cp env.tfvars.example terraform.tfvars

  1. Set your project, auth, and Cloud Foundry values in terraform.tfvars.

  2. Initial rollout (Terraform creates app and route):

setup_workload            = true
manage_workload_app_route = true
Terminal window
terraform init -upgrade
terraform plan
terraform apply
  1. Regular updates (stable mode):
manage_workload_app_route = false
existing_cf_app_id        = "<your-app-guid>"
Terminal window
terraform plan
terraform apply

Hint: This mode split exists because some Cloud Foundry provider versions can still produce recurring app/route drift after the initial creation.

Optimize follow-up asset

Section titled “Optimize follow-up asset”

For the optimization and rightsizing step in the Optimize module, continue with:

Asset title
Framework
Asset type
STACKIT LogoSTACKIT Logo
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.
stackit Logostackit Logo
Optimize Replatform Spring Boot on Cloud Foundry with autoscaling and rightsizing
Migration
Runbook

Asset historyActive 4 of the last 12 weeksTMUpdatedNo updates · 1 bar = 1 week i
Maintainers
TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerActive 10 of the last 12 weeks · 47 updatesSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081Contributed in STACKIT
Show full history (5 more)