What you get

Choose backend features, configure them, deploy your own backend.

A menu of backend modules, not a blank database. Supabase hands you general-purpose primitives — Postgres, auth, storage, a SQL editor — and the product is yours to assemble. A Cratefield module is the other end of that trade: an opinionated workflow whose routes, data model, admin export and abuse controls are already decided, and which you switch on. Both columns, with sources.

Confirmed email signups Shipping

A visitor submits an address, gets a signed confirmation link, and is confirmed only when they follow it: double opt-in, so a confirmed list means the mail arrived. The join endpoint answers the same bytes whatever the row state, so it never reveals whether an address is already on it. The confirmed list is a CSV export behind the harness admin token. email-signup, 0.3.0 on crates.io.

Referral waitlists Shipping

A queue per product, an email confirmation, a dense position assigned inside one atomic batch so two simultaneous confirmations never share a place, referral codes that credit a confirmed referrer, and a CSV export of the whole list behind that same token. Its join endpoint gives nothing away either. waitlist, 0.3.0 on crates.io.

Both take their mail through the Mailer port — adapter-resend is one implementation — and accept Captcha and RateLimiter as optional ports. adapter-turnstile is the Captcha, and it fails closed.

Two ways to end up with a backend

Configure what exists, or write the module yourself.

Managed setup — no Rust Planned

The intended path: pick supported modules from a hosted console, fill in their settings, deploy, and get a backend with a database of its own. No such console is running today. The control plane behind it is unbuilt, and the dashboard screens are written but have nowhere to run. What the managed service would cover. Everything below this describes the other path.

Author your own module — Rust Shipping

Implement the Module trait, write forward-only migrations in the portable SQL subset, run the conformance kit, and compose the module into a backend at compile time. That is what ships. A supported module is a cargo add, or an fz add for the short registry the CLI carries; your own is written the same way and linked the same way. How composition works.

Before you pick

Plugin-like setup, compiled deployment.

A module is not installed into a running process.

Changing the module set regenerates Cargo.toml and harness.rs and deploys a new backend, with a build log. Today each new module set is compiled to wasm, which takes seconds (measured); a build artifact keyed on the module set — so that a deploy of a set already built would upload it instead of compiling — is Designed (#59), not yet built. There is no instant activation, and this page does not draw one.

One Worker and one database, per backend.

Each backend is one Worker with one D1 database of its own, which is where the isolation comes from: no shared tables, and no cross-tenant policy to get wrong. Modules can also reach outside it — a mailer, a captcha — and those providers carry their own accounts and their own invoices; the Cloudflare usage is billed by Cloudflare. None of it is a Cratefield bill, because there is nothing to buy. How the boundary works.

Not in this baseline: the sidecar programme is Designed in epic #56 — the mount exists, the deployment model for a module you did not build does not — and a Durable Object behind the Realtime port is Designed and unbuilt (#103).

The double opt-in, the signed links, the identical responses and the admin routes behind the harness admin token: those are properties of the modules we support, not of the platform. Code you write yourself is not sandboxed and is not automatically secure. It is compiled into your Worker and runs there with the same bindings and the same access as everything else you deployed, so it is yours to read and yours to review before you ship it.

/modules/ · 76 crates

A module is a crate that runs on anyone's Harness.

Every module, adapter, runtime and tool in the harness, with its status and the line that adds it. 65 are on crates.io; 11 are in the repository only, and say so.

Shippingin the repo Designedpublic issues, unbuilt crates.iopublished Git dependencyin the repo, not published yet

Featured

Four that show what a module is for.

waitlist

Module · Growth

Per-product waitlists with confirmation, queue position, referral codes and admin export.

cratefield-module-waitlist

Shippingcrates.io 0.4.4updated 19 Oct 2026

fz add waitlist

auth-passkeys

Module · Auth

WebAuthn registration and login, verified in pure Rust. A passkey cannot be removed when it is the account's only way in.

cratefield-auth-passkeys

ShippingGit dependency

cargo add cratefield-auth-passkeys --git https://github.com/Cratefield/harness

notifications

Module · Messaging

Device and browser subscriptions, per-category preferences, and a fan-out other modules call.

cratefield-module-notifications

Shippingcrates.io 0.3.3updated 19 Oct 2026

fz add notifications

secrets

Library · Security

Envelope encryption over the Database port, in two tiers. A copied, renamed or rolled-back row fails to decrypt rather than quietly succeeding.

cratefield-secrets

Shippingcrates.io 0.4.2updated 19 Oct 2026

cargo add cratefield-secrets

Works with

Every mark here belongs to an adapter or a runtime further up this page, built against that vendor’s own API. The marks are the vendors’, used to say who, and imply nothing else.

Platform

The core, the runtimes and the tools every venture starts from.

cratefield

Library · Platform

The facade: one dependency that pulls in the core, a runtime, adapters and modules by feature, at versions known to agree.

cratefield

Shippingcrates.io 0.2.2updated 19 Oct 2026

cargo add cratefield

cratefield-core

Library · Platform

The kernel: the Module trait, the Harness builder, the ports, problem+json errors.

cratefield-core

Shippingcrates.io 0.10.1updated 19 Oct 2026

cargo add cratefield-core

runtime-cloudflare

Runtime · Platform

Cloudflare Workers. D1, KV, rate limiting, R2 and wait_until mapped to ports.

cratefield-runtime-cloudflare

Shippingcrates.io 0.5.0updated 19 Oct 2026

cargo add cratefield-runtime-cloudflare

runtime-native

Runtime · Platform

The same harness as one tokio binary: axum on a TcpListener, Redis ports, in-process cron.

cratefield-runtime-native

Shippingcrates.io 0.4.4updated 19 Oct 2026

cargo add cratefield-runtime-native

runtime-browser

Runtime · Platform

The harness in the browser: wasm, with SQLite over OPFS as the database.

cratefield-runtime-browser

ShippingGit dependency

cargo add cratefield-runtime-browser --git https://github.com/Cratefield/harness

fz

Tool · Platform

CLI: migrations collect and apply, doctor, modules, data export and import. It links against your venture's own harness.

cratefield-cli

Shippingcrates.io 0.7.2updated 19 Oct 2026

cargo add cratefield-cli

testing

Tool · Platform

The shared test suite every module must pass; run it in your own crate. Fake ports, an in-memory database, no network.

cratefield-testing

Shippingcrates.io 0.5.3updated 19 Oct 2026

cargo add cratefield-testing

cratefield-ui

Library · Platform

Renders every module's declared surface: forms and admin pages at /ui, a 4 KB embed for static sites, styling by plain CSS.

cratefield-ui

Shippingcrates.io 0.4.2updated 19 Oct 2026

cargo add cratefield-ui

manifest

Library · Platform

The venture manifest, and the deterministic composition generator it drives.

cratefield-manifest

Shippingcrates.io 0.3.2updated 19 Oct 2026

cargo add cratefield-manifest

i18n

Library · Platform

Server-side localisation: Fluent catalogs, BCP 47 negotiation and text direction.

cratefield-i18n

Shippingcrates.io 0.2.0

cargo add cratefield-i18n

client-ts

Tool · Platform

Generates a typed TypeScript client from a venture's /__surface contract.

cratefield-client-ts

Shippingcrates.io 0.4.3updated 19 Oct 2026

cargo add cratefield-client-ts

mcp

Tool · Platform

A Model Context Protocol server over fz --json: the CLI's own JSON, nothing of its own to drift.

cratefield-mcp

ShippingGit dependency

cargo add cratefield-mcp --git https://github.com/Cratefield/harness

adapter-cloudflare-saas

Adapter · Platform

CustomHostnames over the Cloudflare for SaaS custom-hostnames API.

Databases, declared tables and content.

tables

Library · Data

A schema a venture declares in its manifest, and the artifacts derived from that one declaration.

cratefield-tables

Shippingcrates.io 0.4.2updated 19 Oct 2026

cargo add cratefield-tables

cms

Module · Data

A small content store with an editor: typed collections, versioned, in the venture's own database. Public reads, admin-token writes.

cratefield-module-cms

Shippingcrates.io 0.3.2updated 19 Oct 2026

fz add cms

adapter-sqlite

Adapter · Data

Database over rusqlite. Every test, and single-node self-hosting.

cratefield-adapter-sqlite

Shippingcrates.io 0.3.2updated 19 Oct 2026

cargo add cratefield-adapter-sqlite

adapter-postgres

Adapter · Data

Database over sqlx Postgres, for the native runtime. Refuses to compile to wasm.

cratefield-adapter-postgres

Shippingcrates.io 0.3.3updated 19 Oct 2026

cargo add cratefield-adapter-postgres

adapter-sqlite-wasm

Adapter · Data

Database over SQLite compiled to wasm, persisted in the browser's OPFS.

cratefield-adapter-sqlite-wasm

ShippingGit dependency

cargo add cratefield-adapter-sqlite-wasm --git https://github.com/Cratefield/harness

introspect

Library · Data

Reads a live database's own catalog over the Database port, in the tables vocabulary.

cratefield-introspect

Shippingcrates.io 0.3.2updated 19 Oct 2026

cargo add cratefield-introspect

tables-api

Library · Data

Who may reach which rows of a declared table. The routes that will serve them are not built yet.

cratefield-tables-api

Designedcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-tables-api

import-supabase

Tool · Data

Step one of a Supabase move: inspect the project read-only and produce the migration report, classifying every object.

cratefield-import-supabase

Shippingcrates.io 0.2.2updated 19 Oct 2026

cratefield-module-owlpost

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-module-owlpost

mail-templates

Library · Messaging

Branded, email-client-safe HTML and a plain-text twin for every message, themed with the venture’s own colours and logo.

cratefield-mail-templates

Shippingcrates.io 0.1.3updated 19 Oct 2026

cargo add cratefield-mail-templates

Growth

Sign-ups, waitlists, releases and usage counts.

waitlist

Module · Growth

Per-product waitlists with confirmation, queue position, referral codes and admin export.

cratefield-module-waitlist

Shippingcrates.io 0.4.4updated 19 Oct 2026

fz add waitlist

The records a venture runs on: people, companies, and the teams they belong to.

module-crm

Module · Business

Contacts, organisations and the tags that label them, with an idempotent upsert API other modules can call.

cratefield-module-crm

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-module-crm

module-orgs

Module · Business

Organizations, memberships, roles and email invitations: a person creates an organization and invites people by address.

cratefield-module-orgs

Shippingcrates.io 0.1.3updated 19 Oct 2026

cargo add cratefield-module-orgs

Payments

Taking money without card data crossing a port.

adapter-stripe

Adapter · Payments

Payments over the Stripe REST API, with HMAC webhook verification and no card data across the port.

cratefield-adapter-stripe

Shippingcrates.io 0.3.4updated 19 Oct 2026

cargo add cratefield-adapter-stripe

adapter-polar

Adapter · Payments

Payments over Polar, a Merchant of Record: Polar sells, collects VAT and sales tax worldwide, and pays you out, so a venture without a company can sell from day one.

cratefield-adapter-polar

Shippingcrates.io 0.2.3updated 19 Oct 2026

cargo add cratefield-adapter-polar

Wallets

Wallets, keys and signing: linking an address, and every guardrail between a request and a signature.

adapter-turnkey

Adapter · Wallets

The KeySigner port over Turnkey: a sub-organization per end user, and our backend only a delegated user inside it.

cratefield-adapter-turnkey

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-adapter-turnkey

signer

Library · Wallets

Key-reference signing: a venture names a key, never touches raw key material, and every sign call passes the guardrails first.

cratefield-signer

Shippingcrates.io 0.1.1updated 19 Oct 2026

cargo add cratefield-signer

session-grants

Library · Wallets

Scoped, capped, expiring, revocable automation keys for Kernel accounts, EIP-7702, Swig roles and Squads vaults.

cratefield-session-grants

ShippingGit dependency

cargo add cratefield-session-grants --git https://github.com/Cratefield/harness

module-guardrails

Module · Wallets

The policy engine every automated value-moving action must pass: hard denies, caps, a kill switch, and an append-only audit chain.

cratefield-module-guardrails

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-module-guardrails

module-wallets

Module · Wallets

Link a person’s own EVM or Solana wallet to an account they have already signed in to, by signature rather than by password.

cratefield-module-wallets

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-module-wallets

AI

cratefield-module-connections

Shippingcrates.io 0.2.3updated 19 Oct 2026

cargo add cratefield-module-connections

adapter-github-issues

Adapter · Integrations

Tracker over the GitHub Issues REST API.

cratefield-adapter-github-issues

Shippingcrates.io 0.3.3updated 19 Oct 2026

cargo add cratefield-adapter-github-issues

adapter-jira

Adapter · Integrations

Tracker over the Jira Cloud REST API v3.

cratefield-adapter-jira

Shippingcrates.io 0.2.3updated 19 Oct 2026

cargo add cratefield-adapter-jira

adapter-webhook-tracker

Adapter · Integrations

Tracker over a webhook the tenant configures, signed with HMAC-SHA256.

cratefield-adapter-webhook-tracker

Shippingcrates.io 0.3.2updated 19 Oct 2026

cargo add cratefield-adapter-webhook-tracker

adapter-github-app

Library · Integrations

GitHub App auth: RS256 app JWTs, cached installation tokens and the user-to-server code exchange.

cratefield-adapter-github-app

Shippingcrates.io 0.2.2updated 19 Oct 2026

cargo add cratefield-adapter-github-app

Module · Integrations

Runs a LinkedIn Company Page from the harness: connect once over OAuth, then create, schedule, edit and delete posts, upload media, and address showcase pages. Private, never published.

fz-module-linkedin

ShippingPrivate

Not offered for install

adapter-linear

Adapter · Integrations

Tracker and StatusWebhook over the Linear GraphQL API.

cratefield-adapter-linear

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-adapter-linear

adapter-colonizer

Adapter · Integrations

An HTTP client for the Colonizer mothership: colonies, questions and whoami, over the runtime’s HttpClient port.

cratefield-adapter-colonizer

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-adapter-colonizer

Security

Secrets, keys, privacy and abuse checks.

secrets

Library · Security

Envelope encryption over the Database port, in two tiers. A copied, renamed or rolled-back row fails to decrypt rather than quietly succeeding.

cratefield-secrets

Shippingcrates.io 0.4.2updated 19 Oct 2026

cargo add cratefield-secrets

kms

Library · Security

Wrap a data key, unwrap a data key. That is the whole trait. The development provider refuses to construct in production.

cratefield-kms

Shippingcrates.io 0.2.0

cargo add cratefield-kms

privacy

Module · Security

What this deployment holds about a person, and everything it holds about one.

cratefield-module-privacy

Shippingcrates.io 0.3.3updated 19 Oct 2026

fz add privacy

adapter-turnstile

Adapter · Security

Captcha over Cloudflare Turnstile, fail-closed.

cratefield-adapter-turnstile

Shippingcrates.io 0.3.3updated 19 Oct 2026

cargo add cratefield-adapter-turnstile

module-sealed

Module · Security

The server half of sealed blobs: opaque ciphertext at rest, crypto-shred erasure, and no server-side recovery path.

cratefield-module-sealed

Shippingcrates.io 0.1.2updated 19 Oct 2026

cargo add cratefield-module-sealed

Nothing matches. Try a port, such as Mailer or Push, or a provider, such as stripe.

Writing one

Implement the trait. Pass the kit.

The conformance kit runs every module against the same contract: problem+json errors, rate-limit headers, request-id propagation, concurrent-request safety, migration idempotency. A module that passes on SQLite runs unchanged on D1.

01Add the harness to Cargo.toml. cargo add cratefield, or depend on cratefield-core directly if you want only the trait.
02Implement Module. name(), version(), requires(), migrations(), validate_config(), router(). Ask for ports by name; never import an adapter.
03Write migrations in the portable SQL subset. Forward-only, include_str!, numbered. The kit checks idempotency.
04Declare a surface, or don't. surface() names the actions a renderer may offer, and their input schemas come from the handler's own body types, so the forms cannot drift from the routes. A module that declares nothing renders nothing.
05Run the conformance kit. Concurrent requests, problem+json, rate-limit headers, request-id propagation, migration idempotency, against SQLite and Postgres both.
06Add it to a composition and build for wasm32. If it pulls tokio, mio or std::fs, the build fails. That is the point.

Two mounts Shipping

Your module. Your Worker. Your source.

A module can be mounted two ways, and the caller cannot tell which. Compiled in is the default: the crate is linked into the worker alongside every other module. Sidecar is the other: the module is its own worker, compiled on its own, reached over a service binding and mounted at the same /v1/<name> path. Both workers live in the same account, which in the default mode is yours. The platform runs them on the same thread of the same server, so the hop costs no measurable latency and nothing extra to run.

The reason it matters is not performance. A sidecar is built and deployed by whoever owns it, which means a module you will not share can run inside your backend without the source ever reaching us. It binds the same database as everything else, so it is a real module with real ports, not a webhook. It is not meant to get the same secrets either: a module we did not build should never hold the key that signs the rest of your backend’s links, so it would be provisioned its own. The secrets layer that makes that possible is Shipping; wiring a sidecar to its own store is part of the sidecar programme, still Designed.

The mount itself is merged: ADR 0009, the Dispatcher port, and a sidecar's surface folded into the same /__surface the compiled-in modules answer with. What is still Designed is the programme around it: the build-artifact cache, the cold-start handshake, a module template you build yourself, conformance parity across both mounts, and the deployment model for customer-supplied modules. Those are epic #56, issues #59 and #61 to #67.

Want a module we have not built yet? Tell us what you are running today.

Join the waitlist Read the source