Manage projects

A project (a Space in the web app) has three homes, one per mode: the User view (/spaces/<slug>) is where people use its apps, chats and workflows; Studio (/projects/<slug>) is where builders build it; Governance (/settings/projects/<slug>, owners and admins) is where its people, access, budget and apps on/off are managed. The Studio view has tabs for building the project:

Tab	What you can do
Overview	Browse the project’s agents, workflows, skills, etc in one table
Workflows, Agents, Apps	The Space’s deployed workflows, agents and apps (`defineApp`)
Files	Browse the project’s shared draft (`luno/draft`) — the work-in-progress source, updated live
Data	Browse the active deploy’s tables (`defineTable`); members who can deploy also add, edit and delete rows
Metrics	Runs, errors, latency, tokens and cost over time (Metrics)
Evals	Eval runs uploaded with `luno evals run` (Test agents)
Deployments	View deployment versions, who deployed them, and which version is active
Settings	Update name, slug, folder path, description, repository sync, and danger-zone actions (leave, delete)

The project header includes quick actions for renaming the project, copying the project ID, copying the project URL when available, and deleting the project. Owners and admins also get a People and access in Governance link. In Governance, the Space’s People tab holds its members (invite, change roles, remove), permission groups, role descriptions, per-agent and per-workflow access lists, project API keys and effective permissions; Settings holds the lead and reviewers, budget (see Budgets), app defaults, the default role for new members and who may invite.

Create a project

Create projects from the web app or the CLI. New projects are inactive until you deploy code to them. Plans limit how many projects an organization can have (1 on Hobby, 5 on Pro and Early); creating a project past the limit returns an error.

luno projects list
luno projects create --name "Support automations"

Project slugs are generated from the name and are used by CLI commands such as --project support-automations. See the CLI reference for the full command list.

Members and access

Project membership controls who can see and work in a project. Org admins can see every project in the organization; other members see the projects they belong to. Project members have one of four roles, assigned per project:

Role	What they can do
Admin	Everything but members: settings, credentials, channel bindings, approvers, access lists, deploys, runs, deleting the project
Editor	Read the project, deploy code and triggers, manage project credentials and settings, and run agents and workflows
Operator	Read the project and use its agents and workflows (subject to access lists), without changing anything
Viewer	Read the project and its history only

Per-agent and per-workflow access lists, approvers, and project-scoped API keys are covered in Governance. Organization owners and admins manage a project’s members (see who manages members). Invite teammates from the Space’s Governance People tab or with the CLI:

luno projects members list --project support-automations
luno projects members invite --project support-automations --email ada@example.com --role editor
luno projects members invite --project support-automations --email ops@example.com --role operator

Only organization members can be added to a project. If someone is not in the organization yet, invite them to the organization first.

Project settings

Project admins and editors can update the project name and description. The default member role and who is allowed to invite members are member management: organization owners and admins set them.

luno --project support-automations project update --name "Support agents"
luno projects settings update --project support-automations --default-role editor
luno projects settings update --project support-automations --invite-permission admin

Use project settings for collaboration boundaries, not for runtime behavior. The codebase still defines what agents, workflows, triggers, actions, skills, and files the project can run.

Project credentials

Credentials can be scoped to a project. Use project-scoped credentials when every agent and workflow in the project should share the same connection, such as a Slack workspace, Linear workspace, or API key.

luno credentials create exa --scope project --project-slug support-automations --set apiKey=@env:EXA_API_KEY

Project credentials are available to the code that runs in that project. If different teams or environments need different credentials, put them in separate projects or set separate credential instances. See Credentials.

Delete or leave a project

Project admins can delete a project. Deleting a project removes the project and its platform state, so treat it as a destructive operation.

luno --project support-automations project delete --yes

Members can leave a project when they no longer need access:

luno projects members leave --project support-automations --yes

Next steps

Projects overview

Understand how projects organize automation work.

Deploy a project

Build and deploy the codebase behind a project.

Credentials

Connect project-scoped credentials for agents and workflows.

Run history

Inspect what has run in a project.

Get started

Learn

Build with AI

Resources

Manage projects

Create a project

Members and access

Project settings

Project credentials

Delete or leave a project

Next steps

Projects overview

Deploy a project

Credentials

Run history

​Create a project

​Members and access

​Project settings

​Project credentials

​Delete or leave a project

​Next steps

Projects overview

Deploy a project

Credentials

Run history

Create a project

Members and access

Project settings

Project credentials

Delete or leave a project

Next steps