Workspaces and projects

Use a workspace for one separately billed customer or product owner. Only create another workspace when it should have its own subscription, members, provider applications, and billing lifecycle.

Every workspace is billed independently. Switching workspaces changes the WorkOS organization session and reloads the control-plane context; it does not reuse another workspace’s subscription.

Projects live inside a workspace. Each project isolates API keys, provider accounts, webhooks, usage, MCP policy, and audit context. A project is explicitly created as either test or production.

Use a test project for provider authorization, webhook verification, MCP client setup, and connection-page review. Test and production projects have different credential prefixes and cannot infer each other’s resources.

• A project ID from another workspace is rejected instead of becoming active.
• A role without project-management permission can view projects but cannot create one.
• Deleting the only owner’s account is blocked until ownership is transferred or the workspace is deleted.

Create one test project, select it in the console header, and finish the launch checklist before creating the matching production project.