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 platform for secure access to servers, Kubernetes clusters, databases, applications, and APIs. It gives people and workloads short-lived credentials, checks their permissions, and records supported activity against their identity. Your team operates the access platform and controls where audit logs and session recordings are stored.

See How It Works for the architecture and Features for supported capabilities.

Who is AlmaForge built for?​

AlmaForge is designed for infrastructure, platform, SRE, and security teams that need to control production access while keeping engineers on familiar tools. It suits organizations that need to run the access platform within their own security boundary and retain audit evidence under their own policies.

The same access model covers people, CI/CD pipelines, automation, and AI agents. See the Security Whitepaper for the security model.

How is AlmaForge different from legacy PAM?​

Credential vaulting manages existing passwords and keys. AlmaForge issues short-lived access credentials tied to identity and policy. Engineers authenticate through SSO and receive access to the resources their roles permit, with temporary elevation through access requests. This reduces reliance on distributing permanent SSH keys or sharing target-account passwords.

Credentials used by target services and integrations still need to be managed. See the Security Whitepaper for the access model and its boundaries.

How is AlmaForge different from a corporate VPN?​

A VPN provides network connectivity. AlmaForge authorizes access to individual infrastructure resources based on identity and policy, and records supported activity through that access path. It can operate alongside your VPN or provide access through its own proxy and agent connections.

Network and host controls must still prevent direct access that bypasses AlmaForge. See How It Works for the connection paths.

Does AlmaForge replace our identity provider?​

No. Your OIDC-compatible identity provider remains the source of human identity and MFA. AlmaForge maps verified identity attributes, such as group membership, to access roles when a user signs in.

For offboarding, disable sign-in at the identity provider and apply an AlmaForge lock to block credentials already issued. See Single Sign-On for provider setup.

What protocols does AlmaForge support?​

AlmaForge provides access to:

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

See Features for protocol coverage. Resources are registered by the agents that serve them.

What integrations does AlmaForge support?​

AlmaForge integrates with identity providers, access-review workflows, and workload identity systems:

  • Single sign-on: Google Workspace, Microsoft Entra ID, Okta, GitHub, and other OIDC-compatible providers.
  • Access-request workflows: Slack, Telegram, PagerDuty, Jira, and custom workflows through the authorization workflow API.
  • Workload identity: GitHub Actions, GitLab CI, CircleCI, and Spacelift.

See Single Sign-On, Just-in-Time Access, and Workload Identity for setup and supported integration behavior.

Can engineers keep using their existing tools?​

Yes. Engineers can use ssh, kubectl, psql, mysql, and their browser. The AlmaForge CLI handles sign-in and credentials, then configures the native client or opens a local proxy as the protocol requires. A browser terminal is also available for SSH access.

See the CLI guide for setup.

Does AlmaForge require an agent on every target?​

No. One database or application agent can serve multiple targets it can reach. A Kubernetes agent connects its configured clusters to the access platform.

For SSH, you can install an agent on the host or configure OpenSSH to trust AlmaForge's certificate authority. Agentless SSH requires the Proxy to reach the host directly and the target OS account to exist already. Sessions are recorded at the Proxy. You can combine agent-based and agentless SSH access in the same deployment. See the agent model.

How does just-in-time access work?​

Users request access to a role or resource for a specific purpose and duration. Policy can approve the request from verified context, such as on-call status, or require designated reviewers. Reviewers act through the Web UI, CLI, or API, with integrations providing notifications and workflow automation.

After approval, the user refreshes their credentials to receive the additional permissions. Those credentials expire within the approved window. Audit events record the request, review decisions, and grant. Whether an open session ends at certificate expiry depends on session-expiry policy. See Just-in-Time Access for the full lifecycle.

Can we enforce MFA?​

Yes. Configure MFA for the AlmaForge application in your identity provider. The provider completes its authentication checks before AlmaForge issues access credentials.

AlmaForge uses your provider's MFA policy. Access-request approvals and duration limits provide additional controls after sign-in. See Single Sign-On for configuration.

How does AlmaForge replace long-lived access keys?​

AlmaForge replaces long-lived user access keys with short-lived certificates, reducing the credentials your team must distribute and rotate. Its built-in certificate authority issues SSH and X.509 certificates carrying identity, roles, and an expiration time. Engineers authenticate through SSO to obtain credentials, while workloads obtain and renew them according to policy.

For an earlier cutoff, apply a lock. Proxies and agents enforce it once received, typically within seconds over a healthy connection to Auth.

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

AlmaForge gives workloads their own identities, roles, and short-lived credentials. Supported provider-backed join methods verify identity from the workload's execution environment, avoiding a shared AlmaForge join secret in code or configuration.

A pipeline, service, or AI agent can then access the resources its role permits. Audit events attribute supported activity to that workload. See Workload Identity for supported providers, join methods, and renewal behavior.

How does AlmaForge limit lateral movement?​

AlmaForge checks each connection against the identity's roles and the requested resource. Temporary access requests can narrow elevated privileges to the resources and duration a task requires.

Target systems still enforce their own permissions: Kubernetes authorizes API requests, databases enforce database-account privileges, and operating systems control what an SSH login can do. Network and host controls must also prevent direct access that bypasses AlmaForge. See the Security Whitepaper for these security boundaries.

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

AlmaForge records terminal output and timing for playback of SSH and interactive Kubernetes sessions. Database queries and Kubernetes API requests produce structured audit events. Session records identify the connecting person or workload and reference an access request when temporary access was used.

Capture depends on the protocol and recording policy. SSH recording is best-effort by default. Strict policy can require recording for a session to proceed. You control recording storage, retention, encryption, and access.

How does AlmaForge handle audit logging and SIEM integration?​

AlmaForge emits structured JSON events for authentication, access requests, configuration changes, and supported protocol activity. Events identify the person or workload alongside the target account, such as root or postgres. You can collect them into your SIEM for investigation and correlation with other security records.

Non-interactive SSH commands produce command events. Commands typed in an interactive shell are visible through terminal replay, rather than a separate audit event for each command. See audit storage for collection and storage options.

How does AlmaForge help with compliance?​

AlmaForge provides identity-linked access records, approval history, and terminal recordings that can support access-control and audit requirements under SOC 2, PCI DSS, DORA, and ISO 27001. Your organization retains the evidence in its own infrastructure and controls retention and access.

While AlmaForge provides the technical access controls and audit evidence needed for reviews, formal compliance depends on your deployment architecture and operational practices. See the Security Whitepaper for the security model and evidence available.

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. Your deployment does not report its activity to us.

Services you configure, such as your identity provider, notification integrations, tracing collector, or Let's Encrypt, have their own network connections. See Networking for connection requirements. The website and support services are covered separately by the Privacy Policy.

Where can AlmaForge be deployed?​

AlmaForge runs on Linux hosts or Kubernetes within your secure perimeter, whether on-prem, cloud, or hybrid. The server supports amd64 and arm64. The CLI is available for Linux and macOS on both architectures. See System Requirements for platform requirements, and the Linux or Kubernetes guide for installation.

Air-gapped deployments use locally available release artifacts, trusted TLS certificates, and a reachable identity provider. The access platform requires connectivity within the deployment, but no vendor service or internet connection. See Air-Gapped Deployment.

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

Yes. Agents establish outbound connections to the Proxy, allowing access to private resources without public target IPs, inbound firewall ports on the resource network, or VPC peering.

Agentless SSH uses a different path: the Proxy must be able to connect directly to the target host. See Networking for firewall and routing requirements.

How quickly can we get a running deployment?​

The Standalone guide takes about 30 minutes once the Linux host, DNS, and identity-provider prerequisites are ready. It covers an evaluation cluster and your first server connection.

Production deployment also requires decisions about storage, availability, and hardening. Use the Linux or Kubernetes deployment guide to plan those requirements.

How does AlmaForge handle high availability and upgrades?​

AlmaForge supports multiple service replicas and external storage in a single-region cluster. Redundant load balancing and HA-capable storage are part of the deployment design. Healthy replicas can accept new connections after a replica fails, but sessions on a failed Proxy end. Recording durability depends on the storage and recording policy. See High Availability for the topology and failure modes.

You control when upgrades happen. AlmaForge does not update itself in the background. Pin the package or container version, then follow the upgrade procedure for your deployment.

Does AlmaForge introduce a single point of failure?​

AlmaForge supports highly available deployments. A resilient deployment runs redundant access services, load balancers, identity providers, and storage across independent failure domains. Test recovery for each dependency.

During an Auth outage, proxies and agents can use cached policy and unexpired credentials, subject to locking mode and session limits. Auth is still required for new sign-ins and credential issuance. A Proxy failure ends its active connections. See High Availability for the detailed behavior.

Maintain an independent way to reach your infrastructure during an outage, such as console access. AlmaForge's break-glass procedure can restore administrative access when SSO is unavailable, but requires a running Auth service and its state backend.

How is AlmaForge licensed?​

AlmaForge is available under a self-hosted Free License or an Enterprise License Agreement.

Enterprise software rights are perpetual: you can continue running the version received under your agreement when support ends. Renewal extends maintenance, technical support, and access to new versions. Enterprise customers can also request a security review during procurement, subject to agreement.

How is AlmaForge priced?​

AlmaForge Free is available at no charge under the Free License. It follows the latest release and has published limits for human users, resources, and clusters. It is not a time-limited trial.

Enterprise pricing is tailored to deployment capacity and support requirements. Enterprise adds supported stable releases and contract-backed technical support, with vendor review assistance and professional services available under the agreement.

See Pricing to compare editions and support plans, or contact us for a proposal.

Do bots and workload identities count toward the user limit?​

No. The Free edition's 10-user limit applies to human users. Bots and workload identities, including CI/CD pipelines, automation, and AI agents, are unlimited and do not count toward that limit. See Free usage limits.

Next steps​

Review the features, learn how it works, check the requirements, or follow the Standalone guide.