PortvMind Cloud
TREN
ContactSign up

Solution scenario

A reference architecture for SaaS products and startups

A team ships several releases a week while tenant data stays in place. This page shows environment separation, the promotion line and the persistent volume.

ContactAll solution scenarios
Primary decision
At which level environment and tenant separation is drawn
Release line
One-way promotion across development, staging and production
Data layer
The managed database is the data layer and will soon be generally available

Overview

What does a multi-tenant SaaS product ask of its infrastructure?

The first decision is the level of separation. Environments are separated at namespace level: development, staging and production live in the same cluster behind different boundaries, a release is promoted in one direction only and is never written straight into production. The second decision is where tenant data sits; the application container changes with every release, while the persistent volume stays in place. The third is the ingress layer: requests are stateless, so the load balancer distributes across the pool. With few containers, Compute is enough; as tenant count grows, VKE is the fit. If staging and production share a node pool, the capacity spike at release reaches tenant requests. The managed database is positioned as the data layer in this architecture and will soon be generally available.

Typical workload profile

Release rhythm and tenant growth are separate axes

Production load is steady and grows linearly with tenant count, while the release line is bursty and asks for capacity several times a day. When both axes share the same node pool, the spike at deploy time reaches production requests. The profile therefore defines the traffic pattern separately from tenant growth.

Traffic pattern

Steady production load, a bursty release line

  • Stateless request flow
  • Several releases a week
  • Growth linear with tenant count

Data volume

Small per tenant, continuously growing in total

  • Persistent volume tied to the tenant
  • Stateless application container
  • Short-lived release artefacts

Latency and compliance

Tenant isolation comes before latency

  • Isolation at namespace level
  • One-way promotion between environments
  • Tenant data on a separate volume

The profile describes steady production load, a bursty release line and tenant growth as separate axes.

Reference architecture

Three environment lanes, a one-way promotion arrow

The architecture reads as horizontal lanes: one lane per environment, one namespace per environment. The arrow between lanes runs downwards only, and nothing is written straight into production. Tenant traffic enters the production pool through the load balancer.

Three environment lanes and a one-way promotion lineThe development, staging and production lanes are stacked; each lane holds a Kubernetes namespace and the workload attached to it. Dashed promotion arrows run downwards only, from development to staging and from staging to production. In the right-hand column tenant requests reach the load balancer, then the production Compute pool and the persistent tenant volume.Development environmentStaging environmentProduction environmentDevelopment namespaceVKE (Kubernetes)Shared runnerComputeStaging namespaceVKE (Kubernetes)Release testComputeProduction namespaceVKE (Kubernetes)Tenant Compute poolComputePersistent tenant volumeBlock StorageTraffic distributionLoad BalancerTenant requestsStateless trafficpromotionpromotion
Promotion is one-way; nothing is written straight into production. Cluster version and node profile are defined in the console.

PortvMind Cloud services used

Kubernetes separates, Block Storage carries

VKE owns the environment and tenant boundaries, Compute the runners and the production pool, Load Balancer the stateless traffic, and Block Storage the tenant data that outlives a release. The critical point in this split is simple: the container is replaced on every release, the volume is not. Without that separation every deploy becomes a data-movement risk.

  1. VKE (Kubernetes)

    Environment and tenant separation is drawn at namespace level with this service.

  2. Compute

    Runners, release tests and the production pool come from the same node profile.

  3. Load Balancer

    Stateless tenant requests are distributed across the pool according to health signals.

  4. Block Storage

    Tenant data stays on a persistent volume independent of the release.

Each service page links back to this scenario; the link is generated from the same list in both directions. All Services

Evaluation criteria

Four questions asked before standing up a cluster

The table covers the orchestration threshold, environment separation, the managed database and tenant data. The managed database is positioned as the data layer and will soon be generally available. Environment separation and the tenant volume are set before the cluster is created.

CriterionQuestion askedAnswer in this scenario
Orchestration thresholdDoes this team need Kubernetes today?With few tenants and services, plain Compute; once separation and promotion needs grow, VKE.
Environment separationWill environments be separate clusters or separate namespaces?This reference chooses the namespace level; promotion is one-way and never writes straight into production.
Managed databaseCan the database be taken as a managed service?Yes. The managed database is positioned as the data layer and will soon be generally available.
Tenant dataDoes a scaling decision move tenant data?No — the application container is stateless and the persistent volume stays tied to the tenant.

The managed database is the data layer and will soon be generally available. Environment separation, the promotion line and the tenant volume are planned before the cluster is created.

Related guides and documentation

Reading on Kubernetes and the responsibility matrix

The guides cover the difference between containers and orchestration and how responsibility is split in a managed cluster. Provisioning infrastructure as code and bringing up a first cluster are handled step by step in the documentation.

Guides

  • What Is Kubernetes? How It Works and When to Use It

    Kubernetes is an open-source orchestration platform that automates the deployment, scaling and lifecycle of containerized applications. It does not write application code and is not a container runtime by itself. Instead, it continuously compares your declared desired state with the actual state of a cluster, schedules pods, replaces failed workloads and routes service traffic to available replicas.

  • Docker vs Kubernetes: What Is the Difference?

    Docker tools focus on packaging an application and its dependencies as a container image, sharing that image and running it as a container. Kubernetes deploys, scales and maintains containerized workloads across a cluster of nodes. They are not direct competitors: image creation and local runtime workflows solve a different problem from multi-server orchestration.

  • Managed Kubernetes Responsibility Matrix: Who Manages What?

    Managed Kubernetes moves part of the control-plane work to the provider. Applications, images, access policy, secrets, data protection and recovery stay with the team. Write down provider scope and the team owner for every operating area.

Other solution scenarios

  • Finance

    An intraday transaction band, an end-of-day batch band and a retention period.

  • E-Commerce and Retail

    A campaign peak with a known date, an elastic pool and an egress budget.

  • Gaming

    Stateful sessions, the matchmaking decision and asset distribution.

Let us build the environment separation and the promotion line together.

Share your release rhythm, tenant model and current deployment tooling; in the architecture consultation we settle the orchestration threshold and the persistent volume plan together.

ContactOpen console