Deploy MailySend to your own Cloudflare account

01What the deploy actually provisions

The deploy creates eight kinds of resource. All of them are in your account, billed to you, visible in your dashboard, and deletable by you.

Who actually creates them

Not the button, mostly. The Deploy to Cloudflare flow auto-creates the bindings it knows how to auto-create — KV, D1, R2 — and does not create queues at all. So build:cf ends by running scripts/ensure-resources.mjs, which creates the twelve queues, the R2 bucket, the D1 database and the two KV namespaces, then writes the generated D1 and KV ids into the config wrangler deploys.

It matches by name and creates only what is missing, so every build after the first is a no-op. That property is load-bearing rather than tidy: re-creating SUPPRESSIONS instead of reusing it would silently empty the one list that must never be lost. It also refuses to run outside CI — only inside Workers Builds (WORKERS_CI=1) or under MS_ENSURE_RESOURCES=1 — so building locally never creates resources in your account as a side effect of a build.

There is no id in the committed config. apps/app/wrangler.jsonc carries no database_id and no KV id, because a generated id cannot be committed and a literal placeholder is worse than omitting one — it passes JSON validation and then fails the deploy with KV namespace 'PLACEHOLDER' is not valid. Omitted, the resource gets created and its real id written in. If the build token cannot create something, the script leaves the id out rather than failing the build, which is exactly the shape wrangler’s own provisioning expects, so the deploy gets a second attempt at it.

At rest — nothing sending — this costs the Workers Paid floor and very little else. The cost guide prices it properly, including the point below which a vendor’s free tier is genuinely the cheaper answer.

02Run the deploy

Two paths to the same place.

$ git clone https://github.com/GagnDeep/mailysend
$ pnpm install
$ export CLOUDFLARE_ACCOUNT_ID=... CLOUDFLARE_API_TOKEN=...
$ npx mailysend provision
$ pnpm deploy:cf

$ curl https://your-worker.workers.dev/v1/health
{ "status": "operational",
  "mode": "single",
  "version": "…",
  "database": "ok",
  "time": "2026-09-11T09:14:02.118Z" }

The commands Workers Builds guesses

The other guess fails just as obliquely. Cloudflare then proposes a bare npx wrangler deploy from the repository root, where wrangler cannot tell which workspace package is the Worker and stops before doing anything. So build:cf ends by writing a root wrangler.json — a copy of the generated config with its path fields rewritten, regenerated on every build and gitignored, so bindings still have one source of truth.

03What happens on first boot

The first request to a fresh instance does four things, and one of them you have to be watching for.

The public URL is learned, not configured. Nothing pins it in wrangler.jsonc on purpose: a placeholder hostname there would mint every tracking pixel, unsubscribe link and canonical tag against a domain nobody owns. Instead the first non-local request’s origin is stored and reused, so a deployment first reached on workers.dev and later on a custom domain adopts the custom domain, and a localhost origin is never stored — which is what stops a development request poisoning a real deployment.

The signing secret is generated and kept. If MS_SECRET is unset, a 32-byte value is generated on first boot and written to the settings table under a conditional insert, so two isolates racing on a cold deployment adopt one value rather than overwriting each other’s. Setting it explicitly is still the better posture — it keeps the signing key out of the database and lets you rotate it — but it is not something to solve before you can deploy.

What every pre-auth screen reads. GET /v1/instance is unauthenticated and reports whether the instance is claimed, whether a claim code is required, whether the claim is reserved to an address, which sign-in doors are actually open, and whether any domain is verified. It carries no secrets and no per-address facts, which is the point: a door is only drawn on the page when it is open, and a button that answers 501 is worse than no button.

04What the deploy deliberately does not do

Four things the deploy deliberately leaves to you.

05If the deploy fails

Five failures account for nearly every deploy that does not come up, cheapest to check first.

When the deploy fails on queue consumers

✘ [ERROR] Trigger configuration for "…" was only partially updated:
    Queue consumers:
      - A request to the Cloudflare API (/accounts/…/queues) failed.
        - An unknown error has occurred [code: 10013]

The script uploaded; only the trigger update failed, and the build is reported as failed regardless. The message names neither the queue nor the reason — but the list of consumers wrangler prints immediately above it does: whichever declared queue is missing from that list is the one that failed. The two causes are rows two and three of the table above, a queue that was never created and a queue another Worker already consumes.

Common questions