Overview
Until now, every new architecture, cloud provider or contract meant another migration project. The compute grid treats work as grains: idempotent function applications that can be dispatched to any machine in a mixed-trust fleet, re-executed safely, and verified by replication when the executor is not yours. Modernize once, move anytime is a property of the code, not a promise on a slide.
One workload, any target.
- x86, ARM, RISC-V, GPU targets and WebAssembly at the edge, from one source
- Modernize once, move anytime is a property of the code
- Every new architecture used to mean a re-code. Not anymore
$ bnl deploy --target fargate ✔ live 00:41 $ bnl deploy --target wasm-edge ✔ live 00:12 $ bnl deploy --target core ✔ live 00:23
One module, one shard, any machine.
- A grain is an idempotent function application: one content-addressed module over one content-addressed input shard
- Dispatched to any machine in a mixed-trust fleet, re-executed safely, verified by replication when the executor is not trusted
- Jobs are the unit of submission, billing and cancellation
Your machines join with consent, and leave cleanly.
- Each node is backed by its own service account and lives in a trust pool
- Leases are time-boxed claims; expiry is the entire failure-recovery story
- Agents verify module digests before running a byte; keys rotate; drains are graceful
Born in shadow. Promoted one step at a time.
- A pin starts in shadow and moves up a guarded ladder, one step at a time
- Approval bound to the exact bytes that were tested
- Rollback rehearsed before the first byte moves, and triggered by the monitor on breach
Faster, without touching the tenant's code.
- A translated kernel lives in-process as a Python extension; the worker calls it like a function
- The original still answers if the kernel declines: fallback is the design, not the incident
- Serving telemetry feeds the outcome monitor and the forecast
Signed from key ceremony to self-update.
- Hybrid key ceremony offline; release tooling never ships in images
- Agents verify update manifests before applying them
- Usage metered per org and pool, in a statement you can read
$ bnl deploy --target fargate ✔ live 00:41 $ bnl deploy --target wasm-edge ✔ live 00:12 $ bnl deploy --target core ✔ live 00:23
BEFORE YOU START
Before you start
Does the application change?
No. The kernel lives beside the original process and the workload moves without touching the application.
Who approves a rollout?
Your team. Every rollout references the tested build's digest and the recorded approval.
What if a target underperforms?
The outcome monitor flags or rolls back, and the evidence travels with the workload, so the next placement is as cheap as the last.
What's next
Start with the 48-hour assessment or bring one workload. We agree the scope in the first conversation.