Projects

A Project is the durable product boundary inside one Workspace. It groups the resources for one application, site, workflow, or customer deliverable, and it never runs code itself. Every resource that belongs to the product carries the project’s project_id, so ownership, deployment history, domains, members, and usage all roll up to one boundary.

A Project always belongs to exactly one Workspace, and a Workspace belongs to one Organization. The Workspace is required: creating a Project with no workspace fails with WORKSPACE_REQUIRED.

1. Create a project

miosa project create "Lead Magnet" \
  --workspace-id "$MIOSA_WORKSPACE_ID" \
  --description "Customer lead capture app"

miosa project list
miosa project get lead-magnet

2. Add resources

# Create a sandbox in the workspace, then publish its output.
miosa create lead-magnet-dev --workspace acme-corp --wait
miosa deploy create --from-sandbox lead-magnet-dev --wait

3. Deploy

miosa deploy create --git https://github.com/me/lead-magnet --branch main --wait

Publishing creates an immutable version under the Deployment and prints the URL. Display the URL the API returns; never rebuild it from a slug.

Pick what you need

You want to	Page
See the project record, fields, and what lives inside it	Project resources
Run the full create, configure, deploy, and retire path	Project lifecycle
Manage members, permissions, and billing attribution	Members and usage

The project record, what attaches to it, and how it maps to your own platform.

Create, add resources, configure environments and secrets, deploy, and retire.

Members, permissions, usage attribution, and common mistakes.

Projects API Create, resolve, update, and inspect Projects.

Publishing Move from mutable source to an immutable candidate.

Domains Configure previews, generated app URLs, and exact hostnames.

Product model How the Organization, Workspace, and Project layers relate.

Organizations, workspaces, and projects form one hierarchy: Open the product model →.