Projects

Learn how projects anchor Studio work, runtimes, and grouped execution records inside a workspace.

Projects are the named work contexts inside a workspace. They anchor the hosted Studio route, group interactive runtime state and execution records, and give app, CLI, TUI, and API workflows a stable project key to target without becoming the permission or billing boundary.

Access, billing, and membership still come from the surrounding workspace and organization. If you only need the hierarchy and boundary model, start with the Manage overview. This page is the project deep dive.

What a project is

A project lives inside a workspace and represents a focused piece of work — a red team engagement, a pentesting target, an evaluation suite, or an experiment.

Projects provide:

A stable Studio route — project keys appear in URLs such as /{org}/studio/{workspace}/{project}
Grouping — a common bucket for attached runtimes, sessions, sandboxes, evaluations, AIRT assessments, and traces related to that work
A default context — when a create flow omits project_id, Dreadnode resolves the workspace’s default project
Runtime association — a project can group zero or more durable runtimes for interactive work

Projects do not replace the real boundaries around that work. Workspaces still control access, storage, and collaboration. Organizations still control membership and billing.

Project keys

Every project has a key — a URL-safe slug that uniquely identifies it within its workspace. Keys appear in URLs, CLI output, and Studio route resolution.

Unlike some older docs implied, project keys are not strictly immutable. Non-default projects can be renamed as long as the new key stays unique within the workspace. That changes the Studio URL, so bookmarks and saved links should be updated when you rename a project.

Hosted project surface

In the hosted app, the concrete project surface is the Studio route:

/{org}/studio/{workspace}/{project}

That route is the interactive shell for the current project.

The base Studio view keeps chat and the composer in project context. From there, the current layout opens three pinned project panels:

Files — browse files produced or persisted through the current runtime/sandbox workflow
Summary — review recent runs, model and tool usage, token totals, and estimated cost for the current project
Runtime — inspect the interactive runtime and sandbox state behind the project

Other routed surfaces such as traces, evaluations, optimization, or studies are adjacent workflow views. They use the same project context, but they are not the fixed pill tabs in the current Studio layout.

Default project resolution

Every workspace has a default project. This prevents new runtimes, sessions, evaluations, or world jobs from becoming ungrouped when the client does not specify a project_id.

That default is used in two common places:

backend create flows that omit project_id
frontend Studio redirects when there is no explicit project URL yet and the app needs a safe fallback

If you open Studio at the organization or workspace level, the frontend resolves the target project for you. In the current app, that means “most recently updated project in the chosen workspace,” with a fallback to the default project key when no explicit project can be resolved.

Projects and runtimes

Interactive compute is still modeled through explicit runtime and sandbox objects, but projects no longer own a single durable runtime slot.

Creating a project does not create a runtime record automatically. Instead, runtimes are created as independent workspace resources and may optionally be attached to a project for grouping. Capability bindings, current sandbox state, and session continuity live on the runtime, not directly on the project row.

Runtime metadata is also independent. Renaming a project does not rewrite the runtime’s key, name, or description.

That is why project docs and runtime docs have to be read together:

the project is the user-facing context and grouping shell
the runtime is the durable interactive control point
the sandbox is the provider-backed compute instance

Traces and telemetry

Traces, sessions, evaluations, and analytics remain workspace-scoped records that use project_id as a grouping and filtering dimension. Use workspace-scoped trace and evaluation routes, then pass project_id when you want a project-specific view.

Projects therefore shape the working set you see in the app, but they are not a separate read permission boundary for telemetry APIs.

Managing projects

Projects are managed through workspace-scoped app and API flows, then reused throughout CLI, TUI, SDK, and hosted workflows.

Important lifecycle rules:

creating or updating a project requires workspace contributor access or higher
deleting a project requires workspace owner access
the default project cannot be renamed, modified, or deleted
deleting a project first stops any running or paused project sandboxes, then cascades through sessions, sandboxes, evaluations, AIRT assessments, and world resources before removing the project itself