AlpacaX

Features

Everything Alpacon does

Every capability below sits behind one gate—identity in, judgment on every command, a record out. For your team, your pipelines, and your AI agents.

Identity in. Record out.

Sign up or log in
Register your servers
Register your team and agents
Access your servers
Judge each command
Review the session record

Sign up, register your servers, your team and its agents—then every session runs the same way: access, a judgment on each command, and a searchable record at the end.

Access

One identity opens every door you're allowed.

Zero open ports.
Nothing listening.

Outbound-only tunnels—no inbound port, no VPN, nothing on the host listening. Log in and click your server.

See how it works

Just log in like a website.

Sign in with your password, verify with MFA, and reach every server you're authorized for—no SSH keys, no per-server credentials. Admins choose which actions demand a fresh factor.

SAML SSOPasskeyOTPBiometricsHardware keyRecovery codes
Learn more

Add people by role, not by server account.

Workspace and group roles decide who reaches what—nobody holds more than their role grants, and you can author custom roles.

Learn more

Every team in its own walls.

Each team or customer gets its own servers, members, policies, billing, and audit trail.

Point it at your AWS account.

Connect an account, auto-discover EC2 instances, and roll the agent out from the console—filtered by region, state and tier.

Interfaces

One policy, every interface.

A real terminal,
one click away.

A full terminal in the browser, nothing to install—shell configs sync to every server, and a code editor rides the same governed channel.

Sudo MFA Elevate privileges with MFA—no shared root passwords, and every grant lands on the session timeline.

prod-server

Session duration 00:12:47

Welcome to Alpacon! This session is recorded.

demo@prod-server:~$ id

uid=2000(demo) gid=2000(alpacon) groups=2000(alpacon),27(sudo)

demo@prod-server:~$ tail -n2 /var/log/payments/app.log

02:04:19 INFO settlement batch queued

02:04:21 INFO 412 rows reconciled

demo@prod-server:~$

Files, dragged and dropped onto production.

Drag and drop files onto remote servers in the browser—every transfer tracked.

Reach internal ports without exposing them.

Databases and internal APIs, reached through an encrypted tunnel instead of an exposed port.

Your terminal, governed: Alpacon CLI.

The full web experience from your terminal—shell, transfers, batch commands, same policy.

Learn more

Let AI operate your servers—
every command judged.Beta

Claude Code, Claude Desktop, Codex, Cursor and VS Code connect in one click to the hosted MCP server—or run it locally—under the same ACL rules as any user.

Drop it into the pipeline you already have.

A service token and our Docker image are the whole integration—what the token may run is set under execution control.

Learn more

Execution control

The command is the perimeter.

Held commands go to a human.

A privileged command without the privilege routes to a manager—logged with its full context, under approval policies you author.

Learn more
alpacon.io/demo/approvals

Command approval

Awaiting approval

sudo docker exec payments-wsgi-1 python manage.py dumpdata clients.ApiClient

svc-incident-bot2 minutes agoAI agent
Medium risk

Work session

Seed the staging billing ACL

Command

sudo docker exec payments-wsgi-1 python manage.py dumpdata clients.ApiClient

Why this is held

AI review held it: dumping API client credentials (client_id, secret) does not serve the session's stated goal of seeding ACL rows. No policy auto-releases an AI hold—only a person can.

Risk factors

  • Command does not plausibly serve the work_session description
  • Running as root

Target server

staging-docker-1

A simulation of Alpacon's approval queue—the hold reasons and every risk-factor line are the product's own. Risk is a band, never a score. At critical risk the lane is deny—no approver can release it.

Nobody has to maintain the allowlist.

Write what the session is for, and Alpacon proposes the scopes it needs with the risk they carry. Proposals are capped by what you may hold and still go through approval—a starting point, not a grant.

Your CI token stops being a blank check.

The pipeline is its own identity, and its credential runs only a deny-by-default allowlist—narrowed by IP, hours and weekday, rotated on policy. Commands, servers and file paths each have their own ACL, capped by the parent application's roles—and every command lands in the record under the application's name.

Learn more

The approval reaches you, wherever you are.

The hold pages its approvers on Slack, email or push—with the command and its risk band attached.

Real-time alerts. Delivered anywhere.

Formats natively for Slack, Discord, Microsoft Teams and Telegram—or JSON to any endpoint you point at.

Grant access. Set limits. Revoke instantly.

Invite a member by email or hand out a password-protected link, 5 to 180 minutes—read-only or full control, flippable mid-session, revocable instantly.

Know what is running now, not afterwards.

Every active session sits on one screen, risk-banded as it runs—watch a live terminal or terminate it on the spot. Only a policy hold interrupts you.

Audit

Everything that ran, answerable.

Every session. Recorded. Searchable.

Terminal sessions replay keystroke for keystroke; commands and transfers are searchable records—secrets masked as the record is written.

alpacon.io/demo/sessions
  • prod-serverEunyoung Jeong12m 47s
  • prod-web-01Minsu Park3m 02s
  • prod-db-masterpacabot (agent)41s
  • staging-webEunyoung Jeong5h 12m

Every session, read back by AI.Enterprise

Risk-scored sessions mapped to MITRE ATT&CK—each technique links straight to the catalogue, and the whole workspace rolls up into a clickable attack-pattern heatmap.

Ask the session what happened.

Ask a recorded session in plain language—answers come from its own record, linked to the sessions they cite.

Answer “why can they do that?” without reading the role tree.

Pick a person and a permission; get the verdict with the binding, the pattern, and the group walk that produced it.

The logins that bypassed Alpacon.

SSH, su and sudo straight to the host are captured too—the audit covers the paths you didn't route through us.

Frequently asked

Technical and operational questions

How does reverse connection work?

Instead of exposing an SSH port, the Alpacon agent installed on a server initiates an outbound HTTPS connection to the Alpacon platform. As a result, no inbound firewall rules are needed, the agent works behind NAT, and servers are never directly exposed to the internet. All user sessions travel through this encrypted outbound tunnel.

What ports does Alpacon use?

Alpacon only requires outbound HTTPS (port 443). No inbound ports need to be opened, which significantly reduces the attack surface.

Does Alpacon require root/admin access?

The Alpacon agent (Alpamon) requires root/admin privileges to manage user sessions, enforce access controls, collect audit logs, and execute commands as other users. End users do not need root access unless explicitly granted by policy.

How do I install the Alpacon agent?

Go to Servers → Register Server, enter your server information, copy the generated installation script, and run it on your server. The script auto-detects the OS and installs the appropriate agent.

Can I use Alpacon for file transfer?

Yes. Alpacon includes WebFTP, a browser-based file manager that supports upload/download, drag-and-drop, server-to-server transfers, and CLI usage for automation.

Can I register a server in multiple workspaces simultaneously?

No. A server can only be registered to one workspace at a time. To move it to a different workspace, first disconnect it from the current workspace, then re-register it in the new one.

How do I handle emergency access?

Emergency access runs through break-glass service tokens: a superuser issues one with a recorded justification, every action under it is logged, and it carries the same command and server ACLs as any other service token. API tokens remain available for programmatic access.

What happens if Alpacon goes down?

Your servers keep running—the agent connects outbound and reconnects on its own. Terminal sessions that are already open typically stay connected, while anything that needs a decision from Alpacon—a new session, an API-submitted command, a sudo grant or approval—waits for recovery. You are never locked out of your own machines: direct SSH or your cloud provider's console, if you kept them, keep working. Live status is published at status.alpacax.com.

How are software updates handled?

The Alpacon platform updates automatically via rolling deployments with no downtime. Agents support automatic updates (recommended) or manual updates via a package manager; neither method interrupts active sessions.

Can I self-host Alpacon?

Yes. Alpacon Enterprise supports self-hosted deployment for organizations with air-gapped environments, data sovereignty requirements, or custom integration needs. Contact sales@alpacax.com for details.

Does Alpacon work with CI/CD pipelines?

Yes. Official GitHub Actions are available for CLI setup, running commands, file transfer, and remote shell. Any other CI—GitLab CI, Jenkins, CircleCI, and the rest—can drive the same REST API and CLI with scoped service tokens.

Can I use Alpacon with configuration management tools?

Yes. Integrate configuration management tools with Alpacon via the REST API to run commands within automated workflows.

Every command, judged before it runs.

Features | Alpacon