Introduction

Welcome to Alpacon: execution governance for people, pipelines, and AI agents.

What is Alpacon?

Alpacon governs execution: what people, pipelines, and AI agents are allowed to do on your servers, and when. Instead of handing out standing SSH access, work moves through time-bound work sessions. You declare what you need, approval happens where it matters, risk is assessed live, and everything lands in a recorded, AI-analyzed audit trail.

People work from a browser terminal, automation runs from the CLI and API, and AI agents connect through the MCP server. All go through the same model, so every action is governed and auditable, whether a human or a machine took it.

New here? How Alpacon works is the 5-minute conceptual tour.

How access works

Server access flows through three stages, which also match the product sidebar:

  • ACCESS—you request a work session for specific servers, tools, and a time window.
  • EXECUTION—a user with the Superuser role approves it (and can watch active sessions live).
  • AUDIT—everything is recorded on one timeline, and Alpacon adds an AI risk analysis after the session ends.

You connect as yourself (your Alpacon identity is your account on the server), and MFA is asked for at the moments that matter, not on every command. See How Alpacon works for the full picture.

For people and for automation

The same governed model serves two kinds of users.

🧑‍💻 People

  • Browser-based terminal: full terminal access (Websh) from any browser, supporting vim, colors, and special keys.
  • Multi-factor authentication: strong verification at decision points.
  • Session sharing: collaborate in real time for debugging or pair programming.
  • Visual file transfer: drag-and-drop with WebFTP.
  • Zero client setup: no SSH client, no VPN, works instantly.
# Open a terminal in your browser for an approved session
alpacon websh production

🤖 Automation and AI agents

  • CLI and API: request and use sessions programmatically.
  • CI/CD native: one-line integration with any pipeline.
  • AI agents: connect through the Alpacon MCP server with scoped, audited access.
  • Bulk operations: run a command across many servers from a session.
  • Service and access tokens: scoped, revocable credentials for automation.
# GitHub Actions
- name: Deploy to production
  uses: alpacax/alpacon-websh-action@v1
  with:
    workspace-url: ${{ secrets.ALPACON_WORKSPACE_URL }}
    api-token: ${{ secrets.ALPACON_API_TOKEN }}
    target: production
    script: |
      docker pull myapp:latest
      docker compose up -d

If you’re coming from SSH

SSH was built to give a person a shell, not to govern what people, pipelines, and agents do at scale. Here is how the same jobs look in Alpacon:

With SSHWith Alpacon
Manual key distributionWork sessions and scoped tokens generated and revoked centrally
VPN, firewall rules, IP allowlistsIdentity-based access over HTTPS, no client and no network plumbing
Standing access that never expiresTime-bound sessions that auto-expire when the work is done
Scattered logs, no story for automationOne AI-analyzed timeline per session; CLI, API, and MCP govern machines the same way

Who uses Alpacon

👩‍💻 Software engineers

  • Debug production with a full browser terminal, no SSH keys or VPN.
  • Share a live session with teammates for collaborative troubleshooting.
  • Move files with drag-and-drop.

🔧 DevOps engineers

  • Integrate access into CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins).
  • Run commands across many servers from a single session.
  • Automate deployments and scheduled maintenance.

🛡️ Security teams

  • Every session is requested, approved, time-bound, and recorded.
  • No standing credentials or exposed SSH ports.
  • A complete, AI-analyzed audit trail for compliance.

💼 IT managers

  • Onboard engineers in minutes through IAM membership.
  • Manage access for all servers in one place.
  • Meet compliance requirements with built-in audit.

Architecture overview

Alpacon uses a reverse-connection architecture: your servers connect out to Alpacon, never the other way around.

Because servers only make outbound connections, there are no exposed SSH ports, no inbound firewall changes, and it works behind NAT.

Getting started in 3 steps

Step 1: Register a server

In your Alpacon workspace, go to ServersRegister Server, enter the details, and run the generated installation script on your server. See the Quickstart guide.

Step 2: Request a work session

From the server, click Connect to request a session with the tools and time window you need. Once it’s approved, your tools open in the browser. See Request a session.

Step 3: Work

Open a terminal, transfer files, or run commands. For automation, create and use sessions from the Alpacon CLI, or issue a token for CI/CD.

That’s it. No SSH keys to generate, no VPN to configure, and nothing left behind when the session ends.

Next steps

Questions?

Welcome to governed server access. Let’s get started.

Last updated: