Concepts

Projects

A project is your day-to-day workspace inside an organization. Every other resource (automations, runs, agents, workers, integrations, secrets, API keys, roles, audit context) lives in exactly one project. The project handle shows up in every URL: /app/projects/{handle}/... and --project {handle} on every CLI command.

Project vs. organization

GoalUse
Separate dev, staging, prod for one teamProjects
Separate two products in one companyProjects
Separate two unrelated companiesOrganizations

Organizations hold billing, membership, and global settings. Projects hold the work. Most teams start with one organization and three projects, one per environment.

What to think about when you set one up

Naming. The handle is URL-stable and immutable. Pick something short and unambiguous: prod, staging, data-platform. Avoid project names that look like resource names ("automations", "runs") and avoid version numbers ("v2"); promote with promotions, not with new projects.

Scope. Resources don't cross project boundaries. That includes agents, integrations, secrets, and API keys. If two automations should share a Slack integration or an agent, they probably belong in the same project.

Access. Project-scoped role assignments are how most teams operate. Org admins can manage everything; project admins manage one project; integration managers manage credentials without seeing the audit log.

Tags

Most resources support a tags map (Map<string, string>). It's the escape hatch for organization: env: prod, owner: platform-team, pii: yes. Tag filters are first-class on most list operations, so investing in tags pays off when you have a few hundred runs to sort through.

Working with projects from the CLI

mobius projects list
 
# Targeting commands at a specific project
mobius --project prod automations list-runs --status running
 
# Or set it once
export MOBIUS_PROJECT=prod

Projects are listed on the org-wide endpoint; the rest of the API is project-scoped.

Tenant isolation

Tenant isolation is enforced in the database: every project-scoped row carries both org_id and project_id (immutable, never empty), and service-layer queries always filter on both. You don't have to think about this, but it's worth knowing it's there.