Understanding Workspaces

Workspaces are the top-level organizational unit in Devpilot. Every resource you create — servers, projects, apps, deployments, integrations — belongs to a workspace. Think of a workspace as a self-contained environment where your team collaborates on shared infrastructure.

Whether you are managing a single side project or running multiple production environments for different clients, workspaces give you the boundaries and structure to keep everything organized.

How Workspaces Organize Your Infrastructure

A workspace acts as the root container for all of your Devpilot resources. The hierarchy looks like this:

• Workspace — the top-level boundary
  • Projects — logical groupings of related apps
    • Apps — individual applications you deploy and manage
  • Servers — the compute infrastructure your apps run on
  • Deployments — records of every deployment across your apps
  • Integrations — third-party service connections (Git providers, cloud accounts, notification channels)
  • Team Members — the people who have access to this workspace
  • Billing — subscription, usage, and payment details scoped to this workspace

Each workspace maintains its own team roster, permission model, billing account, and activity history. Resources in one workspace are completely isolated from resources in another — a team member in Workspace A cannot see or interact with anything in Workspace B unless they are also a member of that workspace.

What Each Workspace Contains

Every workspace includes the following components:

• Owner — the user who created the workspace. Each workspace has exactly one Owner with full control over all resources and settings.
• Members — other users who have been invited to collaborate. Each member is assigned one of the workspace roles (Admin or Member), plus optional resource-level access on specific servers, projects, or apps.
• Projects — containers for grouping related apps together.
• Apps — the applications you build, deploy, and monitor.
• Servers — the infrastructure that hosts your apps, including cloud instances and connected servers.
• Integrations — connections to external services such as GitHub, GitLab, AWS, DigitalOcean, and notification tools.
• Billing — workspace-level subscription plans, usage tracking, and payment methods.
• Settings — workspace name, logo, general configuration, access tokens, API keys, and workspace-level preferences.

Navigating to Workspaces

You can access your workspaces by navigating to /dashboard/workspaces in Devpilot. This page lists every workspace you own or have been invited to. From here, you can select a workspace to enter, or create a new one.

Once inside a workspace, you have access to the following sub-pages:

The Workspace Dashboard

When you first enter a workspace, you land on the Overview page — your workspace dashboard. This page provides a high-level summary of what is happening across your infrastructure.

The dashboard displays key statistics at the top, including totals for apps, deployments, and monthly spend for the current billing period, plus a count of the workspaces you belong to.

Activity Log Sidebar

On the right side of the dashboard, an Activity Log sidebar displays recent events in your workspace. This includes actions such as:

• New deployments triggered
• Team members added or removed
• Server connections established or lost
• App configuration changes
• Integration updates

Each entry shows the action performed, the user who performed it, and a timestamp. The activity log gives you a quick pulse on workspace operations without needing to navigate to the full Activity page.

When to Use Multiple Workspaces

Creating multiple workspaces is useful when you need clear separation between different environments, teams, or clients. Common patterns include:

• By environment — separate workspaces for development, staging, and production.
• By client or project — agencies and consultancies often create one workspace per client to isolate resources and billing.
• By team — large organizations may create workspaces per department (e.g., frontend team, backend team, data team).
• Personal vs. professional — keep side projects in their own workspace, away from company infrastructure.

Each workspace has its own billing, so costs stay clearly attributed to the right context.

Next Steps

Now that you understand what workspaces are and how they structure your Devpilot experience, explore the following guides to get started: