Set up your workspace

This guide is for the person who sets up the workspace and wires up the team: the workspace administrator. Instead of assembling the picture from seven separate pages, follow these steps in order to go from an empty workspace to a team that can request access to the right servers, under the guardrails you set.

Each step links to a detailed page for the full options and screenshots. Work through them once, top to bottom, and your workspace is ready for the team. If you just want to try Alpacon on a single server first, start with the quickstart and come back here when you’re ready to bring in the team.

The mental model: a workspace holds your people and your servers. A user group is the join between them: group membership decides who can request which servers. So the setup builds outward from the workspace: invite the people, register the servers, then create the groups that connect the two, and finally set the governance and security policies that apply across everything.

Step 1: Set up the workspace

A workspace is an independent space for managing servers and team members, with its own URL, members, and billing. You set it up with the AlpacaX team when you book a demo. Together you agree on the workspace name, its URL, and a region (United States us1 or Asia Pacific ap1) that determines where your workspace data is hosted. The region cannot be changed after the workspace is set up, so pick the one closest to your team and servers. The person we set the workspace up for becomes a Superuser with full control, which matters for the approval and security steps below.

See Get a workspace for what is decided at the demo, the region coverage table, and how plan limits affect how many workspaces you can have.

Step 2: Invite your team

Invite the people who will use Alpacon by email from IAM > Users. Each member joins with one of three workspace roles, and choosing them deliberately is the most important governance decision you make here:

  • Member — everyday users. They can only reach servers granted to them through group membership (Step 4).
  • Staff — administrative helpers. They can manage users and groups and some workspace settings, but they cannot review approvals.
  • Superuser — full workspace control. Superusers approve access requests by default (Step 5), unless an access rule names other approvers, so you need at least one besides yourself, but keep the count small since the role is unrestricted.

Invitations are valid for 48 hours by default (adjustable up to 30 days). You don’t have to sort everyone into groups yet, that comes in Step 4 once your servers are in.

See Invite team members for email invitations, domain-based auto-join, resending, and per-plan member limits.

Step 3: Register your servers

Bring your servers under management by installing the Alpamon agent on each one. The recommended path is Registration with token: you generate a registration token, copy the install command, and run it on the target server. The same token can register one server or a whole fleet, and Ansible is available for bulk and configuration-management workflows. A registered server appears in the list as Online once the agent connects, over an outbound HTTPS connection only, with no inbound ports to open.

Register servers before building groups because in the next step you assign these servers to groups, so they need to exist first. If you already know your group structure, you can create the groups first (Step 4) and register straight into them by giving the registration token the right Allowed groups, so each server lands with access already wired.

See Register a server for the token, Ansible, and cloud methods, the supported-platform matrix, and troubleshooting.

Step 4: Create user groups and assign servers

This is where access takes shape. A user group connects people to servers: you assign servers to a group, add members to that group, and every member can then request the group’s servers. Design groups around how your team actually works, by environment (production, staging), by project, or by team (backend, devops), and keep production groups tight.

Assigning is two-directional. Create and populate groups from IAM > Groups, and assign groups to a server either during registration (through the token’s allowed groups) or afterward by editing the server’s Authorized groups. A server with no groups assigned is reachable only by Superuser and Staff members, its owner, or a role scoped specifically to it.

Watch the default group. Every workspace member automatically belongs to the built-in alpacon group. Assigning the alpacon group to a server therefore opens that server to everyone in the workspace. Use it deliberately for broadly shared servers, and leave it off when access should stay limited to specific groups.

See Manage groups for creating groups and assigning users, and Control server access for assigning groups to servers.

Step 5: Configure approval policies

By default, access isn’t automatic: when a member requests a work session on a server, the request enters the Approvals queue, and an approver approves or rejects it: a Superuser, unless an access rule names other approvers. Each request carries a risk rating, and work sessions include an AI pre-review to help you decide quickly. By default the queue is reviewed by Superusers, which is why Step 2 asked you to plan those roles carefully.

Some requests clear without a manual decision: a Superuser’s own session request is approved immediately, while a session requested by an AI agent needs human approval by default. To tune the middle ground, set access rules under Policies > Access rules that decide, based on a request’s risk and who is asking, which actions are allowed, which wait for an approver, and which are blocked, so routine low-risk work isn’t blocked while sensitive requests still get a human.

See Approvals for the queue, request types, automatic-approval rules, and how reviewing works.

Step 6: Configure security settings

Tighten the workspace’s security posture from the top-level Policies menu (Superuser only). Two settings matter most for a new workspace:

  • Allow direct root access — whether a user can connect directly as root through system-account selection. It is off by default, and while it’s off, root is excluded from the account list. Leave it off and use sudo with MFA for privileged actions unless you have a specific reason to enable it.
  • MFA enforcement — when enabled, every member must complete multi-factor authentication at login, and anyone without an MFA method is prompted to set one up. You also choose which methods are allowed (hardware security key, biometric authentication, one-time password, email, or recovery code), which also decides whether a passkey sign-in counts as MFA (details), and how long an MFA session stays valid.

These policies also cover server-access defaults (tunnel and editor allowances for new servers) and sudo behavior. Review them against your team’s requirements before opening the workspace up.

See Manage workspace settings for every setting, including authentication, server-access policies, roles, and integrations.

Step 7: Understand your plan limits

Finally, know where your plan’s edges are so a limit doesn’t surprise you mid-onboarding. Alpacon offers a Free plan and paid plans (Essentials and Enterprise) that raise limits such as members and registered servers and unlock features like activity-log retention, notifications, and SSO. When you hit a limit or open a feature your plan doesn’t include, Alpacon shows an upgrade dialog and doesn’t complete the action until the plan is upgraded.

Track your consumption on the Billing > Overview page (visible to Staff and Superusers), which shows your current plan, usage this period, and an estimated cost. Only Staff and Superusers can change the plan; other members are asked to contact an admin.

See Plans & billing for what happens at each limit and gate, and the pricing page for exact numbers.

What your team members see

Your members don’t repeat this setup, they follow a much shorter path. After you invite them, their journey is essentially the quickstart: sign in, and connect to a server. Because you’ve already wired up group access, they’ll see the servers their groups can reach and click Connect to request a work session, which arrives in your Approvals queue.

Point new members to Connect to servers for how session-based access works and which account they can connect as.

Setup checklist

Use this to confirm the workspace is ready for the team:

  • Workspace set up with the AlpacaX team in the right region, with at least one additional Superuser planned.
  • Team invited from IAM > Users, with roles chosen deliberately (Superusers kept few).
  • Servers registered and showing Online in the server list.
  • Groups created and servers assigned, with the alpacon group used only where broad access is intended.
  • Access rules configured so routine requests clear and sensitive ones get review.
  • Security settings reviewed: direct root access, MFA enforcement, and server-access defaults.
  • Plan limits understood, with billing access confirmed for the right people.
Last updated: