@mediamonks/canopy-cli 0.7.11 → 0.7.12

package/dist/docs/overview-faq.md

@@ -1,105 +0,0 @@
----
-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

@@ -1,82 +0,0 @@
----
-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. The password stays visible in Settings, so you can look it up and
-share it again later. 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.

package/dist/docs/overview-use-cases.md

@@ -1,76 +0,0 @@
----
-title: Use cases
-description: What kinds of projects belong on Canopy — and which ones should live somewhere else.
----
-
-Canopy is built for many small projects, not one big one. It shines when you
-want to get an idea in front of colleagues or a client quickly, with real data
-and real AI behind it, without asking anyone to set up infrastructure.
-
-## Good fits
-
-**Client-facing prototypes.** You're pitching a concept and want the client to
-click through something real, not a slide deck. Build it with your agent,
-deploy it, and share the link with a project password — the client sees a
-working app without needing a Monks account, and nobody else on the internet
-can.
-
-**Internal tools.** A small utility your team needs: a content checker, a
-campaign asset tracker, a review queue. It sits behind Monks sign-in
-automatically, saves its data to its own database, and stays available without
-anyone babysitting a server.
-
-**Demos and experiments with AI.** You want to show what a model can do with
-your workflow — a summarizer, a brief generator, a chat over project material.
-Canopy gives the project AI access with a hard spend cap, so an enthusiastic
-demo (or a runaway loop) can never turn into a scary bill.
-
-**Microsites that need data or uploads.** A small site for a workshop, an
-internal survey, a moodboard collector. Structured data and file uploads work
-through simple calls — no database setup, and uploaded files are never left
-publicly exposed.
-
-**Projects with client or project data.** Canopy projects may hold real client
-material. Each project's data is isolated — its own database, its own storage
-space — and everything sits behind sign-in, so work-in-progress with real
-content is a normal use, not an exception.
-
-### A few concrete scenarios
-
-- A strategist vibecoding a pitch prototype over a weekend, sharing it Monday
-  behind a client password.
-- A producer building a tracker the whole team uses daily, with teammates
-  invited as collaborators.
-- A developer prototyping an AI-assisted workflow with a custom backend,
-  scheduled jobs, and secrets — still inside platform auth and budgets.
-
-## Not a fit
-
-Canopy has deliberate anti-goals. If your project is one of these, it belongs
-on another platform from day one:
-
-- **Public production apps.** Nothing on Canopy is reachable without OneLogin
-  or a project password. A public marketing site, a consumer app, or anything
-  meant for anonymous visitors can't live here.
-- **Apps that need production guarantees.** There are no SLAs, no autoscaling,
-  no multi-region hosting. If downtime would be a real incident, you need
-  dedicated hosting.
-- **Arbitrary server stacks.** Canopy is not a general-purpose cloud — no
-  bring-your-own database, no arbitrary long-running servers or containers.
-  Projects use the platform's building blocks.
-- **Data pipelines and integration hubs.** Canopy can talk to existing internal
-  services, but it's not the place where data warehousing or pipelines live.
-
-> **Note:** The rule of thumb: Canopy is the greenhouse, not the forest. When a project proves itself and
-> needs scale, guarantees, or a public audience, it graduates — exporting its code, database, and
-> files cleanly to dedicated hosting.
-
-## Not sure?
-
-If your project mostly needs to be seen by Monks or a specific client, saves a
-modest amount of data, and would benefit from shipping this week instead of
-this quarter — it's probably a Canopy project. If in doubt, start on Canopy;
-graduation is a supported path, not a rewrite.
-
-- [What is Canopy?](https://docs.canopy.website/overview/what-is-canopy) — The platform in plain language — who it's for and what's managed.
-- [FAQ](https://docs.canopy.website/overview/faq) — Who can see my project, what happens when a deploy breaks, and more.

package/dist/docs/overview-what-is-canopy.md

@@ -1,75 +0,0 @@
----
-title: What is Canopy?
-description: A fully managed home for vibecoded Monks projects — hosting, sign-in, data, files, and AI, all set up before your first prompt.
----
-
-Canopy is where Monks put the projects they vibecode with AI tools. You describe
-an idea, your AI agent builds it, and Canopy runs it — with sign-in, a database,
-file storage, and AI access already wired up and safe before you write (or
-prompt) a single line.
-
-Think of it as a greenhouse: a protected place where small projects can grow
-quickly. When one proves its value, it can graduate to its own dedicated home —
-nothing is trapped here.
-
-## Who it's for
-
-Canopy serves two kinds of builders on one platform:
-
-- **Vibers** — producers, designers, PMs, and strategists who build with AI
-  agents. The platform is your guardrail: you can't accidentally publish
-  something to the open internet, leak a file, or run up a runaway AI bill,
-  because the safe path is the only path.
-- **Coders** — developers who want the same paved road (auth, database, storage
-  arranged for them) plus escape hatches like raw SQL and their own backend
-  code when they need more control.
-
-If you can prompt an AI coding agent, you can ship on Canopy.
-
-## What "fully managed" means
-
-You never touch infrastructure. The platform team owns and operates everything
-behind the scenes, so for you it looks like this:
-
-- **Hosting.** Every project gets its own web address on `canopy.website`. You
-  don't set up servers, domains, or certificates.
-- **Sign-in, always on.** Every project sits behind Monks OneLogin
-  automatically. Any Monk can open it by default; you can tighten access to
-  collaborators only, or add a shared password so clients without a Monks
-  account can see work-in-progress. Nothing on Canopy is ever truly public.
-- **Data and files.** Each project has its own private database and file
-  storage. No tables to design, no migrations, no connection strings — and no
-  other project can see your data.
-- **AI with guardrails.** Projects can talk to the major AI models through the
-  platform, with a hard spend cap per project and full visibility of what
-  you've spent.
-- **Deploys.** Putting a new version online is one step — from the terminal,
-  from the dashboard, or automatically when code lands in your repository. Every
-  deploy becomes a version you can preview and roll back to.
-
-> **Note:** Curious how a project moves from idea to live URL? See [How it works](https://docs.canopy.website/overview/how-it-works).
-
-## What you need to get access
-
-- **A Monks account.** You sign in to everything — the dashboard and every
-  project — with OneLogin. Your Canopy account is created automatically the
-  first time you sign in.
-- **The dashboard.** [dashboard.canopy.website](https://dashboard.canopy.website)
-  is where you see your projects, invite teammates, browse data, check usage,
-  and manage settings.
-- **The Canopy CLI (optional but usual).** A small command-line tool your AI
-  agent uses to create, preview, and deploy projects. The
-  [getting started guide](https://docs.canopy.website/guides/getting-started) walks you through
-  installing it and connecting your coding agent — the agent does most of the
-  typing for you.
-
-## What Canopy is not
-
-Canopy is deliberately not a production hosting platform. There are no uptime
-guarantees, no autoscaling, and nothing reachable by the anonymous public
-internet. Projects that outgrow the greenhouse graduate: they export cleanly
-(code, database, files) and move to dedicated hosting. See
-[Use cases](https://docs.canopy.website/overview/use-cases) for what belongs here and what doesn't.
-
-- [How it works](https://docs.canopy.website/overview/how-it-works) — The life of a project, from creation to rollback, in plain words.
-- [Getting started](https://docs.canopy.website/guides/getting-started) — Install the CLI, sign in, and ship your first project.

package/dist/docs/platform-ai-usage.md

@@ -1,65 +0,0 @@
----
-title: AI access & usage
-description: Projects talk to AI models through the platform — no API keys to manage, a hard daily budget per project, and full visibility of spend.
----
-
-Canopy projects can call AI models without you ever handling an API key. The
-platform routes every request through its own metered gateway, tracks what
-each project spends, and enforces a hard daily budget — so a runaway loop in
-a vibecoded app becomes a capped bill and a visible chart, not a surprise
-invoice.
-
-## What your app gets
-
-The SDK exposes AI as a first-class building block:
-
-```ts
-const reply = await canopy.ai.chat({
-  messages: [{ role: "user", content: "Summarize this note…" }],
-});
-```
-
-- **No keys in your code.** Requests authenticate as the project; the
-  platform holds the provider credentials.
-- **A curated model list.** Each site enables a set of models
-  (`provider/model`, e.g. `anthropic/claude-haiku-4-5`) with a sensible
-  default — ask for a model outside the list and the API tells you what _is_
-  available.
-- **Streaming** via `canopy.ai.chatStream()` for chat-style UIs.
-- **An OpenAI-compatible endpoint.** `canopy.ai.endpoint()` returns a base
-  URL and model list you can plug into ecosystem tools (like the Vercel AI
-  SDK) — same key handling, same budget, same tracking.
-
-## The daily budget
-
-Every project has a daily AI budget in USD. When a project's spend for the
-day crosses it, further AI calls answer with an `ai_budget_exceeded` error
-until the day rolls over. The budget is enforced from the same spend ledger
-the dashboard displays, so what you see and what's enforced can never
-disagree.
-
-> **Note:** Hitting the cap doesn't break the rest of your app — pages, data, and files keep working. Only AI
-> calls pause until the next day.
-
-## The Usage tab
-
-Open a project in the dashboard and the **Usage** tab shows where it stands:
-
-- **LLM spend** — estimated cost, request count, and tokens over the recent
-  window, broken down by model and by day.
-- **Activity** — page loads today and over the last 7 days, plus when the
-  project was last visited. A quick answer to "is anyone actually using
-  this?"
-- **Storage & deploys** — database size, blob storage footprint, and how many
-  versions have shipped.
-
-## From the terminal
-
-`canopy usage` prints the same view without leaving your shell:
-
-```bash
-canopy usage          # AI spend, activity, storage, deploys
-canopy usage --json   # machine-readable, for agents and scripts
-```
-
-- [Getting started](https://docs.canopy.website/guides/getting-started) — Create a project and let your coding agent wire up AI, data, and files.

package/dist/docs/platform-client-access.md

@@ -1,54 +0,0 @@
----
-title: Client access
-description: Share a project with clients who have no Monks account — a shared password unlocks that one project's URL and nothing else.
----
-
-Everything on Canopy normally requires a Monks sign-in — which is exactly
-right until you want a client to see work-in-progress. Client access solves
-that: you set a shared password on a project, send the client the URL and the
-password, and they're in. No account creation, no invitations, no exceptions
-punched through the platform for anyone else.
-
-## How it works
-
-With client access enabled, a visitor without a Monks session who opens the
-project's URL gets a simple password page instead of the SSO redirect. Enter
-the right password and the app loads; Monks can still click through to
-company sign-in from the same page.
-
-The unlock is deliberately narrow:
-
-- **One project only.** The password grants access to that project's own
-  subdomain and nothing else — it can't be used on any other project or on
-  the dashboard.
-- **The live app only.** Clients see what a signed-in viewer would see. They
-  never get the dashboard, the data browser, deploy history, or settings.
-- **It expires.** Access is a temporary session on that browser; when it
-  lapses, the password page comes back.
-
-## Enabling it
-
-Open the project's **Settings** tab and use the **Who outside Monks can open
-it** card:
-
-1. Set a password. Pick something you're comfortable saying out loud on a
-   call — it's a shared secret, not a personal credential.
-2. Send the client the project URL and the password.
-
-To change the password, set a new one — previously handed-out passwords stop
-working for new sign-ins. To turn client access off entirely, remove the
-password from the same card; visitors are back to Monks-only immediately.
-
-> **Warning:** A shared password is deliberately lightweight protection — right for work-in-progress previews,
-> wrong for anything sensitive. Anyone who has it can view the app and share it further, so rotate
-> it when a review round ends.
-
-## Playing well with other access controls
-
-Client access is independent of
-[collaborators-only mode](https://docs.canopy.website/platform/members-and-access): you can lock
-the app down for Monks outside the team while a client with the password
-still gets in. That combination — "the client and the project team, nobody
-else" — is a common setup during a review phase.
-
-- [Members & access](https://docs.canopy.website/platform/members-and-access) — Who can view and who can manage a project, and how to tighten it.

package/dist/docs/platform-deploys-and-rollbacks.md

@@ -1,93 +0,0 @@
----
-title: Deploys & rollbacks
-description: Every deploy is a numbered version you can preview, download, and make live again — rolling back is instant and loses nothing.
----
-
-Every time you publish a project, Canopy records it as a numbered version —
-v1, v2, v3, and so on. The live site is simply a pointer at one of those
-versions. That one idea powers everything on this page: previews, rollbacks,
-and downloads are all just different ways of looking at (or pointing at) a
-version that already exists.
-
-## What a deploy contains
-
-A deploy is the built files of your app — the HTML, JavaScript, CSS, and other
-assets your build produces. Projects with a custom backend also ship their
-worker code in the same deploy, so frontend and backend always move together
-as one version.
-
-A deploy only goes live after every file has been uploaded and validated. A
-connection that drops halfway never leaves your project in a broken state —
-the previous version keeps serving until the new one is complete.
-
-## Ways to deploy
-
-- **From the terminal** — `canopy deploy` builds your project and publishes a
-  new version. This is what your coding agent runs. See the
-  [deploy guide](https://docs.canopy.website/guides/deploy) for details.
-- **From the dashboard** — on the project's Overview tab, upload a new version
-  by dragging in a zip, a folder, or loose files. No command line required.
-- **Automatically from CI** — create a project-scoped deploy token, add it to
-  your repository's secrets, and merging to `main` ships a new version on its
-  own. See [CI and deploy tokens](https://docs.canopy.website/guides/ci).
-
-The dashboard's deploy history shows every version with who published it and
-where it came from (CLI, dashboard, or CI).
-
-## Rolling back
-
-If a deploy goes wrong, point the site back at an earlier version. Rollback
-moves the live pointer — nothing is copied, rebuilt, or deleted, so it takes
-effect immediately and every version keeps its identity. Projects with a
-custom backend roll their backend back to the matching version too.
-
-- **Dashboard** — open the project's Overview tab and pick the version to make
-  live from the deploy history.
-- **CLI**:
-
-```bash
-canopy rollback        # pick a version from a list
-canopy rollback v3     # make v3 live directly
-```
-
-You can also "roll forward": after reverting to v3, making v5 live again is
-the same one-step operation. Any version in the history can be live.
-
-## The staging channel
-
-Beyond previews, every project can have a full **staging channel**: a staged
-version served at `https://staging-dot-<slug>.canopy.website` with its own
-database (a copy of live), its own files, and its own backend. Deploy there
-with `canopy deploy --staging` (or the dashboard's upload dialog), verify, and
-**promote** — the exact staged version becomes live, schema migrations
-replaying against the live database first. See
-[Staging & promoting](https://docs.canopy.website/guides/staging).
-
-## Previewing any version
-
-Every version has its own stable preview URL, so you can open an old build
-next to the current one without touching what's live:
-
-```
-https://v12-dot-<slug>.canopy.website
-```
-
-Preview URLs sit behind the same sign-in as the live site — they're for
-comparing builds and reviewing history, not for sharing something different
-from what access settings allow. A preview shows an old frontend against the
-live data; for a full candidate environment (frontend + backend + own
-database) use the staging channel above.
-
-## Downloading a version
-
-You can download the exact files behind any past version as a zip — handy for
-comparing builds or restoring something by hand:
-
-- **Dashboard** — from the version's entry in the deploy history.
-- **CLI** — `canopy download`, which lets you pick a version.
-
-Downloads are limited to the project's members; the deploy bundle is your
-source, not the public site.
-
-- [Deploying](https://docs.canopy.website/guides/deploy) — Build commands, canopy.json, and what canopy deploy does step by step.
-- [CI and deploy tokens](https://docs.canopy.website/guides/ci) — Ship a new version automatically on every push to main.

package/dist/docs/platform-egress.md

@@ -1,75 +0,0 @@
----
-title: Outbound requests
-description: Which external hosts your project's backend may fetch — a per-project allowlist you manage yourself.
----
-
-Outbound `fetch` from a project's backend worker is **deny-by-default**: the
-platform only lets requests through to platform infrastructure (your database,
-files, AI, the Canopy API) and to the hosts on your project's own
-**egress allowlist**. Anything else is answered locally with a 403
-`egress_denied` — the request never leaves the runtime.
-
-That default is deliberate: a thousand idle vibecoded projects should not be
-able to call arbitrary internet hosts. When your project genuinely needs an
-external API, you allow that host yourself — no platform-team ticket.
-
-> **Note:** Enforcement applies on every target. On GCP the runtime answers the 403 itself; on Cloudflare the
-> platform vets each outbound request outside your worker. Same rule, same error, one allowlist.
-
-## Allowing a host
-
-CLI, from the project directory:
-
-```bash
-canopy egress allow generativelanguage.googleapis.com
-canopy egress list
-canopy egress remove generativelanguage.googleapis.com
-```
-
-Or in the dashboard: **Settings → Outbound hosts**.
-
-Changes apply to the **running** workers within moments — the platform re-rolls
-the project's services with the new list, no deploy needed. Live and staging
-share one list, like secrets: the staging worker is the same code and needs the
-same hosts.
-
-## What an entry looks like
-
-- A bare hostname: `api.example.com` — matches exactly that host.
-- A subdomain wildcard: `*.googleapis.com` — matches any subdomain
-  (`storage.googleapis.com`, `a.b.googleapis.com`) but **not** the apex
-  `googleapis.com`.
-
-Hostnames only: no IP addresses, CIDR ranges, ports, schemes, or paths, and no
-`*` catch-all. Entries are case-insensitive; unicode names are stored in their
-punycode form. A project can list up to **32** hosts.
-
-## What doesn't count as egress
-
-Everything you reach through the SDK — `canopy.db`, `canopy.blob`,
-`canopy.ai`, and `env.CANOPY.fetch` — goes through the platform and is always
-allowed. The allowlist only governs direct `fetch` calls from your worker code
-to the outside world. (Frontend code in the browser is unaffected — this is
-about the worker.)
-
-## When a request is denied
-
-The blocked `fetch` resolves (in ~2ms, no network attempt) with status 403 and
-body:
-
-```json
-{ "error": "egress_denied", "detail": "host api.example.com is not on the project allowlist" }
-```
-
-Allow the host and retry — see the
-[troubleshooting entry](https://docs.canopy.website/guides/troubleshooting#egress_denied-403).
-
-## Recently blocked hosts
-
-You don't have to guess what got denied: the runtime reports every blocked
-host back to the platform, and they show up as **Recently blocked** in
-Settings → Outbound hosts (and in `canopy egress list`), with how often and
-how recently each was hit. One click on **Allow** puts the host on the list
-and clears it from the blocked section. Hosts that keep a low profile drop
-off — the list remembers the 50 most recent — and allowing a host removes its
-blocked entry immediately.