Features
AlmaForge is a context-driven, self-hosted access plane for engineering teams, automation, and AI agents. It replaces permanent credentials and fragmented bastions with just-in-time authorization, short-lived certificates, and complete session replay, running entirely inside your own infrastructure with zero traffic routed through a third-party SaaS vendor.
Core features of AlmaForge:
- Unified Access Plane (protect servers, databases, Kubernetes, internal apps, and APIs)
- Just-in-Time Access (time-bound, ephemeral access requests and approvals)
- Fine-Grained Controls (SSO role mapping, label scoping, protocol permissions, and instant revocation)
- Ephemeral Credentials (short-lived certificates and workload identity)
- Replay and Audit (video-like session replay, protocol-aware audit events, and SIEM streaming)
- Self-Hosted Control Plane (runs in your environment, no telemetry, and air-gap ready)
- Engineering-Friendly (security as code, GitOps workflows, and a kubectl-style CLI)
- Built for AI Agents (scoped requests, zero leaked secrets, and instant cutoff)
Unified Access Plane
Modern infrastructure rarely lives in one place. Across multiple cloud providers, VPCs, and on-prem data centers, access fragments into a maze of VPNs, SSH bastions, static database passwords, and cluster tokens. AlmaForge replaces that patchwork with one unified access plane for your entire fleet.
Engineers sign in through SSO and connect to authorized resources with standard ssh, kubectl, psql, and mysql clients. Internal web apps and APIs sit behind the same SSO and policy, reached through an AlmaForge URL without a VPN or public ingress (see Application Access). CI/CD jobs, automation, and AI agents authenticate through workload identity and receive short-lived credentials under the same policy model.
Infrastructure at a Glance
Ephemeral infrastructure makes static wikis and saved IP lists obsolete. When machines spin up and retire at machine speed, AlmaForge discovers resources as they register dynamically across clouds and clusters. Engineers see what actually exists, verify their permissions, and connect.
Low-Friction Access
Keep the tools. Change the access model. Engineers continue to use ssh, kubectl, psql, shell scripts, and IDE integrations while AlmaForge handles authentication and certificate issuance transparently behind the connection. There are zero proprietary SDKs to import and zero connection logic rewrites. Your microservices, CI scripts, and database drivers connect through native protocols unmodified. A security model that engineers have no reason to bypass is fundamentally stronger than one enforced by policy alone.
alma db login --db-name=orders payments-dbpsql "service=almaforge.example.com-payments-db"psql (18.6 (Homebrew), server 13.23)SSL connection (protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256, compression: off, ALPN: none)Type "help" for help.
orders=> SELECT current_user; current_user------------------- alice@example.com(1 row)Connect from Anywhere
Eliminate open inbound firewall ports, brittle site-to-site VPNs, and flat network peering. AlmaForge connects engineers and workloads to private infrastructure through outbound reverse tunnels. Agents in private VPCs and bare-metal environments dial out to the access plane, keeping target machines completely unexposed to the public internet.
Just-in-Time Access
Grant access for the task, not the job title. When engineers change production code, changes go through pull requests with scoped intent, peer review, and approval. Direct privileged access should meet the same standard. AlmaForge delivers Zero Standing Privilege: time-bound, contextual grants replace standing privileges and expire when the task ends. Authorization evaluates real operational context: who is requesting, target resource and role labels, stated reason, active Jira tickets or PagerDuty on-call shifts, and a strict time limit. See Just-in-Time Access for the complete request lifecycle and CLI commands.
Scoped Access Requests
Request a specific role or a single database, server, or Kubernetes cluster. Every request records the operational reason, target scope, and required duration. Instead of granting blanket admin rights, permissions attach strictly to the task and expire when the window closes.
With no standing access, Alice asks for the prod-ssh role for one hour and names the incident.
Approval Policies
Approving a person by title is a rubber stamp. Approving a bounded task is a control. In AlmaForge, approvers see the exact target resource, stated reason, and countdown timer. Policies define eligible reviewers, require two or more sign-offs for critical systems, and automatically revoke grants when the timer expires.
Alice is on call for the service, so the on-call integration approves her request in seconds.
This functionality is in early preview and will be available in future releases.
Workflow Integrations
Route approvals directly into Slack and Telegram with one-click reviews. Mirror requests into Jira issues to keep compliance tickets synchronized. Operational context can drive decisions: during active incidents, the PagerDuty plugin checks the requester's on-call schedule to approve temporary emergency access immediately without waiting for human sign-offs.
Fine-Grained Controls
Network proximity is not an access control. Traditional firewalls and jump hosts make decisions based on where traffic originates rather than who is acting and what they are authorized to do. AlmaForge replaces coarse perimeter access with identity-enforced boundaries that constrain privileges by purpose and protocol. See the RBAC Guide for role schemas and built-in templates.
SSO Role Mapping
Zero local accounts to provision, rotate, or forget during offboarding. AlmaForge delegates authentication to your existing identity provider: Google Workspace, Microsoft Entra ID, Okta, GitHub, or any OIDC provider such as Keycloak. Multi-factor authentication remains with your IdP, keeping enforcement and conditional access in a single auditable place. Access policies map directly to IdP groups and OIDC claims instead of static user lists. When an engineer changes teams or joins an on-call rotation, their permissions update across all clusters and servers immediately upon their next login.
Label-Based Scoping
Instead of managing access per host or per IP address, AlmaForge enforces policy through resource labels like env: staging or region: us-east-1. When new infrastructure spins up and registers, it inherits the correct role boundaries automatically, with zero manual firewall or policy updates.
Protocol-Level Permissions
Reaching a resource is only half of authorization. Access policies restrict which accounts, roles, and databases an identity can use on the destination:
- Servers: Scope allowed OS logins (such as
ubuntuorapp-deployer) and prevent routine logins asroot. - Databases: Restrict connection to specific database names and database users (such as
readonly_analystinstead ofdb_admin). - Kubernetes: Map authenticated identities directly to native Kubernetes groups and impersonation users (such as
viewversuscluster-admin).
Instant Revocation
When a credential is compromised or an employee is terminated, you cannot afford to wait for certificates to expire. Applying a cluster lock severs active sessions and blocks the target user, role, OS login, or node across all proxies and agents in seconds:
alma create lock --target-user=alice@example.com --message="Incident IR-42"See Revoking access.
Ephemeral Credentials
Standing privileges are persistence debt. Every long-lived credential, permanent role assignment, or SSH key that outlives its task is an unmanaged liability. AlmaForge replaces static credentials with short-lived X.509 and SSH certificates issued on demand and bound to verified identity. The same model covers people, CI/CD jobs, and automation workloads, eliminating static passwords, shared accounts, and long-lived tokens for routine access.
Short-Lived Certificates
Target servers, clusters, and databases trust the AlmaForge Certificate Authority instead of individual user keys. When an engineer connects, AlmaForge issues an ephemeral certificate that expires when its TTL runs out. Offboarding in your IdP blocks the next login. A lock cuts off what is already issued, with no scattered copies of private keys to hunt down.
Workload Identity
Machines need access too, but static service account keys and CI/CD secret variables are prime leak vectors. AlmaForge extends cryptographic, short-lived access to GitHub Actions, GitLab CI, CircleCI, Kubernetes pods, and automation scripts. Workloads authenticate using cryptographic proof from their runtime environment without storing shared join secrets or long-lived API keys. See the Workload Identity guide.
# Nightly GitHub Actions job that queries a database with no stored secret.
name: nightly-report
on:
schedule:
- cron: '17 2 * * *'
permissions:
id-token: write
jobs:
report:
runs-on: ubuntu-latest
env:
ALMA_PROXY: almaforge.example.com:443
ALMA_CLIENT_ID: ci-orders-readonly
ALMA_JOIN_METHOD: github
steps:
- run: curl -fL https://get.almaforge.com/install.sh | sh
- run: alma db connect --db-user=readonly --db-name=orders orders-db <<< "SELECT count(*) FROM orders;"
Replay and Audit
Most audit systems produce data. Very few produce evidence. Traditional logs leave security teams on a scavenger hunt across disconnected servers and fragmented formats while an incident is unfolding. AlmaForge captures privileged activity through protocol-aware proxies, turning raw exhaust into structured, defensible evidence. All recordings and audit events stream directly to storage you own and control (such as S3, GCS, or local disks), where your organization enforces its own retention, encryption, and access policies.
Terminal Replay
Replay interactive SSH and Kubernetes sessions in your browser with full keystroke timing and command visibility. Follow exactly what an operator saw, typed, and executed during an incident or routine maintenance without parsing raw terminal escape codes.
Bob opens the recordings and plays Alice's session back, exactly as she typed it.
Structured Audit Events
Connections terminate at protocol-aware proxies that understand the wire format. Instead of opaque TCP streams, AlmaForge captures structured events: exact SQL queries such as DROP TABLE, Kubernetes API verbs and namespaces, and SSH exec commands. Every event binds the authenticated SSO identity directly to target accounts (like root or postgres), emitted as structured JSON ready for ingestion by Splunk, Datadog, or Elastic.
The event below records alice@example.com running DROP TABLE as the postgres user on payments-db, with the session ID that ties it to everything else in that session.
{
"apiVersion": "almaforge.com/v1",
"kind": "AuditEvent",
"spec": {
"type": "DatabaseSessionQuery",
"code": "TDB02I",
"timestamp": "2026-05-18T22:24:11.503000Z",
"actor": { "name": "alice@example.com", "type": "user" },
"session": { "id": "1cdcd17c-9d9f-4806-9a3c-dffe3f873b0c" },
"database": {
"service": "payments-db",
"protocol": "postgres",
"name": "orders",
"user": "postgres"
},
"databaseSessionQuery": { "dbQuery": "DROP TABLE invoices;" }
}
}
Self-Hosted Control Plane
AlmaForge runs entirely inside your environment. No vendor proxy sits in the access path, no third-party cloud can lock you out, and no telemetry leaves your network. Sized to your deployment, with no per-user fees, license servers, or kill switches.
Run Anywhere
Deploy on bare metal, Linux VMs (APT, YUM, binary), or Kubernetes across AWS, Azure, Google Cloud, and on-premises data centers. Ships amd64 and arm64 builds out of the box with zero cloud lock-in.
No Telemetry
AlmaForge sends no telemetry pings, crash reports, usage tracking, or phone-home traffic. What happens in your perimeter stays in your perimeter: the AlmaForge team has zero visibility into what resources you run, who accesses them, or how your infrastructure is configured. It operates entirely inside your network with no required external services. If the public internet drops, your access plane keeps working.
Air-Gap Ready
Operate in restricted, classified, or dark-site networks without public internet access. Air-gapped clusters run using internal identity providers, locally supplied certificates, and mirrored release artifacts.
Engineering-Friendly
Access infrastructure should not create operational drag or complex maintenance overhead. AlmaForge ships as two static Go binaries with built-in ACME certificate rotation, native Prometheus /metrics, declarative GitOps YAML in Git, and terminal-native CLI ergonomics.
Security as Code
Everything you configure in AlmaForge is code. Roles, SSO connectors, and integrations are declarative YAML resources. Keep them in Git, review changes in pull requests, and deploy with alma apply -f in CI.
Show example
# Platform on-call engineer: team-scoped staging access every day, and a path
# to production that needs a reason, two approvals, and an end time.
apiVersion: almaforge.com/v1
kind: Role
metadata:
name: platform-oncall
spec:
options:
maxSessionTTL: 8h
disconnectExpiredCert: true
requestAccess: reason
recordSession:
default: strict
allow:
# Staging servers, plus any server owned by one of the user's SSO teams.
serverLabelsExpression: |
labels["env"] == "staging" ||
contains(user.spec.traits["teams"], labels["team"])
serverLogins: ['{{external.preferred_username}}']
kubernetesLabels:
env: staging
kubernetesGroups: ['developers']
kubernetesResources:
- kind: '*'
namespace: 'platform'
name: '*'
verbs: [get, list, watch]
- kind: pod
namespace: 'platform'
name: '*'
verbs: [exec, portforward]
databaseLabels:
env: staging
databaseUsers: ['{{email.local(external.email)}}']
databaseNames: ['*']
request:
roles: ['prod-*']
maxDuration: 4h
thresholds:
- approve: 2
deny: 1
deny:
# Deny wins over any allow, so cardholder data stays out of reach even
# when another role grants production.
serverLabels:
pci: cde
appLabels:
pci: cde
databaseLabels:
pci: cde
kubernetesLabels:
pci: cde
kubectl-Style CLI
Manage access from the terminal with the verbs operators already know from kubectl: apply, get, edit, and delete, with -o yaml and -o json for structured output. Script your workflows or apply role changes directly from CI/CD.
alma apply -f contractor.yamlrole 'contractor' has been createdalma get rolesRole Allowed to login as Server Labels Access to resources---------- ------------------- ----------------- -------------------auditor <all nodes> *:list,readcontractor ubuntu env=[staging]dev ubuntu env=[dev staging]alma edit role/contractorrole 'contractor' has been updatedalma delete role/contractorrole "contractor" has been deletedBuilt for AI Agents
Autonomous tools like Claude Code, Codex, and Antigravity now run kubectl and psql against live infrastructure. Giving an agent a static service account leaves permanent credentials lingering in prompt memory. AlmaForge gives agents the same guardrails as human engineers:
- Live inventory discovery: Agents explore what exists across servers, clusters, and databases in seconds (
alma get node,kube,db -o yaml) instead of guessing hostnames from stale wikis. - Just-in-time access requests: Agents start with zero standing privilege and request scoped access on demand (
alma request create) for human or automated approval. - No secrets in prompt memory: Agents authenticate through short-lived certificates. No static API keys, database passwords, or root SSH keys enter context windows or prompt logs.
- Complete recorded accountability: Every SQL query, Kubernetes API call, and SSH exec command is captured in structured audit logs, with terminal replay for interactive sessions.
- One-command cutoff: If an agent goes off course or hallucinates, a single cluster lock severs its access across all infrastructure in seconds.
Alice asks Claude Code why checkout times out. It starts by listing the clusters AlmaForge lets it reach.
The agent reads the checkout logs on prod-eu. Its database queries time out.
With no standing access to the database, the agent requests read-only access and waits for approval.
The agent finds billing-worker holding a lock that checkout waits on.
The billing-worker logs show why it never commits. The grant expires on its own.
Next Steps
The fastest way to get started is on your own infrastructure with your own tools: