Set up your workspace

This guide is for the person who creates 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: Create the workspace

A workspace is an independent space for managing servers and team members, with its own URL, members, and billing. When you create one, you choose a region (United States us1 or Asia Pacific ap1) that determines where your workspace data is hosted. The region cannot be changed after creation, so pick the one closest to your team and servers up front. The person who creates the workspace automatically becomes a Superuser with full control, which matters for the approval and security steps below.

See Create a workspace for the full form, the region coverage table, and how plan limits affect how many workspaces you can create.

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. Only Superusers can review and approve access requests (Step 5), 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 Superusers.

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 a Superuser approves or rejects it. Each request carries a risk rating, and work sessions include an AI pre-review to help you decide quickly. Reviewing the queue requires the Superuser role, 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 always needs human approval. To tune the middle ground, configure approval policies that decide, based on a request’s risk and who is asking, which actions clear automatically and which wait for review, 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 (authenticator app, email, phone, or hardware keys) 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 Plan & billing > Usage 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 created 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.
Approval policies 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.