Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 30 Oct 2026. What's built · Install 0.1.0
jadpo
Reference: Records and manifest

Records and manifest

Production builds

A deployable carries a small build stamp, not its manifest. The stamp holds the build id, the commit, whether the tree was modified, the compiler version, the deployable and the target. Every log event carries it. Each fault site carries its .jadpo file and line as a constant, so events already show .jadpo frames (Errors point at the .jadpo line).

  • The manifest is rebuilt, not shipped. Builds are deterministic (Tooling), so jadpo incident builds the event's commit, checks that the build id matches, and caches the result. Nothing is uploaded or archived. jadpo fetches and runs the exact compiler version the stamp names, as rustup installs a pinned toolchain, so an old build can always be rebuilt.
  • No endpoint. The deployed app reveals nothing about its structure. This also works for a worker with no HTTP surface.
  • Native and Wasm alike. Nothing depends on debug information or unwinding: Rust Workers abort on panic with no stack, so the path comes from the runtime's own spans. On Workers the stamp is logged beside CF_VERSION_METADATA, so the platform's version and the Jadpo build can be joined.
  • Deploy only commits that stay in history, on the default branch or a tag. A build from a modified tree is marked as such, and can be explained only from that exact tree.

jadpo incident isn't built yet (What is built).

Markdown for agents: /docs/production-builds.md.Built from Jadpo main at a707efb.