PAM deployment architecture: VM vs Kubernetes and sizing

A sound PAM deployment architecture puts the session proxies where operators can reach them and targets cannot be reached any other way, keeps state in a database you can fail over, and sizes compute from peak concurrent sessions rather than headcount. For most organisations the choice is between a standalone Linux VM, which is simpler and suits air-gapped sites, and a Kubernetes cluster, which suits teams that already operate one and need to scale proxies across zones. This guide is for infrastructure architects and security engineers planning a privileged access management rollout. It uses SWOT PAM’s documented architecture as the worked example and gives a sizing method you can apply to any platform.

PAM deployment architecture is the arrangement of a privileged access management platform's proxies, vault, database and recording storage across hosts and network zones, chosen so that every privileged session passes through a policy checkpoint and the platform stays available when a component fails.

What sits inside a PAM deployment architecture

Before choosing between a VM and a cluster, list the components and mark which hold state. Stateless parts can be copied and placed behind a load balancer; stateful parts need backups, replication and a failover plan.

SWOT PAM’s architecture documentation describes seven containers:

Component	Role	Port	State
Web client UI	Admin console, access hub, web terminals	443 (or 5000)	Stateless
API server	REST and WebSocket API, policy evaluation	8080	Stateless
SSH proxy	Terminates SSH, injects vault credentials, logs keystrokes	2222	Stateless
RDP gateway	Brokers RDP and RemoteApp	33890	Stateless
Database proxy	PostgreSQL and Oracle wire traffic, SQL rules	5454, 1521	Not classified in the docs
Database GUI proxy	Browser SQL workspace	9095 (internal)	Not classified in the docs
PostgreSQL 15+	Users, policies, audit chain, vault metadata	5432 (internal)	Stateful

The documentation names the API server, SSH proxy and RDP gateway as stateless, so they can scale out behind a network load balancer such as AWS NLB, Azure Load Balancer or F5 BIG-IP. PostgreSQL is the single source of state. For production, Rudratic recommends a managed cluster such as AWS RDS Multi-AZ or Azure Flexible Server, with replicas and automated failover.

Standalone VM or Kubernetes: which PAM deployment model fits

SWOT PAM runs on Docker with Docker Compose, or on Kubernetes, in the cloud, on-premises or hybrid. Both models run the same containers; the difference is how you scale, fail over and upgrade them. The sizing and deployment guide compares them as follows.

Dimension	Standalone VM or bare metal	Kubernetes
Scaling	Vertical: add vCPU and RAM to the host	Horizontal: more pod replicas
High availability	Active-passive, with hypervisor failover	Active-active across zones, with pod restart
Upgrades	A short service restart	Rolling update
Install	Release bundle and deploy.sh	Helm chart or GitOps
Platforms named in the docs	Any Linux host with Docker CE 24+ or Docker EE and Compose v2	AWS EKS, Azure AKS, Google GKE, Red Hat OpenShift
Operating skills	Standard Linux and VM administration	An existing Kubernetes practice

The guide positions the standalone VM for air-gapped networks, banking and defence sites, and up to 1,000 concurrent privileged operators. It positions Kubernetes for multi-region organisations with larger session counts, peak-hour autoscaling and rolling upgrades.

When a standalone VM is the better choice

A single host is easier to harden, back up and explain to an auditor. If your organisation does not already run Kubernetes, adopting it just for PAM adds a control plane, a container network and a new set of privileged identities, all of which then need their own access controls. For a site of a few hundred administrators, that extra surface rarely pays for itself.

When Kubernetes is the better choice

Kubernetes earns its place when you need to add proxy capacity without touching the host, or when shift changes create sharp peaks in session starts. A HorizontalPodAutoscaler updates a Deployment or StatefulSet to scale capacity to demand, which fits the stateless proxies. Test what a rolling update does to sessions that are open at the time: an SSH or RDP stream is pinned to one proxy pod, so plan pod disruption rules and drain timing around your longest sessions.

How to size a PAM platform

Named users tell you little about load. A PAM proxy works hardest when many sessions are open at once, when those sessions are graphical, and when every keystroke and query is inspected and recorded. Collect these inputs before you pick a tier:

1. Peak concurrent sessions. Count open sessions at the busiest hour, usually a shift change, a patch window or month-end. Take it from your current jump-host or VPN logs where you can.
2. Protocol mix. Split the peak into SSH, RDP and database sessions. RDP sessions carry screen data and usually cost more per session than a terminal.
3. Session starts per minute. Login bursts load the API server and identity provider more than steady sessions do.
4. Targets and credentials. The number of servers, databases and vaulted secrets drives discovery scans and rotation jobs.
5. Recording volume and retention. Average recording size per session type, multiplied by sessions per day and the number of days you must keep it.
6. Availability target. Decide how long the PAM may be down before administrators fall back to break-glass access, and size for N+1 on the proxies accordingly.

Starting points from Rudratic’s sizing guide

The SWOT PAM sizing guide publishes four tiers, derived from multi-protocol load testing across SSH, RDP and database proxy sessions. Treat them as starting points to confirm in your own proof of concept, with your own protocol mix.

Tier	Active users	Architecture	vCPU	RAM	Storage
Foundation	50 to 100	Single VM	4	8 GB	SSD, 1,000 IOPS
Mid-enterprise	100 to 500	Two VMs (application and database)	8 (4 + 4)	16 to 32 GB	NVMe SSD, 3,000+ IOPS
Enterprise core	500 to 2,000	Kubernetes, 3 to 4 worker nodes	16 to 32	32 to 64 GB	Cloud SSD, 10,000 IOPS
Global core	2,000 to 5,000+	Kubernetes, multi-zone	32 to 64	64 to 128 GB	Provisioned IOPS, 20,000+

Sizing recording storage

Recording storage grows every day and is easy to underestimate. Measure the average stored size of a one-hour SSH, RDP and database session during your proof of concept, then calculate: sessions per day by type, times average size, times retention days, plus headroom for growth. SWOT PAM can write recordings to Amazon S3 or MinIO by setting RECORDING_STORAGE_BACKEND=s3, so capacity grows with the bucket rather than the PAM host. Rudratic recommends enabling Object Lock, which AWS describes as a write-once-read-many model that stops object versions being overwritten or deleted during a retention period. Read more on what to record in our session recording glossary entry.

Where to place PAM in the network

The aim is a single path: operators reach the PAM proxies, and only the proxies reach privileged ports on targets. If an administrator can still open port 22 or 3389 directly, the PAM records only the sessions people choose to route through it.

Direction	Port	Service
Inbound from operators	443 (or 5000)	Web console
Inbound from operators	8080	API and WebSocket
Inbound from operators	2222, 33890	SSH proxy, RDP gateway
Inbound from operators	5454, 1521	PostgreSQL and Oracle proxies
Internal only	9095, 5432	Database GUI proxy, PAM’s own PostgreSQL
Outbound to targets	22, 3389, 5432, 1521	Linux, Windows and database targets

The architecture documentation says the PAM’s own PostgreSQL on 5432 should never be exposed publicly. In practice that means three rules:

• Operator networks may reach only the inbound PAM ports listed above.
• Target firewalls accept SSH, RDP and database connections only from the PAM proxy addresses.
• The PAM database, the vault master key and the recording bucket sit in a zone no operator can reach directly.

Pair the network rules with the identity side: SWOT PAM federates over SAML 2.0 or OIDC with Okta, Microsoft Entra ID, PingFederate or Google Workspace, and an LDAP or Active Directory sync disables terminated accounts. Our privileged session monitoring overview covers what the proxies inspect once traffic flows through them.

Deploying PAM on an air-gapped site

Air-gapped networks remove the shortcuts most installers rely on: no image registry, no package mirror, no licence call-home. The SWOT PAM administrator guide describes an offline bundle, swot-pam-release.tar.gz, that needs no source compilation and no outbound internet access:

tar -xzf swot-pam-release.tar.gz && cd swot-pam-release
cp .env.example .env    # set SECRET_ADMIN_PASSWORD before first boot
chmod +x deploy.sh
./deploy.sh             # loads prebuilt images and starts the stack
docker compose ps       # checks service health

Plan three things beyond the install. First, a transfer process for future release bundles that matches your media-handling rules. Second, identity and directory services inside the enclave, because SAML, OIDC and LDAP all need a reachable endpoint. Third, time synchronisation, since TOTP codes and hash-chained audit events depend on correct clocks.

High availability checklist for a PAM deployment

A PAM outage blocks every administrator, so design for failure from the start. Use this checklist when you write the deployment design:

1. Run at least two instances of each stateless component (API server, SSH proxy, RDP gateway) behind a load balancer.
2. Put PostgreSQL on a managed or clustered service with automated failover, and test the failover with sessions open.
3. Store recordings in object storage with Object Lock, outside the PAM hosts.
4. Keep the vault master key outside the database, as SWOT PAM does, and back it up separately under dual control.
5. Document a break-glass procedure for a total PAM outage, and alert on every use of it.
6. Forward audit events to your SIEM so evidence survives the loss of the PAM database.
7. Rehearse an upgrade in a staging copy and note what happens to live sessions.

Our cloud infrastructure services team can review a design against this list.

Next steps

PAM deployment architecture comes down to a few decisions: VM or Kubernetes, where state lives, how the network forces sessions through the proxies, and how much recording storage you need. Size from peak concurrent sessions and measured recordings, then confirm the tier in a proof of concept. To see how SWOT PAM fits your network and identity provider, book a demo or read the SWOT PAM product overview.