Web App on Containers

When to use it

• A typical web application: a frontend, an API and a relational database.
• A small team that would rather not operate servers or Kubernetes.
• Traffic that varies over the day, or is quiet overnight.

When you need sidecars, background workers with custom scheduling, or fine control over networking, see Web App on Kubernetes.

Diagram

  Browser
     │ HTTPS
     ▼
  ┌──────────────────────────────┐
  │ CDN & WAAP                    │  caches static assets, filters attacks
  └───────┬──────────────┬───────┘
          │ /api/*       │ /assets/*
          ▼              ▼
  ┌──────────────┐  ┌──────────────────┐
  │ Container:   │  │ Object storage    │  static build, user uploads
  │ web + API    │  └──────────────────┘
  │ (autoscaled) │
  └──────┬───────┘
         │ TCP 5432 (ACL: container egress only)
         ▼
  ┌──────────────────────────────┐
  │ Managed PostgreSQL            │  high availability + PgBouncer
  └──────────────────────────────┘

Components

Component	Velerion service	Configuration
Edge	CDN & WAAP	One CDN resource with two origins: the container for dynamic routes and object storage for static assets. Turn WAAP on for the resource.
Application	Container	A public image of your app. Set the port it listens on, a size that fits the app, minimum replicas of at least one in production, and an autoscaling trigger.
Configuration	Container environment variables	Database URL, storage endpoint and feature flags.
Database	Managed PostgreSQL	High availability on, Connection pooler on, and an access control list limited to the addresses your containers connect from — never the default 0.0.0.0/0.
Files	Object storage	One bucket for the static build, one for user uploads, each with its own access key.

Failure modes

Failure	Effect	Mitigation
Cold start after scaling to zero	The first visitor waits while a replica starts.	Keep at least one replica in production. Scale-to-zero suits staging and preview environments.
Too many database connections during a spike	New requests fail to connect.	Connect through the PgBouncer pooler, not directly.
Database primary fails	Writes stop until failover.	Turn on high availability, which adds a replica.
Database open to the internet	Credential-stuffing and data exposure.	Restrict the ACL, and use a dedicated user with only the rights the app needs.
Regional outage	The app is down.	Keep the database, containers and storage in one region for latency, and regularly copy database dumps and critical files to another region so you can rebuild there.

Trade-offs

• Simplicity vs control: containers remove all server maintenance, but you cannot run sidecars or tune the network the way Kubernetes allows.
• Managed PostgreSQL is in beta and available in fewer regions. Choose the application’s region by where the database is offered.