bext-plugin-nsjail

Process-isolation sandbox for bext lifecycle plugins — JSON-over-stdio IPC with optional Linux namespace isolation.

Part of the bext stack.

[dependencies]
bext-plugin-nsjail = "0.2"

What this crate is

bext-plugin-nsjail runs plugins in a separate OS process, communicating via JSON-over-stdio. On Linux, it can optionally wrap the child process in nsjail for full namespace isolation (pid, net, mount, user).

Best fit for lifecycle plugins (build hooks, deploy hooks, scheduled tasks) where startup latency is less critical than the ability to run any code the plugin author ships — any language, any runtime, any FS access — without worrying about memory corruption of the host.

Why three plugin hosts?

bext ships WASM, QuickJS, and nsjail plugin hosts because each has a different cost/power trade-off:

• WASM: fastest startup (~1ms), strict memory safety, limited to what WASM can express.
• QuickJS: fast startup, full JavaScript, limited to what QuickJS can do (no native deps).
• nsjail: slowest startup (~50ms), but runs literally anything — Python, Go, Node, a shell script, a compiled binary.

License

MIT.

See also

• github.com/bext-stack/bext — the bext meta repo
• Full ecosystem — all bext crates at a glance