Static web delivery with optional CDN

Overview

This pattern targets internet-facing static delivery on STACKIT. It is independent of Cloud Foundry and uses Object Storage plus CDN for static content delivery.

Typical use case

• High static content share: front-end assets dominate traffic volume.
• Global or distributed user base: lower latency is needed for static content delivery.
• Controlled origin architecture: object storage remains in STACKIT while CDN delivery is optimized.

Architecture diagram

Design best practices

• Use CDN only where it adds measurable value: keep CDN optional and validate impact with latency and cache-hit metrics.
• Define cache invalidation behavior early: include cache invalidation and versioning strategy in the release process.
• Keep API and static delivery boundaries clear: avoid mixing cache-sensitive API responses with static content policies.
• Monitor origin fallback rates: high fallback can indicate cache policy or asset versioning problems.

Choose the origin backend and cache behavior before switching static-content traffic. Validate private bucket access, cache headers, and the release purge procedure with representative assets; the product capabilities below do not replace cutover acceptance tests.

From the STACKIT docsCDN features and options › Source (origins and backends)Source updated 14.09.2026 · copied 06.10.2026

The origin is the definitive source of your content. The STACKIT CDN fetches resources from the origin when they are not in the edge cache or when edge delivery rules exclude them.

There are two backend types available:

• HTTP backend: Connects to any publicly accessible web server via a URL or IP.
• Bucket backend: Specifically designed for S3-compatible storage. It allows the CDN to use stored credentials (access key ID and secret key) to fetch private assets securely.

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 docsCDN features and options › CacheSource updated 14.09.2026 · copied 06.10.2026

The STACKIT CDN accelerates content delivery by storing copies of your assets in edge locations across your selected regions (EU, US, AF, SA, ASIA). This reduces latency and minimizes the load on your origin server.

Default cache duration (TTL)

The time to live (TTL) determines how long an asset remains in the CDN cache before it is considered stale and must be fetched again from your origin.

• Origin headers: By default, the CDN respects cache-control headers sent by your origin server.
• Custom default TTL: If your origin does not provide a cache-control header, the CDN applies the default cache duration defined in your distribution configuration.

Purge

When you update content at your origin, the CDN may still serve the older version until the TTL expires. To force the CDN to fetch the latest version immediately, you must perform a manual purge.

There are different purge strategies available:

• Full purge: Invalidates the entire cache for the distribution. While effective, a full purge for a large website can cause a “cache stampede,” where a massive volume of simultaneous requests hits your origin server to repopulate the cache.
• Granular (Path-based) Purge: Invalidates only a specific path (e.g., /static/styles.css). This is the recommended approach for most updates, as it maintains the cache for unaffected assets and reduces the load on your origin.

To optimize your caching strategy, use the logging tools of STACKIT CDN to identify which assets are served from cache versus those causing origin pressure.

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

Repository:

Code & registry github.com STACKIT CMF Replatform Static Webserver repository Open the repository

The repository is structured analog to the existing CMF Terraform samples and uses the common feature flags:

• setup_project
• setup_observability
• setup_database
• setup_workload
• setup_loadgen
• setup_dns

Repository usage and required settings

1. Copy the example file: cp env.tfvars.example env.tfvars
2. Set required project and static delivery values:

project_id                = null
parent_container_id       = "cmf-parent-container-id"
project_name              = "cmf-static-webserver"
service_account_key_path  = "/path/to/stackit-sa-key.json"
objectstorage_bucket_name = null
cdn_regions               = ["EU", "US"]

3. Set feature switches:

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: static_web_url returns the static content endpoint (.../index.html) over CDN.

Note: This pattern intentionally does not provision VM or load balancer components.