Skip to content

Hosting the sales site on Cloudflare

The sales site is built with MkDocs Material and deployed to Cloudflare as a Worker serving static assets (Workers Builds + wrangler deploy) — the exact same setup as the engineering docs.snowops.net. Cloudflare clones this repo, builds it, and serves dist/.

Why a Worker and not Pages? Cloudflare's current "connect a Git repo" flow creates a Worker, not a Pages project. That's fine — a Worker with an [assets] block and no script serves a static site directly. The only thing that was missing originally was the wrangler.toml telling wrangler deploy to serve dist/; without it, wrangler deploy ships a default Worker that returns Hello World!.

One-time Cloudflare dashboard setup

In your Worker → Settings → Build:

Setting Value
Build command bash build-docs.sh
Deploy command npx wrangler deploy
Root directory / (repo root)

The static-asset wiring lives in wrangler.toml ([assets] directory = "./dist"), and the Python version (3.12) is pinned by .python-version. After saving, trigger Deployments → Retry / Create deployment.

What the build does

build-docs.sh is the single build entrypoint (local and Cloudflare):

  1. Assembles docs/ — sales content lives in numbered top-level folders (01-business-context/, …) for browsing and the Google Drive mirror, so the script mirrors them into a throwaway docs/ tree (git-ignored) that MkDocs can build from. The folder names are preserved, so each page's "edit" pencil still resolves to its real source file.
  2. Installs mkdocs + mkdocs-material from requirements-docs.txt if not present.
  3. Runs mkdocs build --clean, emitting the static site to dist/.

wrangler deploy then uploads dist/ as the Worker's static assets.

🔒 Gate the site before it holds real content

Unlike the engineering docs, this site has pricing, positioning, and contract language — it must not be public. Put Cloudflare Access (Zero Trust) in front of the sales.snowops.net route:

  1. Cloudflare dashboard → Zero Trust → Access → Applications → Add an application → Self-hosted.
  2. Application domain: sales.snowops.net.
  3. Add a policy: Allow, with an Emails / Emails ending in rule listing who should get in (you, your wife, each salesperson).
  4. Save. The domain now prompts for a one-time email login before serving anything.

This is a dashboard-only step — it can't be scripted from the repo. Until it's in place, keep the custom domain unpublished or the content placeholder-only.

Local preview

bash build-docs.sh serve   # live-reload at http://127.0.0.1:8000
bash build-docs.sh         # one-off build into dist/

Editing a source file needs a re-run to re-assemble docs/.

Adding a teammate

  • To let someone read the site: add their email to the Cloudflare Access policy above. No GitHub account needed.
  • To let someone edit content: add them to the GitHub repo (a sales team with write access is the clean pattern as the team grows). They can then use the "edit this page" pencil on any page, which opens the real source file in GitHub's web editor.

Adding or moving a page

  1. Add/edit the markdown in the appropriate numbered folder at the repo root.
  2. Add it to the nav: in mkdocs.yml (folders use README.md as their section landing page).
  3. bash build-docs.sh serve to check it renders, then commit.

Prefer a real Pages project instead?

If you'd rather use Cloudflare Pages (explicit "Build output directory" field, no wrangler.toml): delete this Worker, then Workers & Pages → Create → Pages tab → Connect to Git, and set Build command bash build-docs.sh + Build output directory dist. Be sure to pick the Pages tab — the default flow creates a Worker.