Skip to main content
This page is in progress
This page is not finished yet and may not be complete. It is not listed in the navigation.

FAQ

What is AlmaForge?​

AlmaForge is a self-hosted infrastructure access platform for servers, databases, Kubernetes clusters, internal applications, APIs, and services. It issues short-lived credentials to people and workloads, applies resource-level policy, and records supported activity against the authenticated identity. Engineers keep using native tools such as ssh, kubectl, and psql. You operate the control plane, storage, and external integrations, and AlmaForge collects no telemetry.

See How It Works for the architecture, Features for protocol coverage, and the Security Whitepaper for the security model.

Who is AlmaForge built for?​

AlmaForge is for infrastructure, SRE, and security teams that need governed production access through tools such as ssh, kubectl, and psql. It suits organizations that must operate their own access control plane and retain audit evidence under their own policies. The same identity model gives CI/CD pipelines, AI agents, and services short-lived credentials. Deployment options include cloud, on-premises, hybrid, and air-gapped networks.

For more details on the architecture and security model, see the Security Whitepaper. For a full overview of functionality, see Features.

How is AlmaForge different from legacy PAM?​

Credential vaulting manages existing passwords and keys. AlmaForge issues short-lived certificates tied to a verified identity and policy, so users do not need a permanent SSH key or a shared password for access through AlmaForge. Access requests add time-bound privileges, while protocol audit events and terminal recordings provide evidence for review. Existing credentials used by target services and integrations remain under your control.

For a deeper explanation of the security architecture and design principles, see the Security Whitepaper.

How is AlmaForge different from a corporate VPN?​

AlmaForge controls access to infrastructure resources and can operate behind your corporate VPN or without one. A VPN provides network connectivity. AlmaForge checks the connecting identity and its permissions for the requested resource. Users receive short-lived certificates carrying their roles and expiry, and reach SSH, Kubernetes, databases, and applications through the access plane. Network and host controls remain necessary to prevent direct access that bypasses AlmaForge.

For a deeper explanation of the security architecture and design principles, see the Security Whitepaper.

Does AlmaForge replace our identity provider?​

No. Your OIDC-compatible identity provider, such as Okta, Microsoft Entra ID, or Google Workspace, remains the source of human identity, group membership, and MFA. AlmaForge maps its verified attributes to roles when a user signs in. For offboarding, disable sign-in at the IdP and apply an AlmaForge lock to block existing credentials once it reaches the Proxy and agents, typically within seconds over a healthy Auth connection.

What protocols does AlmaForge support?​

AlmaForge proxies the following protocols through its access plane:

  • SSH for Linux and Unix servers, containers, and port forwarding.
  • Kubernetes API for cluster access through standard kubectl.
  • Database protocols for PostgreSQL, CockroachDB, MySQL, MongoDB, ClickHouse, Redis, Cassandra, Elasticsearch, OpenSearch, DynamoDB, and Snowflake.
  • HTTPS for internal web applications, APIs, and dashboards.

Dynamic discovery through AWS, Google Cloud, Azure, and Kubernetes APIs is not available today. Agents register the resources they serve.

For a full overview of functionality, see Features.

What integrations does AlmaForge support?​

AlmaForge supports these identity, review, incident-management, and automation integrations:

  • Identity providers: Okta, Google Workspace, Microsoft Entra ID, and other OIDC-compatible providers.
  • ChatOps integrations: Slack and Telegram. Microsoft Teams, Mattermost, Zulip, and Rocket.Chat integrations are not available today.
  • Incident and ticketing: PagerDuty, Jira, and custom request workflows via the authorization workflow API.
  • CI/CD and automation: GitHub Actions, GitLab CI, CircleCI, Spacelift, and CLI tools. Jenkins, Argo CD, and MCP support is not available today.

Can engineers keep using their existing tools?​

Yes. Engineers use ssh, kubectl, psql, mysql, and their browser. The AlmaForge CLI handles sign-in, obtains certificates, and configures native clients or opens a local proxy where the protocol requires it. Browser-based access is also available. See the CLI guide for setup.

Does AlmaForge require an agent on every target?​

AlmaForge uses agents to integrate resources into the access plane. One database or application agent can serve several targets it can reach. A Kubernetes agent registers its configured clusters and maintains an outbound connection to the Proxy. Engineers then access namespaces and resources through kubectl, with access policy and Kubernetes RBAC determining what they can do. On SSH targets, agents also support automatic OS user provisioning and terminal recording. See the agent model.

AlmaForge also supports agentless access for certain resources. In this mode the target host is configured to trust the AlmaForge certificate authority and the proxy connects directly over standard SSH. The system user must already exist on the host and sessions are recorded at the proxy level. Both modes can be mixed freely across an environment to match the requirements of each resource.

For more details about the architecture, see How It Works.

How does just-in-time access work?​

Users request temporary access to a role or resource and specify the target, duration, and reason. Policy either approves the request from verified context or sends it to designated reviewers. Reviewers can act in the Web UI, with alma request review, through the API, or through a custom integration built on the authorization workflow API. Slack and Telegram notify reviewers.

After approval, the requester refreshes their credentials to use the grant. Those credentials cannot outlive the approved window. Request and review events preserve who asked, who approved, and what was granted. Session-expiry policy controls whether an open session ends when its certificate expires. See request lifetimes for renewal and expiry behavior.

Can we enforce MFA?​

Yes. Your identity provider's MFA policy governs sign-in to AlmaForge. Require MFA for the AlmaForge application in your provider, using Google 2FA, Okta push, or Entra Conditional Access. AlmaForge issues user credentials after the provider completes those checks.

At request time, policy can evaluate verified on-call status. It can also require multiple reviewers and limit both grant and session duration.

How does AlmaForge replace long-lived access keys?​

AlmaForge replaces permanent user access keys with short-lived X.509 and SSH certificates, reducing the keys teams must distribute and rotate. Its built-in certificate authority issues credentials carrying identity, roles, and an expiry time. Access requests add temporary privileges to baseline roles. People sign in again when needed, while workload identities renew credentials within policy.

Offboarding AlmaForge access takes two actions. Disable sign-in at the IdP, then apply a lock to block existing credentials across the cluster. Proxies and agents refuse the identity once the lock arrives, typically within seconds over a healthy Auth connection.

How does workload identity work for CI/CD pipelines, automation, and AI agents?​

Provider-backed join methods let machines authenticate with an identity from their execution environment instead of a shared AlmaForge join secret. CI/CD pipelines in GitHub Actions, GitLab CI, CircleCI, and Spacelift receive short-lived, TTL-bound certificates. Jenkins support is not available today. Certificates remain valid until their TTL expires or a cluster lock blocks them.

AI agents and automation services use the same identity model. Supported platform join methods let them obtain short-lived credentials without storing a shared join secret in code or configuration. Audit events attribute supported activity to the workload identity. See Workload Identity.

Service-to-service authorization applies identity-based policies to workload connections through AlmaForge.

How does AlmaForge limit lateral movement?​

AlmaForge checks identity and permissions for connections through its access plane. Kubernetes requests use the permitted Kubernetes identity and remain subject to Kubernetes authorization. Database access checks constrain database identities, with the database enforcing their native privileges. SSH access checks constrain host logins, with the operating system enforcing permissions inside the session.

AlmaForge authorizes each connection to a database or host against the roles carried on the certificate. Roles and resource requests scope that access to the resources the task needs. Agents connect outward through reverse tunnels, and agentless SSH hosts accept SSH from the Proxy. Together, these controls restrict lateral movement through the access plane. Use network and host controls to restrict direct access and the actions an authorized account can take on the target.

What does session recording capture and how is it replayed?​

AlmaForge captures terminal output and timing for video-like playback of recorded SSH and interactive Kubernetes sessions. Database queries and Kubernetes API requests produce structured protocol events. Session records identify the connecting person or workload and carry access-request references when temporary access was used. Capture depends on the protocol and recording policy. SSH recording is best-effort by default. Strict policy can require it for a session to proceed.

Recordings are stored in infrastructure you control. You define the storage backend, retention, encryption, and access policy.

How does AlmaForge handle audit logging and SIEM integration?​

Structured JSON audit events cover authentication, access requests, configuration changes, and supported protocol activity. Events identify the authenticated person or workload alongside the target account, such as root or postgres. SSH exec requests produce command events, while commands typed in interactive shells are visible through terminal replay rather than a structured event for each command. Collect audit output into a SIEM such as Splunk, Datadog, or ELK for correlation, alerting, and investigation. See audit storage.

For a full overview of audit and recording capabilities, see Features.

How does AlmaForge help with compliance?​

AlmaForge keeps the access control plane and audit evidence in infrastructure you control, under your existing security and retention policies. It requires no vendor-hosted control plane. You choose any external integrations.

The evidence is in the access path. Access requests preserve the stated reason and reviews, session records identify the connecting person or workload, and terminal replay helps reconstruct activity. These capabilities can support access-control and audit work under SOC 2, PCI DSS, DORA, and ISO 27001. They do not by themselves establish compliance, which depends on the deployment and your organization's wider controls and practices.

For a deeper explanation of the security architecture and design principles, see the Security Whitepaper.

Does AlmaForge collect telemetry or call home?​

No. The AlmaForge server and CLI have no telemetry, usage analytics, automatic update checks, or license-server calls. They do connect to services you configure, such as your identity provider, notification destinations, tracing collector, or Let's Encrypt. See Networking for connection requirements and the Privacy Policy for the website and support services.

Where can AlmaForge be deployed?​

AlmaForge runs on Linux and Kubernetes in on-premises data centers, public or private cloud, hybrid environments, and air-gapped networks. Install through APT or YUM, binary tarballs, or container images. Linux packages support amd64 and arm64. The CLI also supports Apple Silicon Macs. Linux packages require glibc 2.28 or newer. A single control plane can manage access across multiple clouds, regions, and on-premises sites.

For air-gapped environments, transfer and verify signed release artifacts, provide TLS certificates trusted inside the network, and use a locally reachable identity provider. The cluster's own certificate authority issues internal credentials, and policy enforcement needs no vendor service. Installation and operation require connectivity within the deployment, but no internet access. See Air-Gapped Deployment.

For detailed installation instructions, see the Install guide.

Can AlmaForge access resources behind NAT or in private VPCs?​

Yes. Agents establish outbound reverse tunnels to the Proxy, reaching private resources without public target IPs, inbound firewall ports on the resource network, VPC peering, or site-to-site VPNs. See Networking for connection requirements, including the agentless SSH path.

How quickly can we get a running deployment?​

The Quick Start gets an evaluation deployment running in about ten minutes once the host, DNS, and identity-provider prerequisites are ready. Production setup also includes storage, availability, and hardening decisions.

The provided install script detects your platform and installs AlmaForge using the recommended method. It verifies the SHA-256 checksum when shasum or sha256sum is available, and the GPG signature when both gpg and gpgv are. For the other paths, follow the verification steps in the installation guide. For full control, APT, YUM, binary, Docker, and macOS installation paths are each documented step by step.

How does AlmaForge handle high availability and upgrades?​

The documented cluster topology is single-region. The control plane supports multiple replicas and external storage for state, audit events, and recordings. Use HA-capable storage and redundant load balancing. Healthy replicas can serve new connections after a replica fails, but connections on the failed Proxy end. Storage durability depends on the selected backends, and buffered recording data can be lost with a failed host. See High Availability for failure modes and recording policy.

Upgrades are explicit and fully operator-controlled. The product does not perform automatic self-upgrades or background updates. APT and YUM repositories support version pinning, Docker images should be pinned to specific tags, and binary installations are upgraded by deploying a specific versioned tarball. In all cases, the operator decides when and how upgrades are applied.

For detailed upgrade procedures, see Upgrades.

Does AlmaForge introduce a single point of failure?​

A deployment avoids a single control-plane failure point when service replicas, the load balancer, the identity provider, and storage span failure domains. Proxies and agents validate certificates against the cluster CA independently. During an Auth outage, they use cached policy and unexpired credentials according to the configured locking mode and session limits. Auth remains required for new sign-ins and credential issuance. A failed Proxy ends its active connections, while healthy replicas accept new ones. See High Availability.

As with any access management system, organizations should maintain independent break-glass access procedures, such as physical console access or pre-positioned local credentials stored in a hardware security module or sealed envelope process, for disaster recovery scenarios. AlmaForge does not prevent or interfere with these recovery paths.

How is AlmaForge licensed?​

AlmaForge is proprietary software built using open-source components. Dependencies include components licensed under Apache 2.0, MIT, BSD, and MPL-2.0. Their notices and license texts accompany the distribution in THIRD_PARTY_LICENSES.txt. AlmaForge is developed privately. Enterprise customers can request source access and security review during procurement, subject to agreement.

How is AlmaForge priced?​

Every Enterprise license includes the full platform. Your agreement sets deployment capacity and support. Buy once and keep running the versions your license covers. Renew for new releases and support, with no subscription or license-server checks.

See Pricing for licensing details.

Next steps​

Review the features, learn how it works, check the requirements, or follow the Quick Start.