DevCell

DevCell is a self-hosted developer cloud that turns a NixOS appliance into secure, persistent workspaces for humans and coding agents. Point it at a repository, launch its Dev Container inside an isolated cell, open it directly in Cursor, and carry the same environment through testing, checkpoints, forks, previews, and deployment.

Inspiration

Modern coding agents are becoming dramatically more capable, but the infrastructure around them is still fragmented.

A developer may have a local editor, a remote VM, Dev Containers, CI runners, deployment scripts, secrets, preview environments, and several AI coding tools all managed remotely. Cloud sandbox products solve parts of this problem, but they usually require moving development into a vendor-owned platform. Traditional homelab and private-cloud tools provide infrastructure, but they are not designed around repositories, coding agents, or the daily developer loop. Devcontainers are the primary abstraction we build upon because their simplicity inspired the workflow.

We wanted the best parts of both worlds:

• the simplicity and polish of modern cloud development environments;
• the ownership and privacy of self-hosted infrastructure;
• the reproducibility of NixOS and Dev Containers;
• the isolation of microVMs;
• and a native Mac experience that feels like opening a local project.

The result is DevCell: a private developer cloud centered on the repository rather than the virtual machine.

What it does

DevCell turns a trusted NixOS appliance into a control plane for durable development environments called cells.

A developer can:

1. Pair the native macOS app with a DevCell appliance.
2. Choose a repository or a known Dev Container fixture.
3. Review the resolved environment and requested resources.
4. Create and start a persistent development cell.
5. Open the workspace in Cursor, VS Code, or a terminal.
6. Run project services and coding agents inside the same environment.
7. Inspect lifecycle events, services, ports, and logs from the Mac app.
8. Create checkpoints and fork a workspace for experiments.
9. Build an immutable application artifact.
10. Deploy that artifact to an external target such as Akash.

For the hackathon prototype, I focused on the smallest complete version of that loop:

Mac app
  → pair with NixOS appliance
  → create a cell from a Dev Container
  → start the workspace
  → open it in Cursor
  → run and preview the application
  → checkpoint or fork it
  → deploy the resulting application

DevCell is designed so the same model can later span homelab servers, workstations, VPSs, Kubernetes clusters, cloud providers, CI runners, and specialized worker nodes.

How we built it

DevCell is built as several deliberately separated layers:

Native macOS client

The SwiftUI app is the developer-facing control surface. It connects directly to the appliance over a generated Connect client and supports:

• appliance discovery and connection;
• TLS fingerprint verification;
• pairing and Keychain-backed credentials;
• cell creation and lifecycle controls;
• operation and event timelines;
• service, port, and log inspection;
• checkpoints and forks;
• terminal and IDE attachment flows.

The Mac app remains a client rather than becoming a second control plane. Security policy, secrets, lifecycle, and infrastructure authority stay on the appliance.

Go control plane

The trusted daemon, celld, is written in Go and exposes a protobuf API over Connect.

It manages:

• cells;
• durable operations and operation steps;
• lifecycle events;
• host identity and client pairing;
• snapshots and forks;
• terminal and port sessions;
• capability requests;
• backend reconciliation;
• audit history.

Long-running actions are represented as operations so the CLI and Mac app can display meaningful progress instead of a single spinner.

NixOS appliance

The appliance is defined declaratively with NixOS and built as a QCOW2 image for Proxmox and other KVM environments.

Nix manages:

• the operating system;
• celld and cell-agent packages;
• persistent storage layout;
• Tailscale;
• Docker and Firecracker dependencies;
• service hardening;
• image reproducibility;
• upgrades and rollback.

A small import script handles the lab-specific Proxmox setup without turning the prototype into a full Terraform project.

Cell runtime

DevCell supports an honest reduced-isolation container backend for rapid development and testing. The production architecture uses Firecracker microVMs, each running a small trusted guest system called CellOS.

Inside each cell:

CellOS
  → cell-agent
  → project Dev Container
  → source code, services, terminals, and coding agents

cell-agent exposes structured guest operations for workspace initialization, services, ports, command execution, checkpoint preparation, and resume behavior.

The repository's devcontainer.json remains the primary workspace contract. DevCell parses it to build an inspectable execution plan, then uses Dev Container tooling to run the actual environment.

Private networking and deployment

Tailscale provides the private connection between the Mac and appliance.

For deployment, DevCell separates the mutable development workspace from the application artifact:

development cell
  → build OCI image
  → push immutable digest
  → deploy to Akash

Akash serves as the first external deployment target and demonstrates how DevCell can extend beyond infrastructure physically owned by the user without changing the local development workflow.

As a stretch direction, Zero can provide paid external capabilities to a tightly scoped support job. A cell could request a service, receive an explicit spending limit, and attach the resulting artifact or receipt to its operation history without exposing a general-purpose wallet to repository code.

Challenges we ran into

Nested virtualization

Our primary development machine is a Mac, where nested virtualization limits the ability to run the complete Firecracker stack locally.

We worked around this by developing three paths in parallel:

• a reduced-isolation container backend for local vertical-slice testing;
• an OrbStack-based CellOS lab;
• and a real nested-KVM environment on Proxmox.

We validated Firecracker on a nested virtualization probe with repeated boot and teardown cycles, TAP networking, vsock configuration, multiple concurrent microVMs, and leak checks.

Building the right abstraction around Firecracker

Firecracker is only the virtual machine monitor. It does not provide a workspace control plane, storage lineage, IDE sessions, guest APIs, deployment workflows, or a native client.

A major design challenge was deciding which responsibilities belong to:

• celld;
• the NixOS appliance;
• the runtime backend;
• CellOS;
• cell-agent;
• the Dev Container;
• and the Mac app.

Keeping those trust and lifecycle boundaries explicit prevented the prototype from becoming a collection of privileged shell scripts.

Honest snapshot semantics

A filesystem copy, a stopped-container checkpoint, and a Firecracker memory snapshot are not equivalent.

We deliberately model reduced capabilities rather than claiming every backend provides identical isolation or snapshot guarantees. The current container backend labels itself as shared-kernel and uses services-stopped filesystem checkpoints. Memory snapshots and true suspend-to-disk remain part of the Firecracker path.

Making remote development feel local

The infrastructure can be correct while the product still feels clumsy.

The most important UX challenge is making this loop feel immediate:

choose repository
  → create cell
  → wait for meaningful readiness stages
  → open directly in Cursor

That requires coordinating appliance identity, temporary sessions, SSH routing, workspace paths, editor deep links, port discovery, and automatic resume behavior.

Scope

The long-term vision includes worker nodes, CI runners, Kubernetes, cloud providers, automation, staging environments, and deployment approvals.

The hackathon constraint forced us to separate the architectural destination from the demonstration. We chose to prove one polished repository-to-workspace loop rather than building several disconnected infrastructure features.

Accomplishments that we're proud of

• We built a real typed control plane rather than a demo-only wrapper around shell commands.
• The Go API, CLI, generated Swift client, and SwiftUI application share one protobuf contract.
• The Mac app supports pairing, certificate fingerprint trust, Keychain-backed credentials, lifecycle actions, events, logs, snapshots, and forks.
• We created a reproducible NixOS appliance image with a persistent disk layout and CI-built QCOW2 artifact.
• We validated nested KVM and Firecracker on our Proxmox lab with repeated clean boot and teardown tests.
• We built a working guest-control layer through cell-agent.
• DevCell can parse real Dev Container configurations into an inspectable workspace plan.
• The reduced-isolation backend can initialize a workspace, run a container, execute commands, expose ports, checkpoint its filesystem state, and restore it.
• The architecture clearly separates repository-controlled code from appliance authority.
• The design remains compatible with existing editors and coding agents instead of requiring a proprietary agent harness.

Most importantly, the project already demonstrates the outline of a coherent product rather than an isolated infrastructure experiment.

What we learned

The sandbox is not the product

The microVM is important, but the actual product is everything surrounding it:

• lifecycle;
• persistence;
• identity;
• sessions;
• routing;
• secrets;
• checkpoints;
• observability;
• native editor attachment;
• deployment continuity.

Firecracker provides the isolation primitive. DevCell provides the developer experience.

Dev Containers are the right workspace boundary

Repositories should continue to own their development dependencies through a portable standard. DevCell should manage the trusted machine, policy, services, storage, and lifecycle around that workspace rather than replacing devcontainer.json with another proprietary format.

Coding agents should remain replaceable clients

Cursor, Codex, Claude Code, and future tools are evolving too quickly for DevCell to become another agent harness.

The more durable abstraction is the environment:

• the agent runs near the repository;
• DevCell keeps the environment alive;
• DevCell controls credentials and infrastructure;
• and the user can switch between human and agent workflows without rebuilding the workspace.

The native client matters

A web dashboard alone would miss much of the opportunity.

The Mac can serve as:

• the editor and terminal launcher;
• the trusted approval device;
• the secure credential endpoint;
• the notification surface;
• and the human control plane for remote infrastructure.

Broad architecture still needs a narrow first loop

The maximalist vision is useful because it keeps today's interfaces extensible. But the first product only becomes compelling when one workflow is excellent.

For DevCell, that workflow is:

Point it at a repository, create a secure persistent workspace, and open it in Cursor.

What's next for DevCell

Complete the golden loop

The immediate priority is making the complete fixture flow work through the real appliance:

pair
  → create
  → start Dev Container
  → open in Cursor
  → preview service
  → checkpoint
  → fork
  → deploy
  → destroy cleanly

Finish the Firecracker product backend

The nested-KVM feasibility work is complete. The next implementation work includes:

• real Firecracker process launch;
• jailer integration;
• TAP and vsock lifecycle;
• bootable CellOS kernel, initrd, and root filesystem;
• orphan reconciliation;
• writable disk strategy;
• memory and differential snapshots;
• warm golden-image restore.

Add Akash as the first deployment target

Akash will demonstrate that a developer can build inside a private DevCell and deploy the resulting artifact to external compute without provisioning another permanent server.

Explore Zero-powered support jobs

A future support cell could request a paid external service through Zero under a strict budget, while DevCell records the request, cost, receipt, and resulting artifact.

Build DevCell Nodes

The current prototype uses one appliance. The next major platform layer is a lightweight NixOS worker distribution that can contribute:

• Firecracker capacity;
• CI runners;
• Nix and container builders;
• caches;
• storage;
• Podman or Compose hosting;
• Kubernetes capacity;
• QEMU virtual machines;
• GPU workloads.

Grow into a private developer fabric

Over time, one appliance will be able to coordinate the resources a developer already controls:

Mac
  → home server
  → workstation
  → VPS
  → Proxmox
  → Kubernetes
  → cloud deployment targets

The long-term goal is simple:

Turn all the compute you control into one private platform for building, testing, deploying, and operating software.

Built With

• a-swiftui-macos-client
• an-astro/starlight-docs-site
• and-guest-agent)-with-protobuf-+-connectrpc-for-the-api
• astro
• cli
• firecracker/kvm-for-microvm-isolation-on-the-linux-host
• go
• nix
• nix/nixos-for-the-toolchain-and-appliance-images
• sqlite
• sqlite-for-state
• swift
• swiftui
• tailscale