How It Works
AlmaForge secures every connection between your team, automated workloads, and private infrastructure. Instead of stitching together a VPN, bastion hosts, shared SSH keys, and database passwords, teams use one unified access path to servers, databases, Kubernetes clusters, and APIs. For every connection, AlmaForge answers three questions: who is connecting, what are they allowed to reach, and what happened during the session.
Engineers keep using ssh, kubectl, psql, and their browser. You operate the control plane and retain all audit records and session recordings inside your own perimeter.
Every connection passes through a single secure gateway on port 443. Instead of opening firewall holes or running a VPN, the gateway verifies your short-lived certificate, checks policy, and routes traffic directly to the destination server, cluster, or database.
High-level architecture
AlmaForge ships as two static binaries: alma for connecting clients (engineers, CI/CD, and AI agents) and almad for your infrastructure.
The server daemon (almad) bundles multiple services into a single binary:
- Auth Service: The central certificate authority and state engine. It issues short-lived certificates from verified identity claims, evaluates RBAC policies, and persists state, audit events, and session recordings to your own storage (such as PostgreSQL, DynamoDB, or S3). It governs access decisions without sitting in the active session stream.
- Proxy Service: The stateless entry gateway on TCP port 443. It serves the Web UI and API, terminates TLS, validates client certificates against the CA, and routes traffic to destination resources.
- Agents: Services running alongside servers, databases, and Kubernetes clusters. They dial outward to the Proxy over persistent reverse tunnels, allowing access into private networks without open inbound firewall ports or public IPs. (For environments where installing an agent is impossible, the Proxy can also connect directly to standard OpenSSH hosts agentlessly.)
A single almad process can run all services together on one host, or you can scale gateways and authority replicas independently across high-availability clusters. See High availability and Storage.
One connection, start to finish
Connecting through AlmaForge takes a single sign-in. Once authenticated, your local tools reach infrastructure transparently.
The workflow connects your identity to your resources in three simple phases:
- Sign in once with your SSO: Running
alma loginopens your identity provider (such as Okta, Microsoft Entra, or Google Workspace) to verify MFA and group memberships. AlmaForge maps those claims to roles and issues a short-lived cryptographic certificate. Automated pipelines and AI agents authenticate headlessly via workload identity. - Connect using native tools: Use your standard tools:
ssh,kubectl,psql, or your browser. The client transparently presents your certificate to the gateway on port 443 without needing standing SSH keys or database passwords. - Authorize and route: The gateway validates your certificate against cluster policy and forwards the session through the target's encrypted reverse tunnel. Target servers never store standing credentials, and every action is tied to your verified identity.
For protocol-specific details and configuration, see Server access, Kubernetes access, Database access, and Workload identity.
Certificates put an end time on access
Passwords and SSH keys keep working until every copy is revoked or rotated. Those copies spread across laptops, build systems, and runbooks. A short-lived certificate gives access a fixed end time instead.
The cluster's internal certificate authority signs user and workload credentials inside your control plane. User certificates last 12 hours by default, and role policies can enforce shorter windows. When a certificate expires, the user signs in again before opening a new connection. Active-session limits can terminate open connections when credentials expire. There is no long-lived access key to collect during offboarding or rotate later.
A certificate carries the role assignments and identity traits present when it was issued. Updating user roles at the identity provider takes effect on the next sign-in. Editing role permissions in AlmaForge updates subsequent access evaluations immediately once propagated to active services.
When access must end before a certificate expires, operators apply an immediate lock. The control plane propagates the lock across gateways and agents within seconds, terminating active sessions and blocking new connection attempts. See Revoking access and session limits.
Agents connect outward
Connecting to private infrastructure traditionally requires opening inbound firewall ports, maintaining bastion hosts, or managing complex site-to-site VPNs. AlmaForge eliminates inbound exposure by having agents connect outward.
An agent deployed alongside target resources dials outward to the gateway on port 443 and maintains an encrypted reverse tunnel. When an engineer opens a session, the gateway routes traffic through the existing reverse tunnel to the destination. Target servers need no public IP addresses and no open inbound firewall ports. They remain secure behind network address translation (NAT).
A cloud VPC, an on-premises data center, and an isolated edge enclave can all dial outward to the same self-hosted gateway. Engineers reach all of them through a unified access path with no VPC peering or cross-site network routing required.
For environments where deploying an agent is not possible, AlmaForge also supports agentless OpenSSH hosts reachable directly from the gateway. See OpenSSH agentless mode and Networking.
Zero standing privileges through temporary access
Engineers maintain minimal baseline roles for day-to-day work and request elevated privileges only when a specific task requires them.
An access request specifies the target resource or elevated role, a justification, and the requested duration. Access policies define approval thresholds, routing requests to reviewers in Slack, Telegram, the Web UI, or the CLI. Policies can also grant instant automated approval based on trusted operational context, such as verifying via PagerDuty that the requester is actively on call.
Once approved, the user's client refreshes its certificate to include the temporary role. The elevated certificate expires automatically when the granted window ends, eliminating the need to manually revoke permissions or track standing grants. See Just-in-time access and Role-based access control.
Follow the access trail
The audit log records sign-ins, connection attempts, access requests, policy decisions, resource changes, and protocol activity. Session events identify the connecting person or workload alongside the target account, providing cryptographic identity attribution even when using shared accounts like root or postgres. See the audit reference.
Recorded SSH terminals and Kubernetes exec and attach sessions can be replayed frame-by-frame with full command timing. Protocol audit events capture Kubernetes port-forward activity, database queries, and application requests. Capture follows your recording policy.
Audit events, session recordings, and cluster state remain in the storage backends you configure and operate inside your own perimeter. See Storage.
Where it runs
AlmaForge runs on Linux hosts or Kubernetes in your cloud account, data center, or air-gapped environment. Its core services operate inside that deployment boundary with no telemetry, usage reports, crash data, or connections to a license server. Customer-configured identity and workflow integrations connect only to the systems you choose.
Next Steps
Get started on your own infrastructure with your existing tools: