Dormant Infrastructure: Adding Container Runtime Abstraction Before We Need It

There's a pattern in software engineering that doesn't get talked about enough: building infrastructure that does nothing today but prevents a painful refactor later. We just did this in sh0, and the methodology behind it is worth documenting.

The Problem We Don't Have Yet

sh0 currently runs all containers with Docker's default runtime: runc. Namespaces, cgroups, the standard Linux container isolation. This works perfectly for self-hosted deployments where you trust the code you're deploying.

But we're building towards sh0 Cloud — multi-tenant, where strangers deploy code onto shared servers. Suddenly runc isn't enough:

• sh0 Debug lets users run arbitrary code. A kernel exploit = host access.
• sh0 Cloud means container escape = other customers' data.

The solutions exist: gVisor (user-space kernel, ~10-30% I/O overhead) and Kata Containers (micro-VMs, ~150ms startup penalty). Docker supports both through a single Runtime field in its API.

The Decision: Build the Abstraction Now

A spec came in suggesting we implement full container runtime support — pre-flight checks, CLI flags, dashboard UI, runtime availability detection. The kind of spec an AI writes when it doesn't know the codebase.

We stripped it down to the minimum viable abstraction:

rust#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize, Default)]
#[serde(rename_all = "snake_case")]
pub enum ContainerRuntime {
    #[default]
    Runc,
    Gvisor,
    KataQemu,
    KataFirecracker,
}

An enum, a database column, a field on the Docker API request. That's it. No pre-flight checks (nothing to check — only runc is installed). No CLI flag (the API is sufficient). No dashboard UI (admin can set via API when the time comes).

What "Dormant" Means Precisely

Every app defaults to Runc. The HostConfigRequest.runtime field is Option<String> with skip_serializing_if = "Option::is_none". For runc, it's None — the field doesn't appear in the Docker API request at all. Docker uses its default. Behavior is byte-for-byte identical to before.

The only way to activate this is to PATCH /api/v1/apps/:id with {"container_runtime": "gvisor"}. At which point Docker will try to use runsc and fail (because it's not installed). Which is the correct failure mode — Docker tells you the runtime doesn't exist.

The Audit Caught Something

We follow a build-audit-audit-approve methodology. The first auditor (fresh Claude session, zero context from the build session) found that 6 out of 8 deploy paths hardcoded container_runtime: None instead of reading from the app's setting:

• Docker image deploy
• Dockerfile content deploy
• Upload deploy
• Rollback deploy
• Scale-up replicas
• Preview environment deploy

Only the 2 git-deploy paths (primary + replica) correctly used the app's runtime.

Current impact: zero — all apps are runc, so None and reading-from-app produce the same result. But if we'd activated gVisor 6 months from now, 6 deploy paths would have silently ignored the setting. Users would set gvisor, deploy via upload, and get runc. The kind of bug that's invisible until production.

The auditor fixed all 6 sites. The second auditor confirmed the fixes. Clean.

The Cost

• 20 files touched — mostly mechanical (adding container_runtime: Default::default() to App struct initializers, container_runtime: None to Sh0ContainerParams call sites)
• 1 migration — ALTER TABLE apps ADD COLUMN container_runtime TEXT NOT NULL DEFAULT 'runc'
• ~60 lines of actual logic — the enum, Display/FromStr, 2 match patterns in the deploy pipeline
• Build time: about 2 hours including both audit rounds
• Runtime cost: zero (the field doesn't serialize for runc)

What Activation Looks Like

When we install gVisor on a server:

bash# On the sh0 server
apt install runsc

# In the sh0 API
PATCH /api/v1/apps/:id {"container_runtime": "gvisor"}

# Next deploy uses runsc automatically

No code changes. No migrations. No new releases. The infrastructure is already there.

The Pattern

The decision framework is simple:

1. Is the abstraction cheap? (Yes — an enum and a database column)
2. Is the integration point clear? (Yes — Docker's Runtime field in HostConfig)
3. Does it change current behavior? (No — None = Docker default = runc)
4. Would retrofitting be painful? (Yes — touching every deploy path, migration, API type, handler)

If all four: build it now, activate later. The audit methodology catches the integration bugs you'd otherwise discover 6 months from now in production.