Accounts, workspaces, and projects

MaxoPerf groups everything you do into a small, predictable hierarchy. Understanding the four layers makes access, billing, and day-to-day navigation obvious.

The four layers

• Account — the billing and ownership boundary. One account holds your plan, payment method, invoices, and overall usage. Most companies have one account per organization.
• Workspace — a team boundary inside an account. Workspaces separate independent teams or environments (for example Web team and Mobile team, or Production and Internal staging). Each workspace has its own members and projects.
• Project — the unit of work inside a workspace. Projects collect related tests, schedules, secrets, and data entities. A project usually maps to one application, service, or surface under test.
• Test — a single load or performance test definition. A test lives inside one project and produces runs each time it executes. See Tests and runs for the run lifecycle.

Each workspace is a team boundary — Web team and Mobile team can sit side by side under the same account.

A project is the unit of work inside a workspace — it owns the tests, schedules, secrets, and data entities for one application or surface.

Who can do what

Each layer has its own permissions, and most roles are inherited downward. For example, a workspace editor can edit every project and test inside that workspace unless a narrower role overrides it.

Layer	Common roles	What that role can do
Account	Owner, billing admin	Change plan, manage payment method, see all workspaces.
Workspace	Admin, editor, viewer	Add or remove members, create projects, configure tests.
Project	Editor, viewer	Edit tests, manage project secrets, view runs.
Test	Runner, viewer	Start runs, view run results.

You can see and adjust roles from the Members screen of the corresponding workspace or project.

The Members directory is where you review and adjust who holds which role, at the workspace or project layer.

Choosing the right shape

Most teams start with one account + one workspace + one project per app. Split into more workspaces only when the audience for the data changes — for example, when a different team wants its own member list, dashboards, or secrets.

When in doubt:

• Same team, different services → one workspace, multiple projects.
• Different teams that should not see each other’s runs → separate workspaces.
• Different companies or different billing → separate accounts.

Where to go next

• Tests and runs — what a test is, what a run is, and the lifecycle a run moves through.
• Manage test secrets — store credentials at the project layer and bind them per test.
• Billing and plans — how usage rolls up to the account.