@mediamonks/canopy-cli 0.7.5 → 0.7.7

package/dist/docs/developers-architecture.md

@@ -0,0 +1,106 @@
+---
+title: How the platform serves your project
+description: What happens between a browser and your deployed code — auth wall, static assets, the optional backend worker, and where data lives.
+---
+
+You never manage servers on Canopy, but it helps to know what the platform
+does with a request. This page covers the pieces a project developer actually
+touches; platform internals stay out of it.
+
+## The request path
+
+Every project lives at `https://<slug>.canopy.<domain>`. Requests hit the
+**gateway** first, which enforces authentication before any of your project's
+bytes are served — then either serves your deployed static files or, if the
+project has one, dispatches `/api/*` to your backend worker.
+
+```mermaid
+flowchart TD
+    B[Browser] --> G["Gateway<br/>auth wall: OneLogin session<br/>or client password"]
+    G -->|"most paths"| A["Static assets<br/>deployed build, SPA fallback"]
+    G -->|"/api/*"| W["Backend worker<br/>(optional, canopy.json 'worker')"]
+    G -->|"/_api/data/v1/*"| P["Platform data plane<br/>auth · db · blob · ai"]
+    W --> P
+    P --> D[("Project database<br/>+ blob prefix")]
+```
+
+## The auth wall
+
+Authentication is a platform property — your app cannot opt out, and must not
+build its own. A visitor without a valid session is redirected into the
+OneLogin sign-in flow; on projects with client access enabled, outsiders get a
+password page and receive a scope-limited `external` session instead. Only
+after that does any project code or asset get served. Your app just asks
+`canopy.auth.user()` who came through the door
+(see the [SDK reference](https://docs.canopy.website/sdk)).
+
+## Static assets and the SPA fallback
+
+A deploy uploads your built files as an immutable, numbered version; serving
+reads whichever version is live. Requests for paths that don't match a file
+fall back to `index.html`, so client-side routes like `/settings` work on a
+hard refresh without any configuration. Rollback just repoints "live" at an
+earlier version — instant, nothing rebuilt.
+
+The full path — including caching, version-pinned `v12-dot-<slug>` preview
+hosts, and the security review — is in
+[How static files are served](https://docs.canopy.website/guides/static-serving).
+
+## The optional backend worker
+
+Most projects are frontend-only: the SDK talks straight to the platform, and
+no server code exists. When you need server-side code — say, calling an
+external API with a secret the browser can't hold — the `worker` template adds
+a backend, declared in `canopy.json`:
+
+```json
+{
+  "slug": "my-app",
+  "build": "npm run build",
+  "dist": "dist",
+  "worker": "worker/index.ts"
+}
+```
+
+Requests under `/api/*` reach the worker (Hono-style handlers); everything
+else is still static serving. Three things to know:
+
+- **Requests arrive authenticated.** The worker sits behind the same gateway
+  wall as the frontend.
+- **Platform access goes through the same SDK**, via the `CANOPY` service
+  binding — same budgets, same data isolation as the browser:
+
+  ```ts
+  app.get("/api/hello", async (c) => {
+    const canopy = createCanopy({ fetch: c.env.CANOPY.fetch.bind(c.env.CANOPY) });
+    const user = await canopy.auth.user();
+    return c.json({ message: `Hello, ${user.name}!` });
+  });
+  ```
+
+- **Secrets and schedules come from the dashboard.** Secrets (Settings →
+  Secrets) land as Workers-shaped bindings (`c.env.MY_API_KEY`, not
+  `process.env`); dashboard Schedules invoke an exported
+  `scheduled(event, env)` — switch on `event.name`.
+
+> **Warning:** Backend workers are capability-gated per target: today the GCP target runs them, while on
+> Cloudflare sites a worker deploy answers a clear "not supported yet". Frontend-only projects
+> deploy everywhere.
+
+## Where your data lives
+
+Every project gets its own database and its own blob-storage prefix. No other
+project can read them, and deleting the project tears everything down. The
+document API is portable across targets; raw SQL speaks the target's dialect
+(`sqlite` or `postgres` — ask `canopy.db.dialect()`). Dumps, snapshots, and
+restores are CLI commands — see the [project data guide](https://docs.canopy.website/guides/data).
+
+## Sites
+
+A _site_ is one installation of the whole platform. The CLI ships three
+profiles — `main` (canopy.website, Cloudflare), `staging` (thanarie.dev,
+Cloudflare), and `gcp-pilot` (canopy.monks.zone, GCP) — and always shows which
+one you're on. Projects pin theirs in `canopy.json`; `--profile` or
+`CANOPY_PROFILE` overrides per command. Most projects only ever use `main`.
+Target differences (dialect, full-text search, worker support) surface as
+capabilities, not separate APIs.

package/dist/docs/index.json

@@ -0,0 +1,331 @@
+{
+  "sections": [
+    {
+      "key": "overview",
+      "title": "Overview",
+      "description": "What Canopy is and how it works, in plain language.",
+      "topics": [
+        {
+          "slug": "overview-what-is-canopy",
+          "title": "What is Canopy?",
+          "summary": "A fully managed home for vibecoded Monks projects — hosting, sign-in, data, files, and AI, all set up before your first prompt."
+        },
+        {
+          "slug": "overview-use-cases",
+          "title": "Use cases",
+          "summary": "What kinds of projects belong on Canopy — and which ones should live somewhere else."
+        },
+        {
+          "slug": "overview-how-it-works",
+          "title": "How it works",
+          "summary": "The life of a Canopy project in plain words — create, build, deploy, roll back."
+        },
+        {
+          "slug": "overview-faq",
+          "title": "FAQ",
+          "summary": "Quick answers to the questions people ask before (and just after) putting a project on Canopy."
+        }
+      ]
+    },
+    {
+      "key": "guides",
+      "title": "Guides",
+      "description": "Hands-on walkthroughs — build, ship, and operate a project.",
+      "topics": [
+        {
+          "slug": "getting-started",
+          "title": "Getting started",
+          "summary": "Install the CLI, sign in with OneLogin, and ship your first project."
+        },
+        {
+          "slug": "dev",
+          "title": "Local development",
+          "summary": "Running a project locally against live or sandboxed data."
+        },
+        {
+          "slug": "deploy",
+          "title": "Deploying a project",
+          "summary": "How canopy deploy builds, uploads, and makes a version live."
+        },
+        {
+          "slug": "staging",
+          "title": "Staging & promoting",
+          "summary": "Deploy to a safe copy of your project first — own database cloned from live — then promote the exact same version."
+        },
+        {
+          "slug": "data",
+          "title": "Working with project data",
+          "summary": "Pulling, snapshotting, and restoring your project database."
+        },
+        {
+          "slug": "migrations",
+          "title": "Migrations & Drizzle",
+          "summary": "Evolve your own tables with versioned SQL migrations — generated by Drizzle or written by hand — applied safely by canopy deploy."
+        },
+        {
+          "slug": "ci",
+          "title": "CI and deploy tokens",
+          "summary": "Push-to-main deploys using a project-scoped deploy token."
+        },
+        {
+          "slug": "porting-nextjs",
+          "title": "Porting a Next.js app",
+          "summary": "How to restructure a Next.js (App Router) project so it runs on Canopy."
+        },
+        {
+          "slug": "cli",
+          "title": "CLI command reference",
+          "summary": "Every canopy command, its flags, and what it does."
+        },
+        {
+          "slug": "static-serving",
+          "title": "How static files are served",
+          "summary": "The full path a browser request takes to a deployed file."
+        },
+        {
+          "slug": "infrastructure",
+          "title": "Infrastructure as code",
+          "summary": "Terraform for the account-level Cloudflare pieces Canopy needs."
+        },
+        {
+          "slug": "troubleshooting",
+          "title": "Troubleshooting",
+          "summary": "Common errors and how to resolve them."
+        }
+      ]
+    },
+    {
+      "key": "platform",
+      "title": "Platform",
+      "description": "Each platform feature explained in depth.",
+      "topics": [
+        {
+          "slug": "platform-deploys-and-rollbacks",
+          "title": "Deploys & rollbacks",
+          "summary": "Every deploy is a numbered version you can preview, download, and make live again — rolling back is instant and loses nothing."
+        },
+        {
+          "slug": "platform-project-data",
+          "title": "Project data",
+          "summary": "Every project gets its own private database and file storage — browse it in the dashboard, snapshot it before risky changes, and pull it locally."
+        },
+        {
+          "slug": "platform-schedules",
+          "title": "Schedules",
+          "summary": "Run named cron jobs in your project's backend — configured in the dashboard, so you can change the cadence without redeploying."
+        },
+        {
+          "slug": "platform-egress",
+          "title": "Outbound requests",
+          "summary": "Which external hosts your project's backend may fetch — a per-project allowlist you manage yourself."
+        },
+        {
+          "slug": "platform-ai-usage",
+          "title": "AI access & usage",
+          "summary": "Projects talk to AI models through the platform — no API keys to manage, a hard daily budget per project, and full visibility of spend."
+        },
+        {
+          "slug": "platform-members-and-access",
+          "title": "Members & access",
+          "summary": "Everything on Canopy sits behind Monks sign-in. Collaborators manage a project; other Monks can view the live app — unless you tighten it."
+        },
+        {
+          "slug": "platform-feedback",
+          "title": "Feedback & bug reports",
+          "summary": "A built-in feedback widget on every project, a ticket-lite inbox behind it, and a CLI that lets agents work the backlog."
+        },
+        {
+          "slug": "platform-client-access",
+          "title": "Client access",
+          "summary": "Share a project with clients who have no Monks account — a shared password unlocks that one project's URL and nothing else."
+        },
+        {
+          "slug": "platform-sites-and-profiles",
+          "title": "Sites & profiles",
+          "summary": "Canopy runs as more than one installation. Most people only ever use main — here's what the others are and how the CLI keeps them straight."
+        }
+      ]
+    },
+    {
+      "key": "cli",
+      "title": "CLI reference",
+      "description": "Every canopy command: usage, flags, and examples.",
+      "topics": [
+        {
+          "slug": "cli-index",
+          "title": "Installing the CLI",
+          "summary": "Install the canopy CLI, sign in, and learn the conventions every command shares."
+        },
+        {
+          "slug": "cli-login",
+          "title": "canopy login",
+          "summary": "Sign in to Canopy through OneLogin in your browser and store CLI tokens for every site."
+        },
+        {
+          "slug": "cli-whoami",
+          "title": "canopy whoami",
+          "summary": "Show which account and site the CLI is currently talking to, and whether your token is still valid."
+        },
+        {
+          "slug": "cli-logout",
+          "title": "canopy logout",
+          "summary": "Sign out of Canopy by removing all locally stored CLI tokens."
+        },
+        {
+          "slug": "cli-create",
+          "title": "canopy create",
+          "summary": "Register a new project on Canopy and scaffold it locally from a starter template."
+        },
+        {
+          "slug": "cli-init",
+          "title": "canopy init",
+          "summary": "Set up a local folder for a project that already exists on Canopy — scaffold a starter or link an existing app."
+        },
+        {
+          "slug": "cli-projects",
+          "title": "canopy projects",
+          "summary": "List your Canopy projects with their status, role, and live URLs."
+        },
+        {
+          "slug": "cli-delete",
+          "title": "canopy delete",
+          "summary": "Permanently delete a Canopy project — its deploys, database, and files."
+        },
+        {
+          "slug": "cli-dev",
+          "title": "canopy dev",
+          "summary": "Run your project locally with a Vite dev server, against live platform data or a local sandbox."
+        },
+        {
+          "slug": "cli-deploy",
+          "title": "canopy deploy",
+          "summary": "Build the project and push a new version live, from your machine or from CI."
+        },
+        {
+          "slug": "cli-promote",
+          "title": "canopy promote",
+          "summary": "Make the staged version live — migrations replay against the live database first, then the exact staged artifacts go live."
+        },
+        {
+          "slug": "cli-staging",
+          "title": "canopy staging",
+          "summary": "Inspect, refresh, or tear down the project's staging channel."
+        },
+        {
+          "slug": "cli-rollback",
+          "title": "canopy rollback",
+          "summary": "Make an earlier deploy live again by moving the live pointer to a previous version."
+        },
+        {
+          "slug": "cli-download",
+          "title": "canopy download",
+          "summary": "Download the deployed files of any version of a project as a zip archive."
+        },
+        {
+          "slug": "cli-token",
+          "title": "canopy token",
+          "summary": "Create, list, and revoke project-scoped deploy tokens for CI and push-to-main deploys."
+        },
+        {
+          "slug": "cli-egress",
+          "title": "canopy egress",
+          "summary": "Manage which outbound hosts the project's backend worker may fetch."
+        },
+        {
+          "slug": "cli-db",
+          "title": "canopy db",
+          "summary": "Pull, snapshot, list, restore, and migrate a project's database from the terminal."
+        },
+        {
+          "slug": "cli-logs",
+          "title": "canopy logs",
+          "summary": "Read your project worker's logs (console output) from the terminal — no cloud console access needed."
+        },
+        {
+          "slug": "cli-usage",
+          "title": "canopy usage",
+          "summary": "Show a project's AI spend, storage footprint, and deploy count from the terminal."
+        },
+        {
+          "slug": "cli-feedback",
+          "title": "canopy feedback",
+          "summary": "Read and triage a project's feedback inbox, or file a bug/feedback report — against a project or against Canopy itself."
+        },
+        {
+          "slug": "cli-open",
+          "title": "canopy open",
+          "summary": "Open the deployed project in your browser."
+        },
+        {
+          "slug": "cli-docs",
+          "title": "canopy docs",
+          "summary": "Read the Canopy docs from the terminal — live from the platform, with offline fallbacks."
+        },
+        {
+          "slug": "cli-skill",
+          "title": "canopy skill",
+          "summary": "Install the Canopy agent skill into a repo so coding agents know how to drive the platform."
+        },
+        {
+          "slug": "cli-upgrade",
+          "title": "canopy upgrade",
+          "summary": "Update the Canopy CLI to the latest published version, using the installer that put it there."
+        }
+      ]
+    },
+    {
+      "key": "sdk",
+      "title": "SDK reference",
+      "description": "The typed client your project code uses — auth, data, files, AI, services.",
+      "topics": [
+        {
+          "slug": "sdk",
+          "title": "Using the SDK",
+          "summary": "One typed client for auth, data, files, AI, and services — no keys, no connection strings, the platform authenticates for you."
+        },
+        {
+          "slug": "sdk-auth",
+          "title": "Auth",
+          "summary": "Read who the platform signed in — you never build a login screen."
+        },
+        {
+          "slug": "sdk-database",
+          "title": "Database",
+          "summary": "Document-style collections on your project's private database, plus a raw SQL escape hatch."
+        },
+        {
+          "slug": "sdk-files",
+          "title": "Files",
+          "summary": "Upload, download, and list files on your project's private blob storage."
+        },
+        {
+          "slug": "sdk-ai",
+          "title": "AI",
+          "summary": "Metered LLM access through the project's budget-capped gateway key — chat, streaming, and an OpenAI-compatible endpoint."
+        },
+        {
+          "slug": "sdk-services",
+          "title": "Services",
+          "summary": "Curated internal data services, invoked through the platform's connector — auth handled for you."
+        }
+      ]
+    },
+    {
+      "key": "developers",
+      "title": "For developers",
+      "description": "Architecture and building with agents.",
+      "topics": [
+        {
+          "slug": "developers-architecture",
+          "title": "How the platform serves your project",
+          "summary": "What happens between a browser and your deployed code — auth wall, static assets, the optional backend worker, and where data lives."
+        },
+        {
+          "slug": "developers-agents-and-ai",
+          "title": "Building with agents",
+          "summary": "Teach your coding agent Canopy — the agent skill, offline docs, template guardrails, and prompts that work."
+        }
+      ]
+    }
+  ]
+}

package/dist/docs/infrastructure.md

@@ -340,21 +340,18 @@ export CANOPY_PROJECT_PROTOCOL="https"
 
    cd ../../examples/kitchen-sink
    canopy-dev --profile main create "Kitchen Sink" --slug kitchen-sink --no-scaffold
-   # CF target: capabilities.workers = false — strip worker for this deploy
-   cp canopy.json canopy.json.bak
-   # remove the "worker" key (jq / editor), then:
    canopy-dev --profile main deploy
-   mv canopy.json.bak canopy.json
    ```
 
    `canopy.json` already carries the slug, build command, dist dir, and a
    usual `"profile": "main"` pin, so `deploy` builds them — no separate
    `pnpm build` needed. Still pass `--profile` for the intended site so a
    stray active profile cannot send the deploy elsewhere
-   (docs/10-cli-sites.md). A kitchen-sink deploy that keeps
-   `"worker": "worker/index.ts"` will 501 `not_supported_on_target` on
-   Cloudflare; assets-only is enough to exercise `db` / `blob` / `ai.chat`
-   through the platform data plane.
+   (docs/10-cli-sites.md). On a site without worker support
+   (`capabilities.workers = false`), a deploy that keeps
+   `"worker": "worker/index.ts"` will 501 `not_supported_on_target` — strip
+   the `worker` key for an assets-only deploy there; that's still enough to
+   exercise `db` / `blob` / `ai.chat` through the platform data plane.
 
 ### 11. AI Gateway keys + spend rule (script)
 

package/dist/docs/overview-faq.md

@@ -0,0 +1,105 @@
+---
+title: FAQ
+description: Quick answers to the questions people ask before (and just after) putting a project on Canopy.
+---
+
+Short answers to common questions. If yours isn't here, the guides go deeper —
+start with [getting started](https://docs.canopy.website/guides/getting-started).
+
+## Who can see my project?
+
+By default, any Monk who signs in with OneLogin. If that's too broad, switch
+the project to **collaborators only** in Settings — then only the people you've
+invited can open the live app (it still appears in the company project list,
+and platform admins can still manage it).
+
+## Can clients without OneLogin see it?
+
+Yes. You can put a shared **password** on a project from its Settings. Anyone
+you give the password to can view the app without a Monks account — useful for
+sharing work-in-progress with a client. That's the only way in without
+OneLogin; there is no fully public option.
+
+## Can I make my project public?
+
+No, and that's deliberate. Nothing on Canopy is reachable without OneLogin or a
+project password. If your project needs an anonymous public audience, it
+belongs on dedicated hosting — see [Use cases](https://docs.canopy.website/overview/use-cases).
+
+## What happens if a deploy breaks something?
+
+Nothing you can't undo. Every deploy is a numbered version, and you can make
+any earlier version live again in one step from the dashboard or the CLI. You
+can also open any past version at its own preview link to compare before
+deciding.
+
+## Where does my data live?
+
+With the project. Each project has its own private database and its own file
+storage space — no other project can touch them. You can browse the data in
+the dashboard, and take or restore database snapshots. Deleting a project
+deletes everything it owned.
+
+## Can my project use AI models? What stops a runaway bill?
+
+Projects get access to the major AI models through the platform, with a hard
+spend cap per project. If something loops out of control, it stops at the cap.
+You can see exactly what's been spent — by model — in the dashboard's Usage
+tab or from the CLI.
+
+## Does it cost anything?
+
+The platform is run by the Monks platform team, and it's designed so that idle
+projects cost essentially nothing. The costs that do exist — mainly AI usage —
+are visible per project in the dashboard and capped hard, so there are no
+surprises.
+
+## Do I need to know how to code?
+
+You need to be able to work with an AI coding agent — the agent writes the
+code, and Canopy's bundled skills keep it on the safe path. The
+[getting started guide](https://docs.canopy.website/guides/getting-started) shows how to connect your
+agent so it knows how the platform works.
+
+## Can I work on it with teammates?
+
+Yes. Invite people from the project's page in the dashboard with the people
+picker — as admins or collaborators. Combined with collaborators-only mode,
+this also controls who can open the live app.
+
+## Can I bring an app I already started?
+
+Yes. You don't have to start from a Canopy template — an existing app can be
+onboarded onto the platform and gain the same URL, sign-in, and deploy flow.
+The [getting started guide](https://docs.canopy.website/guides/getting-started) covers both paths.
+
+## Can I host my Next.js app on Canopy?
+
+Not as-is — Canopy serves pages as static files and deliberately runs no
+app servers, so server-side rendering, server components fetching at request
+time, and server actions have nowhere to run. What works well is a port:
+the frontend becomes a static build, backend logic moves into the project's
+worker under `/api/*`, and the platform takes over auth, database, files, and
+AI. For apps that only lightly use Next's server side that's a small job; the
+[porting guide](https://docs.canopy.website/guides/porting-nextjs) walks through it and helps you judge
+whether your app is a good fit.
+
+## Can it deploy automatically when we change the code?
+
+Yes. Create a project-scoped deploy token, add it to your repository's CI, and
+merging to `main` ships a new version on its own. The token can only deploy
+that one project — it can't touch your data. See the [CI guide](https://docs.canopy.website/guides/ci).
+
+## What if my project outgrows Canopy?
+
+It graduates. Canopy optimizes for many small projects, not for making one
+project big — so when yours needs scale, guarantees, or a public audience, it
+exports cleanly (code, database file, and file archive) and moves to dedicated
+hosting. No lock-in, no rewrite.
+
+## Is my project backed up if something goes wrong?
+
+You have two safety nets you control: versions (every deploy is kept, with
+rollback and download) and database snapshots (take one before a risky change,
+restore it if needed). For anything beyond that, remember Canopy offers no
+production guarantees — see [Use cases](https://docs.canopy.website/overview/use-cases).

package/dist/docs/overview-how-it-works.md

@@ -0,0 +1,81 @@
+---
+title: How it works
+description: The life of a Canopy project in plain words — create, build, deploy, roll back.
+---
+
+Every Canopy project follows the same simple lifecycle. Here's what happens at
+each step, without the technical machinery.
+
+## Create a project
+
+A project starts in one of two ways: your coding agent runs the Canopy CLI to
+create one from a starter template, or you register an app you already started.
+Either way, the project appears in the
+[dashboard](https://dashboard.canopy.website) the moment it exists — with its
+sign-in wall, database, file storage, and AI access already arranged.
+
+Starters come in three shapes — a simple static site, a fully-typed React app,
+or a React app with server-side code — so you begin from the shape that fits.
+The details live in the [getting started guide](https://docs.canopy.website/guides/getting-started).
+
+## Your project gets its own address
+
+Each project has a short name (its _slug_) and lives at its own URL:
+`your-slug.canopy.website`. You don't buy domains or configure anything — the
+address exists as soon as the project does.
+
+## Everything sits behind Monks sign-in
+
+Visitors to your project's URL hit OneLogin before they see anything. By
+default any Monk can open it. From the project's Settings you can tighten that
+to collaborators only, or add a shared client password so people outside Monks
+can view it. There is no "make it public" switch — that's by design.
+
+## Deploys create versions
+
+When you (or your agent) publish the project — one command from the terminal, a
+drag-and-drop upload in the dashboard, or automatically when code lands in your
+repository — Canopy records it as a new numbered **version** and makes it live.
+
+Versions are what make deploying low-stakes:
+
+- Every past version keeps a stable preview link, so you can open an older
+  build next to the newest one.
+- You can download the exact files behind any version.
+- If a deploy breaks something, you pick an earlier version in the dashboard or
+  CLI and make it live again in one step. That's a **rollback**, and it takes
+  seconds.
+
+More detail in the [deploying guide](https://docs.canopy.website/guides/deploy) and the
+[CI guide](https://docs.canopy.website/guides/ci) for automatic deploys on push.
+
+## Data lives with the project
+
+Whatever your app saves — records, uploads — goes into that project's own
+private database and storage space. No other project can read it, and deleting
+a project deletes everything it owned. You can browse the data from the
+dashboard, and take or restore **snapshots** of the database when you want a
+safety net before a risky change. See the [project data guide](https://docs.canopy.website/guides/data).
+
+## Usage is visible
+
+The dashboard's Usage tab shows how active a project is (page loads today and
+over the last 7 days), what its AI calls have cost by model, and its database,
+file, and deploy footprint. AI spending also has a hard per-project cap — a
+loop gone wrong stops at the cap instead of running up a bill.
+
+## Words you'll hear
+
+| Word                      | What it means                                                                                                                                                    |
+| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Project**               | One app on Canopy: its code, its URL, its database, its files, its settings, its people.                                                                         |
+| **Deploy**                | Publishing your project so the new state is live at its URL.                                                                                                     |
+| **Version**               | The numbered result of each deploy. Every version keeps a preview link and can be downloaded.                                                                    |
+| **Rollback**              | Making an earlier version live again, in one step.                                                                                                               |
+| **Snapshot**              | A saved copy of a project's database you can restore later.                                                                                                      |
+| **Slug**                  | The project's short name — the first part of its URL.                                                                                                            |
+| **Site** (or **profile**) | An installation of the Canopy platform. Most people only ever use the main one; the CLI can point at others (like staging) and always shows which one you're on. |
+| **Collaborator**          | A teammate invited to a project through the dashboard's people picker.                                                                                           |
+
+- [Getting started](https://docs.canopy.website/guides/getting-started) — From nothing to a live project, step by step.
+- [Local development](https://docs.canopy.website/guides/dev) — Preview changes on your machine against your real project data.