Working with projects
A project groups repositories, triggers, builds, and variables inside a workspace. Every repository belongs to exactly one. If you only have one team and one product, the single project you start with is all you need; projects earn their keep when several teams share a workspace and shouldn't see each other's variables.
For the concept, see Projects. This page is how to operate them.
Prefer to ask an agent?
An AI client connected to the MCP server can survey what exists before you reorganise anything:
- "List the repositories in my Loha workspace and group them by project."
Creating and deleting projects is dashboard-only. Using AI with Loha
Create a project
The + button beside the project switcher works from any screen, or use the Projects grid at your workspace root.
You give it two things:
- a name: display only, editable later
- a slug: URL-safe and permanent
The slug appears in every bookmarkable URL beneath the project (/<workspace>/<project>/...), which is why it can't be changed afterwards. Pick something you'll still be happy with in a year.
A new project starts empty. Connecting a repository is the first useful thing to do in it.
With a single project, connecting a repository puts it there automatically. Once a workspace has two or more, Loha refuses to guess: the connect dialog asks which project the repo belongs to. There is no silent default.
What lives inside a project
| Surface | What it holds |
|---|---|
| Overview | Recent builds and repo/trigger counts for this project |
| Repos | The repositories in this project |
| Triggers | Triggers for those repositories |
| Builds | Build history, filtered to this project |
| Variables | Project-scoped variables and secrets |
| Settings → General | Rename, read the slug and id, delete |
| Settings → Deploy targets | Deploy targets for this project |
| Settings → Service accounts | Service accounts bound to this project |
Project variables are visible to every build in the project and to nobody outside it. That boundary is the main reason to split a workspace into projects.
Rename a project
Settings → General. The display name changes everywhere; the slug and all URLs stay as they are.
Delete a project
Settings → General, in the danger zone.
A project with repositories attached cannot be deleted: the request is refused rather than cascading. Move or disconnect its repositories first, then delete the empty project. This is deliberate: deleting a project that still owned repos would take their triggers and build history with it.
See also
- Projects: the concept and the default-project invariant
- Secrets management: variable scopes and precedence
- Deploy targets: where a project deploys to
- Creating a trigger: making a repo actually build