crofty 0.20.0 — sites with a worker deploy now

If one contact form was the reason your whole site went out through another tool, that reason is gone. crofty deploy now carries a _worker.js instead of stopping at it.

What used to happen

A project with a _worker.js at its root was refused. crofty deploys to Cloudflare Pages, and a static-only upload would have replaced whatever was answering those routes — so the form kept its URL and quietly stopped working.

$ crofty deploy
✗ this project has Pages Functions (_worker.js) — not deploying:

  crofty deploys static files only. Publishing would replace what is serving
  those routes now, so anything they answer — forms, redirects, APIs — stops
  working, silently.

  Deploy this site the way its Functions get deployed (wrangler / a Pages git
  build), or run 'crofty deploy --static-only' to drop them on purpose.

Nothing was deployed.

Now crofty deploy just runs. The root _worker.js goes up as part of the same Pages deployment as the static files, together with the root _routes.json if one is there.

Two limits, stated plainly. crofty handles a _worker.js that is self-contained — one module, no import, no require; anything pulling in other files would need bundling, and crofty does not bundle. And with SFTP or FTPS as the destination, nothing that answers requests can be placed there, so the deploy still stops.

You can see what crofty found without running a deploy:

$ crofty config --json
{
  …
  "pagesFunctions": [
    "_worker.js"
  ]
}

The runtime and the variables are yours to declare

Both live in .crofty/config.json. crofty supplies no default for either.

There is no default date because a default would follow crofty’s version: updating crofty would move the runtime your existing _worker.js executes on. Pin the date yourself and it changes when you change it.

A malformed date stops the deploy before the build and before the login.

$ crofty deploy
crofty: deploy.worker.compatibilityDate is "2026-7-20" — it has to be a date like 2026-07-20

requiredEnv holds names, never values. crofty asks the Pages project which variable names it has, warns about the ones missing, then deploys anyway. crofty never reads a value and has no path that sends one. A name written as NAME=value is rejected rather than trimmed — trimming would mean a secret had already been written into a file meant to be committed. Missing variables warn rather than stop: crofty did not unset them, and deploying and then filling them in is the only move left.

Also in this release

• A missing _routes.json now warns. Without one, every request runs the worker — static files included — and each is billed. crofty synthesizes no default; add one naming the routes the worker should answer.
• A content section named functions/ is no longer mistaken for Functions source. A site with a content section that happened to be called functions used to have it read as server-side source and left out of the published site. It is published as pages now, and the deploy says so.
• The update notice says what changed. It used to report only that a newer version existed. It now carries the release-notes URL, so you can decide whether to update.
• .pkg installs are pointed back at the .pkg. People who installed without opening a terminal were being told to run curl | sudo sh. The suggestion now matches how crofty was actually installed.

Getting it

Download crofty.pkg or crofty-setup.exe and double-click it. The OS will warn you once — the installers are unsigned, and getting started walks through it.

From a terminal:

curl -fsSL https://crofty.site/install.sh | sh                                          # macOS / Linux
irm https://github.com/ShiroDoromoto/crofty/releases/latest/download/install.ps1 | iex  # Windows