Skip to content

Projects

A project is the core deployable unit in Flagon, scoped to an organization.

A project is the core unit in Flagon: a deployable app. There is no separate "app" layer above it, following the Vercel model. Every project belongs to an organization, and its URLs are org-scoped: app.flagon.io/<org>/<project>.

Creating a project

You can create a project three ways, and they all go through the same API operation:

  • In the UI, from the organization's dashboard.
  • By asking the in-product assistant ("create a project called billing-api").
  • Directly against the API, or through an external agent over MCP.

Because every path calls the same permission-checked API operation, a project created by the agent is identical to one created by hand.

The project page

A project reads like a repository. Its Overview tab renders the README as a document, with an inline editor (Edit and Preview) for members. The Settings tab holds the project's name, slug, description, and repository URL, plus the delete action. Later, linking a real repository will sync the README automatically instead of editing it in place.

Editing a project

You can change a project's name, slug, description, and repository URL from the Settings tab, and its README from the Overview tab, by asking the assistant, or over the API. Edits are partial: only the fields you change are touched. Renaming the slug changes the project's URL. Editing requires write access (members and above; viewers are read-only).

Deleting and restoring

Deleting a project is a soft delete: the project is hidden and stops counting, but it can be restored. Deleting frees the slug immediately, so you can create a new project with the same name right away.

Restoring brings the project back, but only if its slug is still free. If a new project has since taken that name, restore is refused until you free the slug (for example by renaming the new project). Because they are destructive, delete and restore are an owner-tier action: a project owner (an individual or a team) or an org owner/admin, who always have owner authority. A plain project admin can manage access but cannot delete the project. Like everything else, all three actions go through the same permission-checked API operation whether you use the UI, the assistant, or MCP.

Deleted projects are listed under Settings > Archive > Deleted projects, with the time each was deleted and a one-click restore. The same list is available to the assistant and MCP for reading, so you can ask which projects were recently deleted and restore one by name.

Ownership and access

Projects inherit their organization's membership and roles, and can layer repository-style collaborator roles on top for finer control on a single project. See Project access for the roles and how they combine.

Access is permission-scoped from day one: a token or agent can only act on a project if its scope allows it, and tenant isolation is enforced in the database with row-level security, so one organization can never see another's projects.