Builder14 min read€5 guide

Ship a full-stack app on Cloudflare with Claude Code

Use our own kickoff pack to take an Astro, D1, R2, KV and Workflows app from an empty folder to production, one /goal at a time.

This site runs entirely on Cloudflare, and Claude Code built it from a folder of plain text files. This guide hands you that folder, generalized, and walks through why each file is there. It is for builders who can read TypeScript and want a repeatable way to go from idea to a deployed Workers app without babysitting every step.

What you will have at the end

  • A kickoff pack in your repo: CLAUDE.md, SPEC.md, PLAN.md, REVIEW.md, a starter D1 schema and two wrangler.jsonc files with full staging blocks.
  • A .claude/ folder with permissions, two hooks, three skills and five agents that keep Claude honest about "done".
  • Phase prompts that each run under /goal until a check you can read in the transcript passes.
  • A web Worker (Astro) and a jobs Worker (Workflows) wired together, with D1, R2, KV, Email Sending and rate limits, on staging first.
  • A deploy routine with migrations, a secrets check, a live tail and a rollback command.

Before you start

  • Claude Code, updated with claude update (CLI reference).
  • A Cloudflare account, with your domain on Cloudflare DNS. Email Sending requires it: "You must be using Cloudflare DNS to use Email Service." (Email Sending)
  • Node and npm, plus jq for the test filter hook.
  • The attached kickoff-pack folder. Search it for YOUR_ and you will find every placeholder: app name, domains, account id, resource ids, sender address.
  • About 20 minutes of dashboard work: onboarding the sending domain, creating a Turnstile widget, and getting API keys for whatever your app calls. Keep secrets out of chat; you will set them with Wrangler later.

Step 1: write the memory, the spec and the plan before any code

Copy the pack into an empty repo, including the hidden .claude/ folder, then open three files in this order.

kickoff-pack/
  CLAUDE.md          project memory, read every session
  SPEC.md            what you are building
  PLAN.md            phases, each with a /goal prompt
  REVIEW.md          what counts as a real bug
  db/schema.sql
  apps/web/wrangler.jsonc
  apps/web/public/.assetsignore
  apps/jobs/wrangler.jsonc
  .claude/settings.json, hooks/, skills/, agents/

CLAUDE.md is short on purpose. Claude Code loads it into every session, and the docs suggest a target "under 200 lines per CLAUDE.md file" because longer files cost context and get followed less (memory). Ours has five parts: one paragraph on the product, the stack, the exact commands, rules that are not defaults, and gotchas. Notice what is missing: style advice Claude already follows, and anything it can read from package.json. If you are starting a different stack, /init drafts a starter file you can trim (commands).

The commands block matters most. The best-practices page puts it plainly: "the single most useful line in your CLAUDE.md is the command that runs it", meaning the check that proves the work (best practices). Every later phase leans on npm run check, npm test and npm run e2e existing and meaning one thing.

SPEC.md is the contract. Fill all ten sections before phase 0, even roughly. The pages table has a Render column for a reason. The Cloudflare adapter server-renders every page by default, and you opt single pages out with export const prerender = true (Astro on Workers). A prerendered page is built once, ahead of time, so in our build any page that reads D1, KV or R2 stays server-rendered and the rest are prerendered. Section 5 lists your Workflows and their named steps. Section 6 holds prices and quotas as placeholders; the rule in CLAUDE.md keeps real numbers in one shared file so Claude never invents a second copy. Section 10, out of scope, saves more tokens than any setting: Claude will not build what you told it not to.

PLAN.md turns the spec into phases. Each phase gets a branch, a short list of numbered steps, and a done-check you can verify from command output. We will run them in step 6. For now, read phase 0 and replace the placeholders it uses.

If you stop here, you already have something useful: a spec and a memory file that make any coding session, with any tool, faster and less wrong.

Next

Read next