Skip to main content
In Luno OS, everything you build belongs to a project. A project is a shared space for building and running your agents, workflows, triggers, and actions. Think of a project as the unit you build, deploy, give credentials to, invite teammates into, and inspect run history for. In the web app a project is called a Space. Spaces can be grouped into folders (the Space tree in Governance) to mirror how your company is organized; folders are only for organizing, the Space is still the unit. Each Space has one home per mode: people use it in the User view, builders build it in Studio, and owners and admins govern it (people, access, budget) in Governance. See Manage projects. An organization functions as your company’s workspace, and projects are the place where work is divided up. You might have one project for personal agents, another for support automations, and another for internal ops. When you create an organization, Luno OS automatically creates a default project named after the org (for example, Acme Default). Joining members are added to that project with its default role for new members; people invited with the organization role Member join as Operator at most (they can use agents, apps and workflows but not deploy or edit). You can create more projects as your work grows — up to your plan’s project limit (1 on Hobby, 5 on Pro and Early).

​
What belongs to a project?

Projects group the code and operational resources for a specific area of work:
  • Agents decide what to do when the steps are not fully known.
  • Workflows run known steps reliably.
  • Actions are typed capabilities agents and workflows reuse.
  • Triggers start agents or workflows automatically.
  • Skills teach agents how to do a job.
  • Files give agents static context to read.
  • Credentials let actions connect to external services.
  • Run history shows what happened after agents and workflows run.
  • Members can build, deploy, and manage the project.
Project membership controls who can see and work in a project. Members can build and deploy to projects they belong to, and org admins can see every project in the organization.

​
How code fits in

A project is defined in TypeScript. The codebase behind a project is the source of truth for the agents, workflows, triggers, actions, skills, and files it can run. luno init scaffolds that codebase with a standard layout:
Luno OS discovers everything under src/ by convention. Add a file that exports an agent, workflow, or trigger, and it becomes part of the project. Lint, typecheck, and test tooling ships in @meetluno/cli — not in project devDependencies. Because the project is code, your coding agent can read it, change it, run tests, and maintain it over time. See AI onboarding.

​
How to use projects

To build agents, workflows, etc, you edit the codebase and deploy it to a project — Luno OS is deploy-first. Deploy often: a full deploy ships everything, or --filter redeploys a single module fast.
The project is the platform home for your work, and the codebase defines what runs there. After linking and deploying, luno deploy and other project-scoped commands use the slugs in luno.config.ts automatically. You can also create and build projects from a chat-first agent over the Luno OS MCP server — a hosted workspace that deploys to the same platform. We recommend the local CLI path (CLI for agents) when your coding agent can work in an editor on your machine. To go the other way — get an existing project’s code onto your machine — luno pull fetches the shared draft into a local directory (or --published for the active deploy revision). See deploy a project.

​
Next steps

Manage projects

Create projects, invite teammates, and manage project settings.

Deploy a project

Deploy a TypeScript codebase to run on the platform.

Deploy individual files

Keep work-in-progress modules out of deploys.

Pull a project

Fetch the shared draft or active deploy source into a local directory.

Run history

Inspect the agents and workflows that have run in a project.