Neon Law | The crates we actually run on

The crates we actually run on

The bill of materials for a real legal-tech product — every line a crate you can pull today:

HTTP and views — axum, dioxus, tower / tower-http.
Async runtime — tokio, multi-threaded, with graceful shutdown.
Database transition — Postgres today; SurrealDB follows through the next store slices.
Durable execution — restate-sdk.
Telemetry — opentelemetry, tracing, OTLP.
Archive — arrow and parquet; a real Iceberg table lane is separately tracked.
Content — pulldown-cmark.
Cloud — google-cloud-storage + reqwest.
Identity — jsonwebtoken + oauth2.
Tests — fantoccini and cucumber, exercised through the workspace harness.

Presenter notes

So you can map this onto your own stack: for HTTP and views, axum for the router and handlers, dioxus for the browser surface, tower / tower-http for the middleware stack. The async runtime is tokio, multi-threaded, with signal handling for graceful shutdown. The database is Postgres today, with a SurrealDB store transition in progress. Durable execution is restate-sdk hosting every workflow on one worker endpoint, with the journal doing the remembering. Telemetry is opentelemetry and tracing, with OTLP as the export seam. The archive uses Arrow and Parquet. The real Iceberg-table and restore drill work is tracked separately, so the slide does not turn a plan into a fact. Content is rendered from the Markdown you read. Cloud is google-cloud-storage behind a storage trait, with reqwest for the REST plumbing that provisions a fresh project. Identity is jsonwebtoken and oauth2 for the OIDC flow. Tests use fantoccini to drive a real browser over WebDriver, and cucumber for the behavior specs you saw in Step 2. One workspace, one cargo test, one language from the HTTP handler down to the migration and back up to the browser assertion. None of these crates asked us to sign anything.

View all slides Open display