Architecture

How Alpacon is put together, seen from where you sit: how your servers connect, how you reach them, and what gets recorded.

Overview

Alpacon gives your team one place to reach servers, prove who did what, and manage access, without standing SSH keys, VPNs, or open ports.

Three things come together:

  • Access: you connect as yourself, only for the servers and time window you asked for.
  • Governance: every session is approved where it matters, scoped to specific actions, and time-bound.
  • Audit: everything is recorded on one timeline and reviewed by AI risk analysis after the session ends.

How servers connect

Outbound-only agents

The Alpamon agent on each server makes an outbound connection to Alpacon and keeps it open. Nothing ever connects in to your server.

What this means for you:

  • No inbound ports to open, and no public SSH exposure (port 22 stays closed).
  • Works behind NAT, corporate firewalls, and proxies with no firewall changes.
  • All connections are encrypted end-to-end.
  • Sessions stay reliable through brief network drops and reconnect automatically.

Registering a server

Register a server from your workspace (Servers → Register Server) and run the generated installation script. The whole process takes a few minutes.

See the Quickstart guide for step-by-step instructions.

Once a server is registered, you get real-time status monitoring, connection alerts, and group-based access control for it.

How you connect

Connect as yourself

You reach servers as your own Alpacon identity, with no shared keys or per-server passwords to distribute. Your identity is your account on the server, so every action is attributable to you from the start.

You can open a browser terminal (Websh), transfer files (WebFTP), or run commands, with no client software or SSH keys to set up.

Access is requested, not standing

Access is granted just in time through a work session, not held open as a standing connection:

  1. You request a work session for specific servers, tools, and a time window.
  2. Alpacon authorizes it, and a Superuser approves it when required.
  3. You work from the browser or the CLI for the length of the session.
  4. Everything you do is recorded for audit.
  5. Access is released when the session ends or expires.

Identity and access management (IAM)

One place for identities

People join through IAM membership and get their access on first connection. Changing or removing someone updates their access everywhere at once, with no local accounts to provision or clean up server by server.

Process:

  1. New teammate → invite to Alpacon
  2. Access provisioned on first connection
  3. Permission changes sync automatically
  4. Access revoked immediately on offboarding

Stronger sign-in

Supported MFA methods:

  • Biometric
  • Hardware security key
  • OTP (One-Time Password)
  • Email
  • SMS

Single sign-on (via Auth0):

  • Google Workspace
  • Okta for Enterprise workspaces (Okta Integration Network)
  • SAML IdP for Enterprise workspaces (arranged during onboarding)

Passwordless system accounts

  • System accounts are created without passwords.
  • They are reachable only through Alpacon.
  • Direct SSH key or password use is blocked.

Automation and integrations

People work through sessions; automation uses scoped tokens instead of SSH keys. A token is limited to specific scopes or an allowlist of commands and servers, so a pipeline can only do what it is permitted to. See Tokens.

CLI example

# Login
alpacon login --workspace my-workspace --region us1 -t "alpat-..."
 
# File upload
alpacon cp docker-compose.yml prod-docker:/opt/my-app/
alpacon cp .env prod-docker:/opt/my-app/
 
# Command execution
alpacon websh prod-docker docker compose -p my-app --env-file .env up -d

REST API example

curl -X POST https://your-workspace.us1.alpacon.io/api/events/commands/ \
     -H "Content-Type: application/json" \
     -H "Authorization: token=\"alpat-...\"" \
     -d '{"server": "7a50ea6c-2138-4d3f-9633-e50694c847c4", "line": "docker ps", "username": "docker"}'

What you get:

  • Fine-grained command restrictions
  • Only allowed commands run per token
  • CI misuse prevented

Audit

Every server access and action is tracked on one timeline.

What you get

  • Live activity: watch active sessions in real time
  • Complete recording: every session captured on one timeline (commands, transfers, sudo grants, terminal recordings)
  • AI risk analysis: an automated review of each session after it ends
  • Full visibility: every action attributable to a person or token

What each entry captures

  • Who (user/token)
  • When (timestamp)
  • Where (server/IP)
  • What (command executed/results)
  • Why (session context)

Security principles

Zero trust

  • No implicit trust from network location
  • Every access request verified
  • Least privilege by default
  • Continuous verification

Defense in depth

  • Multiple layers of protection
  • No single point of failure
  • Encrypted connections
  • A complete audit trail

Built for people and agents

  • SSH was designed for humans → Alpacon governs both people and AI agents.
  • Standing keys → just-in-time work sessions and scoped tokens.
  • Scattered logging → one centralized, AI-analyzed audit trail.

Availability

  • Redundant, highly available service
  • Automatic failover
  • Global region support
Last updated: