Skip to main content

System Requirements

AlmaForge runs on Linux hosts and Kubernetes in your cloud account, data center, or air-gapped environment. For a first installation, use the Standalone guide with the evaluation requirements below.

TL;DR​

A single-host evaluation needs a supported Linux host with 2 vCPUs, 2 GB RAM, 10 GB of free disk, and sudo access. Have a DNS name, inbound TCP/443, and an OIDC identity provider ready. The Standalone guide uses local storage and Let's Encrypt certificates.

For production, choose Linux or Kubernetes. Those guides cover multiple replicas, external storage, and the network layout.

Platforms​

AlmaForge is designed for production use on Linux. Major Linux distributions (APT- and RPM-based) and Kubernetes are supported on amd64 (x86_64) and arm64 (aarch64). Client binaries are also available for macOS installation on Intel and Apple Silicon. Windows users should use Windows Subsystem for Linux.

Production baseline:

  • Official Docker image
  • Official RPM or APT packages on long-term supported server Linux with glibc 2.28 or newer:
    • RHEL / AlmaLinux / Rocky Linux / Oracle Linux 8+
    • Ubuntu 22.04 LTS+
    • Debian 12+

For package installation, see the Linux deployment guide. Need validation for a specific platform or distro? Contact us.

Hardware​

Use these numbers for evaluation clusters and small single-node deployments.

Minimum resource requirements:

  • vCPU: 2
  • RAM: 2 GB
  • Disk: 10 GB free (if local storage is used)
  • Architecture: amd64 (x86_64) or arm64 (aarch64)

These are baseline requirements for evaluation deployments. Larger or high-availability deployments may require additional resources. The production Linux guide starts at 2 vCPU, 2 GB RAM, and 10 GB of free disk per cluster host when durable storage is external. For sizing guidance at scale, contact us.

Storage​

AlmaForge stores three persistent data streams: cluster state, audit events, and session recordings. Cluster state holds security-critical configuration such as roles, connectors, node membership, active sessions, and dynamic configuration. Audit events are structured records for investigations and compliance. Session recordings are stored separately for playback.

Cluster state (choose one):

  • Local disk or persistent volume with SQLite backend (SSD recommended for production, single-node only)
  • etcd
  • PostgreSQL
  • DynamoDB
  • Firestore

Session recordings (choose one):

  • Local disk or persistent volume
  • S3 or S3-compatible storage
  • GCS
  • Azure Blob Storage

Audit event destinations (one or more):

  • Local files (the evaluation default)
  • PostgreSQL
  • DynamoDB
  • Firestore
  • Athena
  • Standard output for collection by an external logging system

For setup details and the full driver list, see Storage.

Containers​

AlmaForge can be deployed with Docker/Podman or Kubernetes:

  • OCI-compatible runtime (Docker, Podman, or containerd)
  • EKS, GKE, AKS, and OpenShift are supported
  • TCP LoadBalancer or ingress configured for TLS passthrough to expose network ports
  • Cluster DNS for service discovery and external name resolution
  • Persistent volumes if local storage is used

For production container and Kubernetes planning, contact us.

Time Sync​

Reliable time is required for authentication, TLS, and token validation.

  • NTP or chrony enabled on all servers
  • Keep clock skew under 30 seconds

See clock synchronization for operational guidance.

Authentication​

Every deployment needs an SSO identity provider that supports OIDC (Okta, Microsoft Entra, Google Workspace, or Keycloak).

  • An OIDC-compatible identity provider (OAuth 2.0 + OpenID Connect) is configured.
  • The OIDC application returns an email claim for the first administrator.

AlmaForge does not manage local user accounts.

Configure MFA at your identity provider. Start with the SSO Integration guide for provider setup and claim mapping, including the first administrator.

Network​

The default single-port endpoint must be reachable from user workstations, agents, and Let's Encrypt's validation servers:

  • TCP/443 for the Web UI, CLI, proxied protocols, agent connections, and automatic certificate validation

The cluster host also needs outbound HTTPS to the identity provider and, when enabled, Let's Encrypt. See egress requirements.

AlmaForge requires DNS records to access the UI and internal services. Set up A and/or AAAA records pointing to the public endpoint:

  • almaforge.example.com points to the host
  • *.almaforge.example.com also points to the host if you will publish web applications under that name
Cloudflare notice

If you're using Cloudflare, make sure the "orange cloud" is turned off (DNS-only, no CDN proxy).

The default setup uses AlmaForge's built-in Let's Encrypt integration to issue and renew TLS certificates. This requires public DNS and inbound TCP/443 for validation. See ACME configuration.

For a private endpoint or an organization-managed certificate, supply a certificate trusted by your clients and agents. It must cover the cluster hostname and any application hostnames you expose. See operator-supplied certificates.

For port layout, load balancers, and full TLS options, see Networking.

Multi-node Linux deployments add private service ports for state, diagnostics, metrics, and optional direct-Auth paths. See Cluster on Linux for the HA firewall matrix.

Browsers​

The web UI supports modern, evergreen browsers.

  • Chrome, Firefox, Edge, or Safari (current or previous major version recommended)
  • JavaScript enabled and cookies allowed for session-based authentication
  • TLS 1.2+ support

Next steps​

Follow the Standalone guide to install an evaluation cluster, or choose a production deployment on Linux or Kubernetes.