Berry Wiki

InstaVM NixOS Sandboxes

Properties2
tagsai, hosted
aliasesInstavm Nixos Sandboxes

7 min read

InstaVM NixOS Sandboxes

Summary

InstaVM’s nix-dev environment is a hosted NixOS sandbox for agents and developers. It runs inside a Firecracker microVM, supports Nix flakes, can be snapshotted, and can create fresh copies of a pinned development environment through the InstaVM command line or Python software-development kit.

  • Product: InstaVM nix-dev
  • Article published: 2026-06-26
  • CLI support: Stated as available from v0.24.0
  • Checked: 2026-07-14

Problem

Normal sandbox images drift as packages and base images change. An agent may install tools successfully today but fail to reproduce the same environment later. NixOS describes the operating system and packages as code, while snapshots preserve a working machine state.

How It Works

  • Hosted microVM: Each sandbox gets a Firecracker VM with its own kernel, filesystem, memory, CPU allocation, and network stack.
  • NixOS guest: image_variant="nix-dev" selects a guest with Nix and flake support.
  • Declarative environment: A flake.nix describes packages; flake.lock pins exact sources and hashes.
  • Mutable work remains possible: Users can add packages with nix profile during a session.
  • Snapshot: InstaVM flattens the writable ext4 layer into a reusable snapshot.
  • Clone: New microVMs can boot from that snapshot with installed packages preserved.
  • Access: Commands run through the API, CLI, interactive shell, or pseudo-terminal.

Security Boundary

The primary boundary is a Firecracker hardware-assisted microVM with a separate Linux kernel. Root inside the guest is not intended to grant host access, and sandboxes do not share filesystems or memory.

Network egress is documented as deny-by-default and configurable by package-manager access, HTTP/HTTPS, domains, or address ranges. This is stronger host separation than a normal shared-kernel container.

Limits:

  • Firecracker and the host orchestrator remain trusted computing components.
  • Uploaded code, injected values, mounted volumes, and allowed destinations are exposed to guest code.
  • The public service requires trusting InstaVM with compute, stored snapshots, volumes, logs, and account metadata.
  • No independent microVM security audit specific to the NixOS variant was found.

Platforms And Agents

  • Guest: NixOS Linux on Firecracker.
  • Control clients: Python SDK and instavm CLI; the general platform also documents JavaScript support.
  • Host location: InstaVM’s hosted cloud. The public CodeRunner project offers a local-development path, but the checked NixOS article describes the hosted service.
  • Agent model: Agent-agnostic code execution. InstaVM documentation names Claude Code, Codex, GitHub Copilot, OpenAI Agents SDK, LangChain, and LlamaIndex workflows.
  • Direct agent bundle: The NixOS article does not say that coding-agent CLIs are preinstalled; users define or install their own tools.

Setup

  1. Create an InstaVM account and API key.
  2. Install the Python package, which provides the SDK and CLI.
  3. Store the key interactively or supply INSTAVM_API_KEY to automation.
  4. Create a VM with the nix-dev image variant.
  5. Define packages in a flake or add them to a Nix profile.
  6. Create a named snapshot, list snapshots, and boot new VMs from the snapshot identifier.

Fresh command-execution shells may not include ~/.nix-profile/bin in PATH. The article says callers must add it when using profile-installed tools. Flake commands also require Nix experimental features to be enabled explicitly.

Network And Credentials

  • Account authentication: One API key controls CLI, SDK, and HTTP API access.
  • Current key scope: Official authentication docs say all API keys currently have full account access; scoped keys are planned.
  • Storage: Interactive CLI login stores the key under ~/.instavm/config.json; automation can use an environment variable or secret manager.
  • Egress: Free includes known package managers and common AI APIs. Pro adds unrestricted access or granular domain/address allow-lists.
  • Secrets: General InstaVM materials describe environment injection and proxy-based vault substitution so selected provider keys need not appear inside the VM. The NixOS article does not demonstrate that flow specifically.
  • Risk: Any secret placed directly into the guest environment can be read by guest code.

Pricing

Official pricing checked 2026-07-14:

  • Free: 50 starting credit.
  • Pro: $100 monthly base plus usage, 100 concurrent VMs, granular egress controls, higher limits, advanced monitoring, and a 99.9% uptime target.
  • Enterprise: Custom pricing, capacity, policy, support, contracts, and stated SOC 2 Type II compliance.
  • Compute: 0.05 per vCPU-hour; 0.02 per GB-hour.
  • Extra allocated volume storage: $0.0002 per GB-hour after the included 10 GB.
  • Idle: Pricing page says there are no idle compute charges.

The pricing page contains inconsistent promotional text: most sections state 100. Confirm the dashboard offer before relying on either amount.

Strengths

  • Reproducible OS: Nix flakes pin the whole toolchain rather than only application packages.
  • Strong isolation: A separate kernel reduces host exposure compared with containers or process sandboxes.
  • Fast lifecycle: Official docs claim sub-200 ms general sandbox starts; the NixOS article says about one second for nix-dev.
  • Snapshots and cloning: Teams can bake a known environment and create identical working copies.
  • Rollback-friendly: Nix and snapshots provide two ways to return to known state.
  • Agent-agnostic API: Agents can use it as remote execution infrastructure without a provider-specific harness.
  • Network controls: Per-VM egress policies reduce unnecessary outbound access.

Limits

  • Hosted dependency: Workloads and environment state run on InstaVM infrastructure unless using a separate local CodeRunner path.
  • Nix learning curve: Flakes, locks, profiles, and NixOS differ from standard package-manager workflows.
  • Early feature: The NixOS variant was announced less than three weeks before this check.
  • API key blast radius: Keys are account-wide today.
  • Pricing complexity: Compute, memory, storage, subscription, and network features vary by plan.
  • Reproducibility boundary: A snapshot can preserve mutable state that is not declared in the flake; exact reproducibility still requires disciplined definitions and locked inputs.
  • Marketing evidence: Startup, isolation, uptime, and compliance claims are vendor-provided and were not independently tested here.

Activity And Maturity

Checked 2026-07-14:

  • NixOS article: Published 2026-06-26.
  • CLI milestone: Article cites v0.24.0 for direct nix-dev creation and snapshots.
  • Public local runtime: instavm/coderunner was created 2025-06-23, had 869 stars and 40 forks, and its latest checked commit was 948095ee8240 from 2026-05-16.
  • CodeRunner releases: No GitHub releases or tags were published at check time.
  • Service maturity: Pricing, documentation, SDKs, authentication, network policy, snapshots, and service targets exist. The hosted control-plane implementation and NixOS image build are not fully public.
  • Assessment: Operating commercial sandbox platform with a newly released NixOS option; production evidence for this variant is limited.

Best Fit

Best for teams that already value Nix, need reproducible remote agent environments, want to clone known-good machines, and prefer a managed Firecracker service over operating VM infrastructure.

It is a weaker fit for local-only source restrictions, teams avoiding hosted compute, simple one-off scripts, or users unwilling to adopt Nix and usage-based billing.

Comparison

  • Versus standard InstaVM sandbox: Same microVM service and controls, but NixOS replaces a mutable prebuilt root filesystem with a declarative, pinned operating system.
  • Versus Clawk: InstaVM is hosted and API-oriented; Clawk is local-first and mounts the developer’s worktree into a disposable VM.
  • Versus Nix microVM tools: InstaVM manages hosting, warm capacity, API access, snapshots, and billing. Self-hosted Nix tools provide more infrastructure control.
  • Versus container sandboxes: Firecracker supplies a separate kernel; containers are usually lighter but share the host kernel.
  • Versus cloud dev environments: nix-dev emphasizes agent execution, snapshots, and reproducible OS definitions rather than an integrated browser IDE.

HN Context

An InstaVM representative replied to a Nix microVM project in the Clawk thread. They said InstaVM had launched NixOS-based sandboxes, mainly as a cloud product, and highlighted scale, secret injection, suspend/resume, snapshots, cloning, and sub-second warm-pool starts. They also said a future Tarit runtime could reduce startup time further.

The parent commenter asked for the product’s advantage over their self-built Nix sandbox. The answer was primarily managed scale and cloud operations, not a fundamentally different Nix environment model.

Unknowns

  • Nix image source: The complete build definition and patch history for nix-dev were not found publicly.
  • Snapshot sharing controls: Team permissions, encryption, retention, and deletion guarantees for snapshots were not established by the article.
  • Secret proxy coverage: Exact support for Nix package fetches and arbitrary agent APIs is unclear.
  • Audit: No independent security audit specific to nix-dev was found.
  • Warm-pool isolation: Implementation details behind warm starts and tenant cleanup are proprietary or undocumented.
  • Tarit: The HN reply described a future replacement; it is not evidence of current nix-dev behavior.

Sources

Graph View