Hosting

Before you deploy

• Hosting is in beta: it is enabled per workspace on request, and needs a Pro plan or above.
• Use an API key that holds only sites:write, and keep it in your own shell. Do not reuse a build-time read key for it: a key an Astro build reads from an environment variable at build time is a wider blast radius than one that only ever runs a deploy from your machine.
• After Deployed: prints, Cloudflare’s edge can take up to about 20 seconds to serve the new version everywhere. If you refresh and see the old site, or a 522 on a file you just added, wait and try again.
• Rollback is best-effort, not guaranteed. Sedgemark stores each deployment’s manifest of content hashes, never the bytes, so a deployment whose files Cloudflare no longer holds has to be redeployed from your own source instead.

What it does, and does not do

sedgemark deploy is a command you run locally, from the command line. It runs your project’s own build, then hands the finished static output to Sedgemark, which publishes it to Cloudflare and hands back a live URL. Sedgemark never builds your code, never executes it, and never serves the bytes itself: it is a control plane in front of Cloudflare’s edge, so a Sedgemark outage cannot take a published site down.

Install and deploy

npm i @sedgemark/client

SEDGEMARK_API_KEY=pk_your_deploy_key_here npx sedgemark deploy

Use a separate API key from the one your site’s build reads content with. Deploying needs a key granted sites:write; reading content at build time needs only collections:read (plus forms:read if you also generate form types, see TypeScript client). Keeping them separate means a build-time key leaking into a CI log cannot be used to publish a new version of your site.

Checks run first, and are your safety net, not the server's

Before anything goes over the network, sedgemark deploy runs your own checks: an explicit deploy.checks array in sedgemark.config.json if you set one, otherwise lint/typecheck/test auto-detected from your package.json, cheapest first, with astro check filling the typecheck slot on an Astro project with no dedicated script. The first failing check stops the deploy before any request is made. --skip-checks skips all of them.

Configuration

// sedgemark.config.json: every key is optional; omitting "deploy" auto-detects everything.
{
  "baseUrl": "https://acme.sedgemark.app",
  "deploy": {
    "build": "astro build",
    "outputDir": "dist",
    "checks": ["lint", "typecheck", "test"],
    "notFoundHandling": "single-page-application"
  }
}

Build command and output directory are auto-detected: your package.json’s build script, and dist/ for an Astro project, unless overridden by --dir or the config file. notFoundHandling controls what a request matching no uploaded file gets back: "404-page" (default, serves your own 404.html), "single-page-application" (serves index.html for everything unmatched: what a client-side router needs, or every deep link 404s), or "none" (Cloudflare’s bare 404).

Deployments, rollback and deletion

npx sedgemark deploy      [--skip-checks] [--dir <path>] [--base-url <url>]
npx sedgemark deployments [--base-url <url>]
npx sedgemark rollback    [--to <deployment-id>] [--base-url <url>]
npx sedgemark delete-site [--yes] [--base-url <url>]

Uploads are incremental: every file is content-addressed, so a redeploy with one changed file uploads exactly that file. sedgemark rollback uploads nothing at all: the bytes for any previous deployment are already on Cloudflare, so restoring one is a single publish call, instant either way.

sedgemark delete-site permanently removes the live URL, the underlying Cloudflare Worker and route, and every deployment’s history: there is nothing to redeploy from afterward, since deployments store content hashes, not bytes. It needs --yes to actually run; without it, it prints exactly what would be destroyed and exits, since there is no terminal to prompt an unattended agent on.

In the dashboard

Settings → Sites shows your site’s live URL, deployment history, and lets you roll back or delete from the UI as well as the CLI. There is no MCP tool for any of this: deploying needs a build already sitting on disk, which an MCP tool call cannot supply, so this is CLI-only by design.

Plan and permissions

One site per workspace today. Free excludes sites entirely; Pro and Business each cover one. sites:read/sites:write are their own permission grants, separate from everything else: an owner grants them like any other resource.

A downgrade does not take a live site offline: it is served from Cloudflare’s edge, not from a Sedgemark request path, so a site your plan no longer covers keeps serving: only new deploys, rollbacks and finalizes refuse until you upgrade again. That is the opposite of how a locked collection or form behaves, and it is deliberate: Sedgemark genuinely cannot pull a live Cloudflare Worker offline without an extra step, and there is no reason it should if it could.