Manage workspace settings

Workspace settings are only accessible to Staff (RBAC admin) or Superuser (RBAC superuser) members.

Menu access by role

Note: Authentication, Server access, and Privileged access are no longer under Workspace settings—they moved to the top-level Policies menu (see below). Approvals is now a separate page—see Approvals. On self-hosted deployments, Billing, Authentication, and Privileged access aren’t shown. Security groups require the Enterprise plan; each entry under Extensions has its own plan requirement—see Extensions below.

Access settings

Click Workspace settings in the left sidebar. This menu is only visible to Staff or Superuser members.

General

Basic configuration

• Workspace display name: Set the workspace name
• Timezone: Select default timezone
• Language: Set default display language
• Billing email: Email for billing notifications

Advanced settings

Invitation link validity period:

• How long workspace invitation links stay valid
• Up to a maximum of 30 days

Websh session retention time:

• Inactive Websh sessions terminate automatically after this time
• Longer retention may increase costs
• Range: 15 minutes ~ 1 day

Package proxy:

• Specify a proxy server URL for package installations on servers that cannot access the internet directly.
• Leave empty to use direct connections (default).

Allowed domains:

• Users with specific email domains can join without invitation.
• Available on Essential plan or higher

Agent updates

Agent updates decides whether Alpacon upgrades the Alpamon agent on this workspace’s servers automatically, and when. Like the rest of workspace settings, only Staff and Superuser members can change it.

Update policy:

• Latest (recommended, the default): upgrades agents to new releases inside the maintenance window below.
• One release behind: stays one release behind the newest. It’s shown but can’t be selected yet, with the note “Available once verified upgrades are enabled.”
• Manual: no automatic upgrades. Start each upgrade yourself with Upgrade agent in the Agent card of the server’s detail page.

Maintenance window:

Automatic upgrades start only inside this window. It’s hidden under Manual, and has four parts:

• Days: the days the window opens, from Monday to Sunday. Select at least one.
• Start time: the hour the window opens, from 00:00 to 23:00.
• Length: how long the window stays open, from 1 to 24 hours. A window can run past midnight into the next day.
• Timezone: the timezone the days and start time are read in.

A summary under the fields reads the window back, for example “Weekdays, 02:00–06:00 (Asia/Seoul).” Every day with a 24-hour length is the default and reads “Any day, any time.”: upgrades can start at any hour.

Alpacon plans each week’s automatic upgrades on Monday, spreading the workspace’s connected servers across the open hours of the coming week. A change to the window takes effect from the next Monday’s plan, and upgrades already planned for hours that now fall outside the window wait for the next open hour. Switching to Manual stops automatic upgrades that haven’t reached an agent yet.

This window is only for agent upgrades. It’s separate from Alpacon’s own maintenance windows, which pause alerts during platform maintenance.

Recent agent upgrades:

Under the policy, Recent agent upgrades lists the latest agent upgrades across every server you can see, newest first. Filter it by Outcome or by Started by (Automatic or Manual), and select a server name to open that server. Each row reads the same way as a server’s own upgrade history.

Billing

For how plans work in the product—where to manage your plan, what happens at a limit or gate, and how payment works—see Plans & billing. For prices and included limits, see the pricing page.

Overview

The Overview page has these sections:

• Current plan—your plan and renewal date, or the Contract term on a fixed-term contract. Upgrade (on Free) or View plans (on a paid plan) opens the upgrade panel over the page you’re on; nothing opens in a new browser tab. Enterprise isn’t sold from the console, so for that plan the panel points you to support@alpacax.com instead.
• Estimated next charge—the next amount due and the date it’s charged, alongside any Available credit the workspace holds. A prepaid contract shows Next payment as None instead.
• Usage this period—a tile each for active users, active servers, Websh session usage time, and FTP file transfer volume, with a gauge per tile where the plan sets a limit.
• Estimated month-to-date cost—a per-service breakdown (with any overage) and a total.

Billing permission is needed to see any of this; without it the Billing group isn’t shown at all.

Payment

• Payment method—the cards this workspace is charged on. Add a card, remove one, or change which one is the default.
• Billing details—who the invoice is addressed to and the location used to calculate tax. Most workspaces bill directly: name, email, country, and phone (optional), plus a postal code where the country needs one. A workspace billed through a company account is asked for the full address instead (postal code, city, and street address; state and a second address line optional), because that record is printed on the company’s statements.

History

Three tabs:

• Invoices—invoices issued to this workspace, with the issue date, item, invoice number, amount, and status. Selecting a row opens that invoice, and a downloadable document can be pulled straight from the list.
• Payments—every charge against the workspace, with its date, item, amount, and status. A row expands in place for the card it was charged to, the charge breakdown, and a receipt link where the payment provider issued a receipt.
• Credits—each credit’s code, amount, how much is used, what’s left, and when it was redeemed.

Note: Managing billing is a Staff and Superuser capability, so the whole Billing group carries the same access as the rest of the table—no other member sees any of its items. On self-hosted deployments the Billing menu isn’t shown at all.

Access

Roles

Manage roles and their permissions within the workspace. Roles are collections of permissions that can be assigned to users and groups. Only Superuser members can access this setting.

Built-in roles

Built-in roles are automatically assigned to Staff and Superuser members based on their role setting.

Regular users aren’t given a workspace-wide built-in role. Their access comes from group membership and any roles explicitly assigned to them.

Resource-scoped roles

Resource-scoped roles come with Alpacon, like built-in roles, but each one covers a single resource, such as one server or one group, instead of the whole workspace.

Examples include server:maintainer and group:member. Each role’s description in the role list says how it is assigned.

Role list

The role list displays all roles in the workspace, showing each role’s name, description, and created date.

Create a role

1. Click New role
2. Enter the Name and Description for the role
3. Save

The role is created without any permissions. Assign permissions, users, and groups from the role detail page.

Delete a role

1. Navigate to the role detail page
2. Go to the Settings tab
3. Click Delete role
4. Confirm the deletion

Role detail page

The role detail page has four tabs: Permissions, User assignments, Group assignments, and Settings.

Permissions tab

Manage permissions assigned to this role. Each permission follows the resource:action format (e.g., server:read, server:update); the full list is in the scopes reference.

The permissions list shows the permission name, and whether it is scoped to a specific resource type and object.

You can search permissions using the search bar and filter by All or Assigned status.

Assign a permission:

1. Click Assign permission
2. Select a Permission from the dropdown
3. Optionally, check Limit to specific resource to restrict the permission to a specific resource type and object:
   • Select a Resource type from the dropdown
   • Select one or more Object entries from the checkbox list
   • If no objects are available for the selected resource type, the permission applies to all objects of that type
4. Save

Remove a permission:

Select the assignment and click Remove assignment to remove it from this role.

User assignments tab

Manage users assigned to this role. The list shows each user’s name, email, and scope information.

Assign a user:

1. Click Assign user
2. Select a User from the dropdown
3. Optionally, configure the Scope to limit this role to a specific resource
4. Save

Remove a user assignment:

Select the assignment and click Remove assignment to remove it.

Group assignments tab

Manage groups assigned to this role. When a role is assigned to a group, all members of that group inherit the role’s permissions.

Assign a group:

1. Click Assign group
2. Select a Group from the dropdown
3. Optionally, configure the Scope to limit this role to a specific resource
4. Save

Remove a group assignment:

Select the assignment and click Remove assignment to remove it.

Settings tab

Edit the role’s name and description, or delete the role.

• Name: A unique name for this role
• Description: An optional description of the role’s purpose

Click Save to apply changes, or Delete role to permanently remove the role and all its assignments.

Server registration

Create and manage server registration tokens used to onboard servers. Set a token’s Name, optional Expiry, and Allowed groups (which groups the registered servers are assigned to). The token key is shown only once. Superuser only.

Security

Note: Authentication, Server access policies, and Sudo access (labeled Privileged access in the app) moved out of Workspace settings into the top-level Policies menu, visible to Superuser members only; this page keeps documenting them below for reference, and old deep links into this section redirect automatically to the new location.

Authentication

In the app: Policies > Authentication (Superuser only, Alpacon Cloud/Auth0 workspaces).

Configure workspace security policies. MFA authentication is required to change these settings.

MFA enforcement:

• When enabled, all workspace members must complete MFA during login.
• Members without any MFA method configured will be prompted to set one up on their next login.

Allowed MFA methods:

• Select which MFA methods members can use (multiple selection).
• Available methods: TOTP authenticator app, email, phone, and WebAuthn (hardware keys)

MFA timeout:

• Maximum duration that MFA authentication remains valid after completion
• Set for the whole workspace. Members cannot shorten it for themselves.
• Shorter timeouts provide stronger security but require more frequent re-authentication.
• Privilege elevation (sudo) uses a shorter window of its own, so it may ask again while other actions still count as verified.

MFA required actions:

Select which actions require members to re-verify MFA, beyond the login check that MFA enforcement covers. Enforcement is a login policy; this list is what asks for a fresh check at the moment an action is taken.

• Websh, WebFTP: system account access with sudo privilege. Applies when a user connects as a system account (e.g., root) rather than their personal Alpacon account, and the prompt appears before the privileged session starts.
• Command, Editor, Server: the same re-verification on those surfaces.
• Approval: reviewing an approval request. Add it if approvers should re-verify before deciding; enabling MFA enforcement alone does not require it.

Server access policies

In the app: Policies > Server access (Superuser only).

Configure server access and security policies for the workspace. MFA authentication is required to access these settings.

Server defaults

Allow tunnel by default:

• When enabled, tunnel access is allowed by default for newly registered servers.
• Tunnel sessions provide direct network access to the server.

Allow editor by default:

• When enabled, code editor access is allowed by default for newly registered servers.
• Editor sessions provide file editing access on the server.

Tunnel and editor sessions are not recorded in session monitoring. Review these defaults carefully based on your security requirements.

These two defaults have no effect on Windows servers, where tunnel and editor are not available. See Windows servers.

Account defaults

Set home directory access permissions when provisioning IAM user accounts to Linux systems.

• Private: Owner only
• Group shared: Group members
• Public: All users

sudo and root access

Allow direct root access:

• Whether to allow direct connection as the root user via system account selection
• Default: disabled
• When disabled, the root account is excluded from the system accounts list in Websh, WebFTP, and code editor connections.

Use sudo with MFA:

• Enable sudo with MFA to allow Staff and Superuser members to run sudo commands in Websh with MFA verification.
• When enabled, the required PAM module is automatically installed on the servers running Alpamon 1.3.2+ that are connected at that moment.
• Works independently from Allow direct root access—users can use sudo commands even when direct root access is disabled.
• Disabling this setting stops Alpacon from authorizing sudo anywhere in the workspace and turns off Disable sudo outside Websh. It changes nothing on your servers: the PAM module stays installed and simply has no effect. See Disabling sudo with MFA.

sudo with MFA timeout:

• Duration that sudo privilege remains valid after MFA authentication
• After this period expires, the next sudo command requires MFA verification again.

Disable sudo outside Websh:

• When enabled, only allows sudo commands within Alpacon Websh sessions.
• All other server connection methods have sudo disabled.
• This setting is only configurable when Use sudo with MFA is enabled.

Execution control

Execution control is the last card on the page. It sets one workspace-wide posture: whether Alpacon’s judgment of a command gates that command, or is only recorded.

• Enforce (default): judgments gate execution. A command can be held for a Superuser’s approval or blocked outright, and a command judged Critical is always blocked.
• Advisory: judgments are recorded only. Every command runs immediately, nothing is held and nothing is blocked, and the judgment is written afterwards.

Advisory is for a workspace that wants the record without the per-command interruption. It applies to the whole workspace—there is no per-server or per-member exception—and you can switch back to Enforce at any time.

What advisory changes

Advisory does not mean every action succeeds. sudo still needs its authority and a recent verification, so a member who has neither is still refused—just never because of a judgment.

Who can switch it, and how

Only a Superuser can change the mode, and Alpacon asks for a fresh identity verification at the moment of the change—in both directions.

1. Go to Policies > Server access and scroll to the Execution control card.
2. Choose Advisory. A confirmation opens listing what the workspace gives up. Select I understand, then click Switch to advisory.
3. Click Save, and complete MFA verification if you’re asked for it.

Switching back to Enforce takes the same role and the same verification, but no confirmation dialog. Either change is recorded in the activity log with who made it and when.

Switching is not retroactive

A change of mode decides what happens next; it doesn’t reopen what is already waiting.

• Requests already Pending when you switch to advisory stay pending. They are neither approved nor released, and they still need a decision.
• A pending work session that nobody decides cancels itself when its pending window runs out (24 hours by default), and the requester is notified.
• To get moving after the switch, submit the request again rather than waiting on the old one. The new request takes the advisory path.

What members see

• An amber Advisory chip sits beside the workspace name in the top bar, on every page, for every member. Its tooltip says what the posture means, and for Superusers it links to this setting. In Enforce there is no chip.
• A command that ran under advisory carries the Advisory verification status in Commands.
• A sudo action that ran under advisory is recorded in Sudo with the type Advisory (not gated).

Sudo access

In the app, this page is named Privileged access, under Policies (Superuser only, Alpacon Cloud/Auth0 workspaces).

Pre-authorize privileged commands with sudo policies, and audit how access was granted. This setting has two tabs:

• Policies — define which commands (wildcards allowed) are authorized, optionally scoped to specific users and servers, with a valid from/until window and a reason. A policy can be bound to a work session; a session-bound policy can allow MFA bypass so a non-interactive caller runs those commands without an MFA prompt, and is deactivated when the session ends. See Sudo command patterns for how a command is matched against a policy.
• Grants — the authorization history (also shown in Sudo history).

See sudo with MFA. Superuser only.

Integrations

Metric alerts

Metric alerts no longer live in workspace settings. They moved to the Metric alerts screen of the Metrics app. For how to create and edit a rule, and every field a rule can carry, see Monitor server status - Metric alerts.

Webhook

Register webhook URLs to send notification events to external services. Alpacon supports Slack, Discord, Microsoft Teams, Telegram, and custom endpoints.

Create webhook

1. Click New webhook
2. Enter information:
   • Name: Webhook name
   • URL: Webhook endpoint URL
   • Provider: Messaging platform (auto-detected from URL if not set)
   • Verify SSL: SSL certificate validation
   • Enabled: Activation status
3. Save

Supported providers

Provider setup guides

Slack

1. Go to your Slack workspace → Apps → search for “Incoming WebHooks”
2. Add to a channel and copy the webhook URL

Discord

1. Go to Server settings → Integrations → Webhooks
2. Click New webhook, select a channel, and copy the URL

Microsoft Teams

Using Workflows (recommended):

1. Hover over the channel name in the sidebar and click More options (…) → Workflows
2. Search for “Post to a channel when a webhook request is received”
3. Complete the setup and copy the webhook URL

Using Incoming Webhook (legacy):

1. Hover over the channel name in the sidebar and click More options (…) → Manage channel
2. Select Edit, search for Incoming Webhook, and select Add
3. Configure and copy the webhook URL

Telegram

1. Message @BotFather to create a bot and get the token
2. Get your chat ID, then construct: https://api.telegram.org/bot<token>/sendMessage?chat_id=<id>

Custom

Configure any HTTP endpoint that accepts POST requests and enter the URL directly.

Manage webhooks

• Click webhook card for detailed management
• Modify settings or delete

Extensions

Selectively enable Alpacon extensions, each toggled on or off:

• IP — manage IP and DHCP settings (Enterprise)
• DNS — translate domain names to IP addresses (Enterprise)
• Proxy — control and configure proxy servers (Enterprise)
• Private SSL — manage private SSL certificates (Enterprise)
• Package mirrors — distribute and manage package mirrors (Enterprise)
• Power control — monitor and control power settings (Enterprise)
• Metrics — turn on server charts (CPU, memory, disk, disk I/O, network) and metric alert rules (Essentials and Enterprise); see Monitor server status for what it unlocks

Free plans can’t enable any extension.

Related docs

• Delete a workspace
• Invite team members
• Set permissions
• Security settings
• sudo with MFA