System and Workspace Settings

Devpilot separates configuration into two layers:

• System settings are global to the Devpilot instance and govern which cloud providers are available when any workspace provisions infrastructure.
• Workspace settings are scoped to a single workspace and hold operational preferences for that workspace alone.

This page covers both layers, who can change each one, and how to use them safely.

System Settings: Cloud Provider Availability

System settings control which cloud providers are enabled for server provisioning. This list is shared across every workspace on the instance.

Supported Providers

Devpilot ships with support for the following providers:

Each provider carries an Active or Inactive status. When a provider is Active, workspaces can use it to provision servers; when Inactive, it is hidden from the provisioning flows and cannot be selected in any workspace.

Viewing Providers

Open System Settings > Cloud Providers to see every provider and its current status. The list is fetched directly from the database, so it always reflects the most recent toggle.

Toggling a Provider

When to Deactivate a Provider

• Decommissioning a cloud — you no longer want new servers to land on that provider.
• Compliance scoping — a region-specific regulation requires the team to provision only on a whitelist.
• Cost control — pausing a more expensive provider while the team standardises on a cheaper one.
• Outage response — a provider is unavailable and you want to stop users from trying to provision there until it recovers.

In every case, deactivating stops new provisioning but leaves existing servers and their billing records intact.

Workspace Settings

Each workspace has its own settings object, editable by workspace Owners and Admins. Workspace settings are stored as a JSON document, giving each workspace a flexible place to hold its own preferences without touching other workspaces.

Who Can View and Change Workspace Settings

Members do not see the Settings page.

Viewing Workspace Settings

Updating Workspace Settings

What Belongs in Workspace Settings

Use workspace settings for preferences that affect how the whole workspace behaves and that should survive across user sessions. Typical examples include:

• Default preferences that the workspace wants pre-filled when a Member creates a new resource.
• Feature-flag-style toggles shared by the workspace.
• Operational preferences that are not big enough to warrant their own full feature page.

For anything with stricter security or auditing requirements, use the dedicated pages:

• Access tokens and API keys for programmatic credentials.
• Roles and permissions for member and resource-level access.
• Invitations for adding members.
• Quotas and usage alerts for quota thresholds and delivery channels.

Tips for Safe Edits

• Review the current object before you save. The update replaces the existing settings object in one shot, so anything you omit is lost.
• Coordinate with other admins. Because workspace settings are shared, another Owner or Admin may be relying on the value you are about to change.
• Keep secrets out of workspace settings. Store API keys and tokens in their dedicated features, which encrypt and scope them correctly.

Who Can Change What — Summary

Members cannot view or change system-level cloud provider toggles, and they cannot view or change workspace settings.

Related Audit and Analytics

• Access-related changes a workspace admin makes (role grants, role changes, approvals) are captured in the access audit trail, not here.
• Activity volume that flows through a workspace (deployments, edits, and so on) is summarised on the team analytics page.

Changes to system-level provider availability and workspace settings themselves are applied immediately and reflected in the workspace's own configuration on the very next page load.

Next steps