Open source AI infrastructure · secure harness

Your private AI operations center and agent harness.

Build a secure, reproducible harness for agents, local models and AI-enabled applications. Every sandbox receives only its approved developer tools, MCP capabilities, project data and network paths. Route outbound traffic through a governed gateway and standard forward proxy, then see which destinations each sandbox attempts to reach, what is allowed or blocked, and why. When explicitly authorized, transparent proxy observation can expose otherwise direct traffic too — always visible, scoped and reversible.

Create your appliance Explore the platform ↓

Policy-first harness
Local models on your hardware
One clear control surface

PRODUCT FILM · INTRODUCTION

Gateway active

3 isolated workloads

BUILT FOR A SAFE AGENT HARNESS

From the first agent experiment to a governed AI environment.

OpenShell sits at the core of the Nestbox design: a safe runtime developed by NVIDIA for controlled AI-agent execution. Nestbox surrounds it with a purpose-built control plane, policy, mounts, models, tools and observability.

OpenShellNemoClawOpenClawOpenCodeOpenChamberClaude CodeCodex / ChatGPT workflowsGemini CLIGoogle Antigravity workflowsHermesAiderCline AgentKilo CodeContinueVS Code workflowsCursor workflowsYour runtime

Runtime and workflow examples are shown for the planned compatibility surface. Direct support depends on the selected sandbox template, agent pack and provider/API configuration.

Built at Dev Community Day Berlin.

PROJECT ORIGIN

Nestbox began during the Dev Community Day Hackathon in Berlin on 25 October 2026. The early project concept and website were accelerated with OpenAI credits. Thank you to OpenAI. Additional thanks to NVIDIA and Nous for a 20 US dollar free-credit voucher shared at the RTX Launch Event Berlin, which supported early experimentation and evaluation. The first project concept, product-language drafts and this website were developed with assistance from GPT-5.6 Terra; the project direction and final decisions remain the responsibility of the maintainer.

Buy me a Red Bull 🪽 LinkedIn profile ↗

LOCAL AI · NVIDIA ECOSYSTEM CONTEXT

Designed for the emerging local AI stack.

Nestbox is being designed for NVIDIA DGX Spark-class systems, the GB10 Grace Blackwell platform and other local GPU workstations where large unified memory makes private model evaluation and agent workflows practical. The goal is not to replace NVIDIA cloud resources, NIM microservices, NeMo tooling or AI Enterprise workflows — it is to offer an open-source, self-hosted control plane around the workloads you choose to run.

Nemotron local models

Validated NVIDIA Nemotron profiles can be delivered as independently managed model sandboxes, with lifecycle state, health checks, logs and controlled consumers.

OpenShell and agent safety

OpenShell provides the safe execution foundation in the design. Nestbox adds mount grants, policy assignments, isolated sandboxes and egress observability around AI-enabled workloads.

Cloud or local, one workflow

Begin with NVIDIA cloud resources, a provider-neutral VM or local GPU hardware. Keep the same policy-first deployment model as workloads move closer to your own infrastructure.

NVIDIA, DGX Spark, GB10 Grace Blackwell, NIM, NeMo, OpenShell, NemoClaw and Nemotron are trademarks or product names of NVIDIA Corporation. Nestbox is an independent open-source project and is not affiliated with or endorsed by NVIDIA.

FUTURE DIRECTION · FROM HOME LAB TO TEAMS

Start small. Earn the right to scale.

I am building Nestbox in the open and have early foundations in place. The next milestone is repeatable validation: make the core workflows reliable, run the first tests, learn from real feedback and announce a wider testing opportunity only when the project is ready for useful evaluation.

If the project proves useful and earns sustained adoption, the direction could expand from one home-lab host or single VM into a centrally managed fleet: multiple VMs, gateways, sandboxes and local-model runtimes operated from one Control Center.

Follow the development on GitHub ↗

Now

Validate the core

Single-host recipes, sandbox concepts, policy and observability foundations.

Next

Invite testing

Announce evaluation only after repeatable core tests are ready.

Maybe later

Scale the control plane

Explore multi-VM, multi-gateway and Kubernetes-compatible operation if demand justifies it.

PLANNED V1 · EXISTING GPU ENVIRONMENTS

Bring your CUDA-X-ready hardware into the sandbox workflow.

Many teams already operate NVIDIA GPUs in a private datacenter, lab or cloud environment. Nestbox is planned to make that existing investment easier to use for controlled agent workloads: select a GPU-capable sandbox template and prepare the runtime configuration required by your approved CUDA-X software stack.

That can include CUDA runtime compatibility, GPU device access, container image selection and workload-specific configuration for tools such as CUDA-X libraries, NIM microservices, TensorRT-LLM, RAPIDS or other approved components already present in your environment.

What is NVIDIA CUDA-X? ↗

Nestbox will not replace NVIDIA software, drivers, licensing or vendor support. The goal is to make approved local or cloud GPU capabilities easier to attach to a governed sandbox, with explicit policy and observability around the workload.

Existing GPU hardware prepares an isolated sandbox for an approved CUDA-X software environment — Existing GPU estate → prepared sandbox runtime → governed workload

ONE PLATFORM · CLEAR BOUNDARIES

Every responsibility in its own lane.

React Admin provides the local control experience. FastAPI exposes a versioned control API. A gateway governs routes. OpenShell mediates execution. Every agent, model or OCI workload runs in its own sandbox.

See what each boundary protects →

Separate containers for web console, API, gateway, OpenShell and sandbox workloads — Control plane → gateway → runtime → isolated workload

THE CAPABILITY LAYER

One system. Many controlled ways to build.

01 / 06

LOCAL MODELS

Choose a model. Deploy a governed runtime.

Select a validated Nemotron profile, deploy a dedicated model sandbox, then start, stop, inspect health and read logs from one place. Agent access is routed through approved policy paths — never direct host access.

Dedicated model cache and lifecycle
Validated local GPU profiles
Approved consumers and gateway routing

A local AI model selected from a console and deployed to an isolated model runtime

AGENT WORKSPACES

Start with a harness. Keep every capability explicit.

A harness gives an agent runtime the developer tools, MCP capabilities, project scope and reusable policy it needs. Templates provide a secure starting point, not blanket host access.

Development, research and custom templates
Git, approved GitHub access and project CLIs
Governed MCP tools per sandbox

An isolated agent workspace receiving approved tools through a policy gateway

PROJECT MOUNTS

Attach a project where it belongs — then remove it.

Projects are capabilities, not background assumptions. Attach a volume read-only or read-write, detach it instantly, or reassign it to a different sandbox with an audit trail.

Read-only and read-write grants
No implicit shared filesystem
Unmounted means inaccessible

customer-portalproject volume

Read/write → Coding sandbox

Read-only → Research sandbox

No mount → No access

POLICY + EGRESS

See every route before it becomes a risk.

Create reusable policies for mounts, tools, DNS, TLS, proxy routing and destinations. The planned gateway can surface live egress decisions and forward redacted structured events to syslog.

Validate, version, diff and roll back
Allow/block decisions per sandbox
Optional observation path; TLS inspection off by default

A sandbox request passes through policy gateway while secrets remain isolated

PROTECTED OCI APPS

Bring an image. Put governance in front of it.

Connect Docker Hub, private OCI registries or your approved image source. Deploy application images to isolated sandboxes and place OpenShell and gateway policy in the path for AI-capable workloads or controlled egress.

Public and private registry references
Secret references, never image-embedded credentials
One lifecycle and policy surface

A secure gateway routes traffic to isolated application sandboxes

IMAGE BUILDER

Configure once. Boot into a ready environment.

Generate inspectable Ubuntu seed bundles for bare metal, Proxmox, a cloud VM, WSL or local GPU hardware. Network, DNS, NTP, trusted CA and proxy settings can be preseeded; secrets are always added after first boot.

Cloud-init and autoinstall preview
Static IP or DHCP, CA and proxy support
Future remote ISO jobs and artifact history

Deployment targets for a bootable Nestbox appliance

PLANNED · LIVE TRAFFIC CONSOLE

See sandbox traffic before opening the firewall editor.

The planned Admin Center starts with a firewall-style timeline for each sandbox: incoming and outgoing protocol events, source, destination, port, policy decision and correlation ID. Select a suspicious event to draft a block rule, review the diff and apply it explicitly.

Default deny is available too. For a strongly isolated sandbox, start with all network traffic blocked and allowlist only the exact hosts, protocols, ports and tools that the workload needs.

Live firewall traffic console selects a suspicious sandbox connection and creates a block rule — Event → rule draft → review → explicit apply

Appliance DNS service logs sandbox queries, blocks blacklisted domains and applies DNS allowlists — Appliance DNS · blacklist and allowlist policy

PLANNED · DNS CONTROL

Give the appliance a DNS service — and make every lookup accountable.

Nestbox will provide an appliance DNS service for managed sandboxes. The Admin Center records queries with the sandbox, name, resolver and decision. Blacklist a hostname or domain when it does not belong; for a hardened sandbox, block all DNS by default and allowlist only required names.

Per-sandbox DNS query timeline and audit trail
Blacklist a hostname or domain for one sandbox or policy
Default-deny DNS with explicit allowlists for tightly isolated workloads

Every DNS policy change is versioned, reviewable and reversible. A blocked name means that sandbox cannot resolve it in the future until policy permits it again.

PLANNED · RULE FROM EVENT

See a suspicious connection. Draft a block rule from it.

In the Live Traffic Console, an operator will be able to select an unusual DNS query or network connection and create a prefilled policy-rule draft. The draft is scoped to the selected sandbox or policy, reviewed in the editor, then explicitly applied — never silently enforced from a click.

Connection event → prefilled destination, protocol and port
DNS event → prefilled hostname/domain block rule
Review, diff and approve before the future connection is blocked

RULE DRAFT

sandbox: research-01destination: telemetry.example.netprotocol: DNSaction: block

Review diffApply policy

Explicit operator approval required

PLANNED · EGRESS MODES

Choose how deeply each sandbox is observed.

Network visibility is a deliberate policy decision, not a hidden default. Operators choose a standard proxy path or explicitly enable transparent proxy observation for a narrowly scoped sandbox.

DefaultForward proxyTransparent inspection off

DEFAULT MODE

Governed forward proxy

Approved outbound traffic follows the gateway and proxy path. Operators can see incoming and outgoing protocol events, source, destination, port, policy decision, route, status and latency without enabling TLS decryption.

Visible egress decisions per sandbox
Allow, block and audit events
Safe starting point for every deployment

EXPLICIT OPT-IN

Transparent proxy observation

For a sandbox that needs deeper network observability, an operator can explicitly enable transparent interception. The planned Control Center issues a sandbox-scoped trust CA and injects it only when the operator approves this mode.

Observe traffic that would otherwise bypass a proxy
Review destination and permitted request metadata
Turn off, revoke the trust CA and return to forward-proxy mode

Privacy and control by design: transparent TLS inspection is disabled by default, must be visibly enabled per policy, and is intended only for workloads and environments where the operator is authorized to inspect that traffic. The Control Center will show the active mode, assigned trust CA and audit history for every affected sandbox.

THE GOVERNED PATH

Sandbox → OpenShell → Gateway → policy decision.

01Isolated sandbox

02OpenShell runtime

03Gateway + policy

04Approved destination

Secrets are not embedded in images or ordinary sandbox files. The planned control plane manages scoped delivery, mount grants and visible policy decisions after first boot.

Nestbox configured for a local workstation, virtual machine, cloud or GPU appliance — Deploy to the hardware you already control

DEPLOY ANYWHERE

Build an appliance for the place your compute lives.

Start with a local seed bundle today. Configure hostname, networking, DNS, NTP, trusted CA and proxy behavior. Later, choose a signed ISO build, Brev launch, cloud VM, Proxmox or local workstation target from the same flow.

Bare metalProxmoxCloud VMWSLLocal GPU

WORKING NOW · LOCAL GENERATOR

Turn intent into an inspectable seed bundle.

Render a lightweight recipe locally in your browser. It never asks for an API key, and the generated artifact contains no credentials.