Skip to content

Projects

Projects are grouping buckets inside a workspace. They help you organize runtimes, sandboxes, sessions, evaluations, and traces into named contexts without becoming the permission or execution boundary.

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:

  • Grouping — a common bucket for related runtimes, sandboxes, sessions, evaluations, and traces
  • A default context — when a create flow omits project_id, Dreadnode resolves the workspace’s default project

Projects do not own runtime lifecycle. Workspaces are the real boundary for permissions, storage, and execution.

Every project has a key — a URL-safe slug that uniquely identifies it within its workspace. Keys appear in URLs, API paths, and CLI output. They are immutable after creation in most contexts.

Interactive runtimes are explicit runtime and sandbox objects. They are workspace-scoped resources that also carry a project_id for grouping. Multiple runtimes can share the same project, and runtimes can be listed or filtered by project without the project owning their lifecycle. Capability attachments live on runtimes, not projects.

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

Traces remain queryable by project as a filter dimension. Use workspace-scoped trace and evaluation routes, then pass project_id when you want a project-specific view. Projects do not get their own trace or evaluation execution routes.

Projects can be managed from Studio, the CLI, or the API:

  • Studio: Create, rename, delete, and switch between projects from the sidebar.
  • API: Projects are available at GET /api/v1/org/{org}/ws/{workspace}/projects.
  • API: Traces, evaluations, runtimes, sessions, and sandboxes stay workspace-scoped resources; project is grouping metadata on those resources, not the path owner.

Deleting a project cascades to grouped resources — sessions, sandboxes (running sandboxes are stopped), evaluations, AIRT assessments, and world resources are removed along with the project.