the engineTHAT GROWSwith you

where does your softWare live when you're not loOking?

Almost everything you "own" digitally runs on a computer that isn't yours. Your notes, your photos, the app your business depends on — they live in someone's datacenter, and what you actually own is a login. That trade has real upsides, and for plenty of things it's fine. But notice what it does to software you build: your own creation lives somewhere you can't see, priced per request, on terms that change under you.

The agent era sharpened this from a philosophical itch into a bill. Agents need a computer to live on — a real one, with files and processes and time. The industry's answer has been to rent that computer in slices: a fresh micro virtual machine per agent, metered by the second. It's genuinely good technology, and at prototype scale it feels free. Then you scale, and the meter is the business model. People have resorted to parking Mac minis in closets just to give an agent somewhere permanent to exist — which tells you the demand is real, even when the answer is silly.

The missing piece isn't a cheaper rental. It's an engine you own.

the DEFINITION

"Nexus" because that's its job: the point where your workbooks, your data, your services, and your agents connect — and the one piece of the system that's a place rather than a file. A workbook is the thing you hand to anyone. The Nexus is the thing you plug it into.

what DOCKING actually means

On its own, a workbook is an artifact — complete, portable, and inert while it's closed (the workbook page ends on exactly this boundary). Dock it into a Nexus and three things switch on:

• Isolated — the workbook runs in its own sealed compartment. It can't reach the host machine, your keychain, or any other workbook; it gets exactly the capabilities you grant it and nothing else.
• Stateful — its database becomes live, persistent, and synced. The workbook keeps running while it's closed: schedules fire overnight, state survives restarts, the copy you serve stays current.
• Agentic — agents attached to the workbook get somewhere permanent to live and work: long-running, on schedules, with their files and memory in the workbook they're tending.

Same file before and after — nothing was converted, exported, or deployed in the traditional sense. The landing page draws this as a diagram: one workbook, docked, fanning out into any kind of app. This page is that picture in prose.

built on a BORING miracle

Here's the part most platforms bury in a footnote, told up front, because it's the best reason to trust the design. The Nexus is built on the BEAM — the virtual machine behind Erlang and Elixir — which is not new, not trendy, and not experimental. It was engineered by Ericsson to run telephone exchanges: millions of simultaneous calls, where every call had to be isolated from every other call, and the system was allowed to fail for roughly nothing. The famous figure is nine nines of uptime — 99.9999999% — about 31 milliseconds of downtime per year.

The design that achieves that is almost insultingly simple: everything is a tiny isolated process. A call is a process. A web request is a process. If one crashes, it takes nothing down with it — a supervisor notices and replaces it, mid-flight, while the rest of the exchange hums along. Forty years later, that same VM quietly carries a noticeable share of the world's messaging traffic.

The Nexus inherits the whole posture for free: every docked workbook, every agent, every request is one of those processes. A workbook crashing is a non-event — its process dies, its supervisor restarts it, no other tenant notices. This is also why one modest machine goes so far: the BEAM was built to hold millions of concurrent processes, so "thousands of workbooks and agents on one server" isn't a stretch goal — it's the VM's resting heart rate.

isolation, TWICE

depth rung · skippable — the mechanism behind the "isolated" light

BEAM processes isolate workbooks from each other. But a workbook also carries arbitrary code — its WebAssembly could have been written by anyone. That code runs inside a second wall: a WebAssembly sandbox (industry-standard, the same engine class browsers trust), where the code gets memory it can't escape and only the capabilities explicitly handed in. No ambient file system, no ambient network — grants, not inheritance.

So the nesting goes: machine → engine → process → sandbox. Code in a workbook would have to break out of two unrelated containment systems just to reach its neighbor, let alone your machine.

And one detail that says a lot about the philosophy: even the compilers live inside the sandbox. When the Nexus builds code — C, Rust, Zig, Go, JavaScript — the compiler itself has been compiled to WebAssembly and runs under the same containment as everything else. Build steps are a classic attack surface (an "install" script is just untrusted code you run with your own hands), and the Nexus simply refuses to have that surface: nothing untrusted ever executes natively on the host. Not even the toolchain.

"why not serverless? why not rent the vMs?"

Because of what agents and living software actually are.

Serverless functions are built for ephemeral work — a request comes in, a function spins up, answers, and evaporates. Nothing about an agent is ephemeral. An agent is a long-running thing with memory, files, schedules, and a chronology — the precise opposite of the serverless shape. You can duct-tape persistence onto function calls, and people do, but you're fighting the model, and the per-invocation meter is still running while you fight it. The pricing follows the shape: scale a serverless prototype into a real product and the bill scales with every single call.

Rented microVM sandboxes fix the shape problem — a real computer, properly isolated — but keep the meter. You're paying for isolation as a service, by the second, forever. Lovely for a demo; a trap to build a company on.

The Nexus's answer: isolation is software, not a subscription. The BEAM and the WebAssembly sandbox do what the rented VM was doing, on a machine you own — and the economics invert. One small server runs thousands of isolated workbooks and agents concurrently. When you outgrow it, you don't multiply line items; you grow the machine. That's how companies that operate at serious scale actually manage cost, and there's no reason a two-person team shouldn't get the same curve.

the SECURITY model, plainly

depth rung · skippable — unless you have a security review in your future

Start with why agent setups are scary. An agent running with operating system access is an open box: your keychain, your environment variables, your API keys, your files — anything a vulnerability or a bad instruction can reach, it can reach. And "bad instruction" is the part people underestimate: prompt injection means anyone whose text reaches your agent — a web page it reads, an email it summarizes — is partially steering it. Give that agent your data and an internet connection, and you've built an exfiltration machine and put a stranger near the wheel.

The Nexus's frame: never trust the workload; structure the world so it doesn't have to be trusted.

• Capabilities are granted, not inherited. A workbook starts with nothing — no network, no host files, no secrets. Each power is a specific, revocable grant, so the question "what could this thing do at worst?" has a short written answer.
• Secrets stay in the engine. Keys live with the Nexus; workbooks ask the engine to act, and the engine decides. Code in the sandbox never holds credentials, so there's nothing to leak.
• The blast radius is one process. Compromised or just broken, a workbook can trash exactly itself. The supervisor restarts it; its neighbors never know.

None of this requires you to do security engineering. It's what docking is — the same answer at two people and at ten thousand, which is exactly what a security review wants to hear.

dev is prod — one engine, every stAge

The classic software journey crosses three worlds: the thing on your laptop, the staging copy, and production — each with different infrastructure, different configs, different failure modes. Most "works on my machine" misery is those worlds disagreeing.

There is exactly one Nexus. The engine on your laptop and the engine in your cloud are the same engine — same image, same behavior — and a deployment is described by one declarative file. Where it runs is a value in that file: flip local to cloud and the prototype you built for yourself is the product your team runs. No translation layer, no re-platforming cliff, no "now make it real" rewrite.

Ownership compounds here too: multi-tenancy is built in, with organization-level isolation enforced by the engine. A team — or a whole company, or your customers — share one Nexus the way tenants share a building, each behind their own door.

what the NEXUS isn't

Honesty section.

It isn't serverless-with-extra-steps. It's a server — that's the point. You own a thing that runs; "nothing to operate" was the pitch that ends with the meter. What ownership costs you is knowing the thing exists; what it buys you is everything above.

It isn't a number-cruncher. The BEAM's genius is coordination — millions of small isolated things, none allowed to hurt the others — not raw math. Heavy computation belongs in the WebAssembly lane, in a language built for it. The Nexus is deliberately split-brained like that: the engine coordinates, the sandbox computes. Knowing which half does which is most of understanding the design.

It isn't required. Worth repeating from the workbook page: workbooks open in any browser, no engine in sight. The Nexus is for the living part — running, persisting, serving, agents. Viewing is free, forever, by design.