Introduction
Welcome to Alpacon: secure, governed server access for people and AI agents alike.
What is Alpacon?
Alpacon is a server access platform that replaces always-on SSH access with access that is requested, approved, time-bound, and recorded. Instead of handing out standing credentials, you ask for exactly the access you need through a work session, use it, and it expires on its own.
People work from a browser terminal; automation and AI agents work from the CLI and API. Both 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 workspace admin 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 -dWhy it’s different
Traditional server access wasn’t built for modern, governed operations:
| Traditional approach | Alpacon approach |
|---|---|
| Manual SSH key distribution | Work sessions and scoped tokens generated and revoked centrally |
| VPN client configuration | No client needed—works anywhere over HTTPS |
| Firewall rules and IP whitelisting | Identity-based access—your IAM identity, not a network location |
| Standing access that never expires | Time-bound sessions that auto-expire when the work is done |
| Scattered audit logs | One timeline per session, recorded and AI-analyzed |
| No story for automation or AI | CLI, API, and MCP govern machine access 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 Servers → Register 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
- How Alpacon works—the conceptual model in 5 minutes
- Installation guide—set up Alpamon on your servers
- Quickstart—get hands-on
- Key concepts—a deeper reference
Questions?
- Check the FAQ for quick answers
- Join our Discord community for real-time help
- Email support at support@alpacax.com
Welcome to governed server access. Let’s get started.