Skip to main content
A project is a single application. It owns its own providers, routing, environments, and traces — so a project is the unit you point an SDK or the gateway at, and the unit traces and audit events are scoped to. Projects live inside a workspace.

​
Creating a project

Open Settings → Projects and choose New project. A project needs:
  • Workspace — the active workspace it belongs to.
  • Name — its display name (up to 120 characters).
  • Slug — the lowercase, hyphenated identifier used in dashboard URLs (/org/<org>/ws/<workspace>/prj/<project>/…).
A handful of reserved words (such as default, overview, traces, prompts, and settings) can’t be used as a slug, because they collide with dashboard routes. Creating a project requires the project:create permission in the target workspace.
A project’s slug is fixed once it’s created. You can rename a project later, but the slug stays the same so existing links and integrations keep working.

​
Managing a project

Each project row on the Settings → Projects page exposes its actions, gated by project:update (rename, archive) and project:delete (delete).
  • Rename — changes the display name only; the slug is untouched.
  • Archive — hides the project and makes its data inaccessible without deleting it. Archiving is reversible: restore the project to bring it back.
  • Delete — permanent. The dialog summarizes what will be removed (traces, prompts, tools, API keys) and requires you to type the project’s name to confirm.
The default project in the default workspace can’t be archived or deleted — its controls are hidden.

​
Project settings

Configuring what a project does happens elsewhere in the dashboard:
  • Providers and routing live under Deploy.
  • Environments — the production and non-production targets a project deploys to — are managed under the project’s Settings → Environments. See Environments.

​
Next steps

Deploy

Configure providers and routing for a project.

Environments

Separate production from staging.