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
| Goal | Use |
|---|---|
Separate dev, staging, prod for one team | Projects |
| Separate two products in one company | Projects |
| Separate two unrelated companies | Organizations |
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=prodProjects 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.
Related
- API keys and roles for access control inside a project.
- Audit logs for who-did-what.