navaris-cli

Navaris

A sandbox control plane for managing isolated execution environments across multiple backends.

Why Navaris?

Running untrusted or experimental code safely requires strong isolation — but the tooling to manage that isolation is fragmented. Incus gives you system containers, Firecracker gives you microVMs, and each has its own API, lifecycle model, and operational quirks.

Navaris provides a single control plane that abstracts over these backends. You get a unified REST API and CLI for creating, snapshotting, and managing sandboxes regardless of whether they run as containers or microVMs. The same workflow that creates an Incus container also works for a Firecracker VM — same endpoints, same state machine, same tooling.

This matters when you need to:

• Offer on-demand dev environments where users shouldn't care about the underlying runtime
• Run untrusted code with microVM-level isolation without rewriting your orchestration layer
• Snapshot and restore execution state for reproducibility or checkpointing
• Mix isolation levels — containers for speed, microVMs for security — behind one API

Backends

Navaris supports two isolation backends. You can enable one or both when starting the daemon — the API and CLI work identically regardless of which backend is running underneath. When both are enabled, each sandbox is routed to the correct backend automatically.

Incus (system containers)

Incus runs sandboxes as system containers using LXC. Containers share the host kernel but get their own filesystem, process tree, and network namespace.

Strengths:

• Fast startup — containers launch in under a second
• Low overhead — no guest kernel, near-native CPU and memory performance
• Mature ecosystem — rich image library, live migration, storage pools, and clustering built in
• Simpler operations — no kernel or rootfs images to manage separately

Best for: development environments, CI runners, trusted workloads where speed and density matter more than hard isolation boundaries.

Firecracker (microVMs)

Firecracker runs sandboxes as lightweight virtual machines using KVM. Each sandbox gets its own guest kernel, providing hardware-level isolation.

Strengths:

• Strong isolation — separate kernel per sandbox; a guest kernel exploit doesn't compromise the host
• Minimal attack surface — Firecracker's VMM is purpose-built with a small device model (no PCI, no USB, no graphics)
• Predictable performance — dedicated vCPUs and memory with no kernel sharing; no noisy-neighbor effects from cgroup contention
• Jailer integration — each VM runs in a chroot with seccomp filters and a dedicated UID

Best for: running untrusted code, multi-tenant environments, security-sensitive workloads where isolation guarantees matter.

Choosing a backend

Consideration	Incus	Firecracker
Startup time	~1s	~2-3s
Memory overhead	Minimal	~30MB per VM (guest kernel)
Isolation level	Namespace/cgroup	Hardware (KVM)
Host kernel shared	Yes	No
Requires /dev/kvm	No	Yes
Image management	Built-in image server	Manual rootfs + kernel
Live snapshots	Native support	Memory + disk snapshot
Density (sandboxes per host)	Higher	Lower

You can run both backends in a single Navaris instance — containers for speed, microVMs for security — behind one API. Backend selection happens automatically based on image format, or you can specify it explicitly per sandbox.

Features