Projects & Workspaces
Workspaces own tenancy and billing. Projects are the unit of monitoring and telemetry. Every monitor, key, and ingest path resolves to a workspace — and almost always a project.
What they are#
- Workspace — tenancy boundary for members, plan entitlements, and shared settings. Types:
personal(one per user, auto-provisioned) andteam(multi-member). - Project — monitoring and telemetry boundary inside a workspace (slug unique per workspace). Monitors, browser apps, log sources, and trace sources attach here.
Why the split exists#
Billing and identity live at the workspace. Reliability surfaces (HTTP checks, RUM, logs, traces, incidents) need a project so teams can separate products or services without sharing ingest keys. Server code scopes queries by workspace_id (and project when applicable) — never by bare resource IDs alone.
How workspaces work#
- On signup, Mydle ensures a personal workspace for the user.
- Free and Pro allow 1 workspace per owner. Plans and limits belong to the workspace, not to individual members.
- Member invites, RBAC, audit log, SSO and SCIM aren’t part of the Free or Pro package. Existing Team and Enterprise contracts keep them.
- Switch context from the app shell; the active workspace drives which projects and settings you see.
How projects work#
- Create a project in /app (name + slug within the workspace).
- Project lifecycle includes
active,paused, andarchived— archive is soft removal, not a health claim. - Issue project-scoped credentials for browser (
pk_…) and server ingest (sk_…/ source tokens). - Attach monitors and telemetry sources; health and explorers stay empty until observations arrive.
Roles & permissions#
Workspace roles are owner, admin, and member. There is no viewer role in the schema. Examples of enforcement:
- Members can view the workspace and manage projects (create / configure)
- Admins invite and manage non-owner members
- Owners manage billing, rename, transfer ownership, delete team workspaces
Member invites need the members entitlement, which Free and Pro don’t include — those workspaces are owner-only.
Config in product#
- Workspace settings and billing — owner surfaces in Settings
- Project general settings — name, slug, platform metadata
- API keys — Settings → API Keys (browser publishable vs server secret)
- REST automation —
api_access, not part of Free or Pro; see API Reference
Limits#
- Free: 1 workspace · 3 projects · 3 active HTTP monitors across those projects · $0
- Pro: 1 workspace · no fixed project count · 10 active HTTP monitors · $19 / workspace / month
- Extra projects never add monitor capacity; Pro add-ons do.
See Limits & Quotas.
Failures
- Creating a fourth project on Free fails the projects cap — upgrade or archive unused projects.
- Invite / RBAC UI stays gated on Free and Pro.
- Soft-deleted workspaces and archived projects hide from normal lists; they do not invent historical uptime.
- Cross-workspace IDOR is rejected — credentials and sessions only authorize their tenant.