Install

System requirements

Wardengate runs as a small number of long-lived stateful services backed by a Postgres database and a Redis-compatible cache. The platform is deliberately boring on the infrastructure side — if you can run an ordinary web application with a database, a queue, and an object store, you can run Wardengate. The rest of this page spells out concrete sizing, OS support, and the handful of kernel knobs that matter under load.

Hardware sizing

The table below lists reference tiers for the combined control plane plus a single gateway replica. Add one gateway replica per 500 concurrent interactive sessions, and one control plane replica per additional availability zone. Recording storage is sized separately since it grows linearly with session hours and recording mode.

Recording capture is the most CPU-sensitive workload. Plan on roughly 0.25 vCPU per concurrent full-capture session on top of the table above, and budget around 60 MB of storage per hour of SSH session or 280 MB per hour of RDP session at default quality.

Supported operating systems

Wardengate is supported on mainstream 64-bit Linux distributions with a kernel of 5.10 or later. Packages and container images are built for both x86_64 and aarch64.

• Ubuntu 22.04 LTS and 24.04 LTS
• Debian 12 (Bookworm)
• Red Hat Enterprise Linux 9
• Rocky Linux 9 and AlmaLinux 9
• Amazon Linux 2023
• Alpine 3.19+ (container base only; not supported for host installs)

Older distributions may work but receive no regression testing. macOS and Windows are supported only as client platforms for wgctl, not as server hosts.

Kubernetes versions

The Helm chart is tested against the three most recent upstream Kubernetes releases. At the time of writing that means 1.27, 1.28, 1.29, and 1.30. Any CNCF-conformant distribution is expected to work — EKS, GKE, AKS, OpenShift, Rancher RKE2, and k3s are all covered by CI.

• Helm 3.12 or later
• A default StorageClass with ReadWriteOnce volumes for session scratch space
• An ingress controller of your choice (nginx, Traefik, HAProxy, Contour) or a cloud load balancer integration
• cert-manager is optional but recommended for automated TLS

Database

Wardengate uses PostgreSQL for all durable state: users, policies, audit metadata, session indexes, and the encrypted secret vault. A managed Postgres is strongly encouraged over a self-run instance — the access control plane is a poor place to debug replication.

• PostgreSQL 14, 15, or 16
• A dedicated database and role owned by Wardengate
• The pgcrypto and uuid-ossp extensions available
• TLS enforced on the connection; certificate validation enabled
• Baseline provisioning: 4 vCPU / 8 GB RAM / 50 GB storage for small deployments, scaling up with session volume

Cache and queue

A Redis-compatible cache holds session state, approval request fan-out, and rate-limit counters. Both Redis OSS 7+ and Valkey 7+ are supported. In single-node deployments, wardengate/server ships an embedded Valkey; for anything larger, run a separate instance or use a managed service such as ElastiCache or Memorystore.

• Redis 7.0+ or Valkey 7.2+
• Persistence not required; all data is reconstructible
• At least 512 MB of memory for small deployments
• ACL user dedicated to Wardengate, or password authentication

Network ports

The ports below are the defaults baked into the container image and Helm chart. Everything is configurable, but changing a port rarely pays for itself — prefer to firewall what you do not use.

Outbound connectivity

Wardengate does not phone home for licensing or telemetry, but the control plane does need to reach a handful of external services to function as most teams configure it. An offline install is documented separately for the rest.

• Your identity provider’s metadata endpoint (SAML, OIDC, or SCIM)
• The S3-compatible object store used for session recordings
• SMTP relay or a transactional email provider for invites and approvals
• An ACME directory (Let’s Encrypt, ZeroSSL) if you opt into automated TLS
• Webhook destinations for Slack, Microsoft Teams, PagerDuty, or your SIEM
• The image registry during upgrades (Docker Hub, GHCR, or your mirror)

TLS certificates

The control plane listens on HTTPS only; plaintext HTTP is not supported, even in dev. Provide either a cert and key for the public hostname or an ACME configuration. Internally, every component authenticates with mutual TLS using certificates issued by an embedded intermediate CA — operators do not need to manage those certificates.

• Certificate chain in PEM format, including intermediates
• Private key in PKCS#8 PEM, 2048-bit RSA or P-256 ECDSA
• Subject alternative names covering every hostname users reach
• If you use a private CA, distribute the root to user workstations

Filesystem prerequisites

The server writes to two directories at runtime. On a Linux host install, create them ahead of time and chown to the Wardengate service user. In containers, mount them as volumes.

• /var/lib/wardengate/data — durable state (keys, certs, local config)
• /var/lib/wardengate/recordings — scratch buffer before upload to object storage

Use a local filesystem that supports fsync and atomic renames (ext4, xfs, or zfs). NFS is not supported for the recording scratch path; it is fine for the data directory if you accept the latency.

Kernel parameters

A busy gateway proxies thousands of long-lived TCP connections. The stock kernel limits on most distributions are too conservative. Drop a file into /etc/sysctl.d/ and bump file descriptor limits for the service user.

# /etc/sysctl.d/60-wardengate.conf
net.core.somaxconn              = 4096
net.ipv4.tcp_max_syn_backlog    = 8192
net.ipv4.ip_local_port_range    = 10000 65535
net.netfilter.nf_conntrack_max  = 524288
net.nf_conntrack_max            = 524288
fs.file-max                     = 1048576
fs.nr_open                      = 1048576

# /etc/security/limits.d/wardengate.conf
wardengate soft nofile 524288
wardengate hard nofile 524288
wardengate soft nproc  65535
wardengate hard nproc  65535

On hosts running conntrack-heavy firewalls, keep an eye on /proc/sys/net/netfilter/nf_conntrack_count and alert before you hit the max — dropped connections under conntrack pressure are the single most common cause of phantom session failures.

Browser requirements

The admin console and the web-based RDP/SSH clients target evergreen browsers. Officially supported: the current and previous major versions of Chrome, Edge, Firefox, and Safari. The web client uses WebAssembly and WebSockets; both must be reachable without being rewritten by an intermediate proxy.

Related

• Docker install — single-node quickstart
• Kubernetes & Helm — production chart
• High availability — multi-replica topologies