---
title: Spring Boot on Cloud Foundry with PostgreSQL and Autoscaler
description: 'Reference architecture for Spring Boot on STACKIT Cloud Foundry with managed PostgreSQL, App Autoscaler, and Observability for controlled runtime delivery.'
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: 'blueprint'
  external: false
  tags: ["design-and-mobilize", "design", "target-architecture", "replatform", "cloud-foundry", "postgresql", "observability", "spring-boot"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/migration/assetcontainer/stackit/architecture-spring-boot-cloud-foundry-paas-backing-services/"
source_file: "docs/migration/assetcontainer/stackit/architecture-spring-boot-cloud-foundry-paas-backing-services.mdx"
---

## 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

- **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

```d2
vars: {
  d2-config: {
    pad: 32
  }
}

style.font-size: 22

direction: right

Users: "Users" {
  icon: ../../../../../../public/stackit-icons/networking/ip.svg
}

CloudFoundry: "Cloud Foundry" {
  link: https://docs.stackit.cloud/products/runtime/cloud-foundry/

  Router: "CF Router" {
    icon: ../../../../../../public/stackit-icons/networking/application-load-balancer.svg
    link: https://docs.stackit.cloud/products/runtime/cloud-foundry/
  }

  Autoscaler: "App AutoScaler service" {
    icon: ../../../../../../public/stackit-icons/runtime/cloudfoundry.svg
    link: https://docs.stackit.cloud/products/runtime/cloud-foundry/how-tos/use-the-app-autoscaler/
  }

  SpringApps: "Spring Boot app instances (1..N)" {
    icon: ../../../../../../public/stackit-icons/runtime/cloudfoundry.svg
    link: https://docs.stackit.cloud/products/runtime/cloud-foundry/
  }
}

Postgres: "PostgreSQL Flex service" {
  icon: ../../../../../../public/stackit-icons/databases/postgresql-flex.svg
  link: https://docs.stackit.cloud/products/databases/postgresql-flex/
}

Obs: "Observability" {
  icon: ../../../../../../public/stackit-icons/logging-monitoring/observability.svg
  link: https://docs.stackit.cloud/products/logging-and-monitoring/observability/
}

Users -> CloudFoundry.Router: "HTTPS"
CloudFoundry.Router -> CloudFoundry.SpringApps: "route to app"
CloudFoundry.Autoscaler -> CloudFoundry.SpringApps: "scale by load"
CloudFoundry.SpringApps -> Postgres: "service binding"
CloudFoundry.SpringApps -> Obs: "metrics/logs"
```

## 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 docs: [Requirements for applications › Limitations of application instances](https://docs.stackit.cloud/products/runtime/cloud-foundry/basics/requirements-for-applications/#limitations-of-application-instances) (Source 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](https://docs.stackit.cloud/products/runtime/cloud-foundry/how-tos/use-manifest-files/).

> From the STACKIT docs: [Requirements for applications › Don’t write to the local filesystem](https://docs.stackit.cloud/products/runtime/cloud-foundry/basics/requirements-for-applications/#dont-write-to-the-local-filesystem) (Source 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](https://docs.stackit.cloud/products/runtime/cloud-foundry/getting-started/create-a-service-instance/).

## Automation repository

<LinkCard
  title="STACKIT CMF Replatform Cloud Foundry repository"
  href="https://github.com/stackitcloud/stackit-cmf-replatform-cloud-foundry"
/>

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

## Repository usage (rollout and update)

1. Copy the example file:

```bash
cp env.tfvars.example terraform.tfvars
```

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

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

```hcl
setup_workload            = true
manage_workload_app_route = true
```

```bash
terraform init -upgrade
terraform plan
terraform apply
```

4. Regular updates (stable mode):

```hcl
manage_workload_app_route = false
existing_cf_app_id        = "<your-app-guid>"
```

```bash
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

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

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  assetIds={[
    "migration/assetcontainer/stackit/optimize-replatformed-spring-boot-cloud-foundry-autoscaling",
  ]}
/>