Sandbox Base Images: Pick From Three Tiers

title: "Sandbox Base Images: Pick From Three Tiers" slug: "agent-sandbox-base-images-distroless-slim-dev" meta_title: "Sandbox Base Images: Pick Your Tier" meta_description: "Sandbox base images set cold start, attack surface and debuggability in one choice. Three tiers, distroless, slim and dev-full, and when each wins." primary_keyword: sandbox base images author: Krova Cloud Engineering date: 2026-10-26 schema: BlogPosting+FAQPage category: AI Code Sandboxing secondary_keywords: distroless images, debian slim, dev container images, sandbox image tiers, cold start image size excerpt: "One line in your Dockerfile sets your sandbox cold start, attack surface and debuggability for every session after. Three image tiers, and when each wins."

Sandbox Base Images: Pick From Three Tiers

Sandbox base images are a lifecycle decision hiding in a FROM line. The image you choose sets cold-start seconds, the package surface an attacker can reach, and whether a human can debug the session at all. Teams usually pick one image for everything and then live with the compromise forever. The better pattern is three tiers, each assigned to a workload class, with promotion rules between them.

The three tiers

Distroless images, per the GoogleContainerTools project, ship only the application and its runtime dependencies: no shell, no package manager, no busybox leftovers. Slim images, like the official debian slim variants documented in Docker's best-practices guidance, keep a minimal shell and package tooling while dropping docs and caches. Dev-full images add compilers, debuggers, editors and language toolchains, essentially a workstation root filesystem.

What each tier buys and costs

Distroless buys the smallest pull, the fastest restore and the smallest reachable surface, because there is no shell to spawn. It costs you exec-based debugging entirely: when a session misbehaves, you inspect from outside, via logs and metrics, or not at all.

Slim buys a survivable debugging story and apt-based fixes mid-session, at the cost of a package manager an exploit can reach. Dev-full buys agent freedom: installing a missing toolchain mid-task is often the difference between a completed task and a failed one, and it costs the largest image, the slowest cold start and the widest surface.

Assign tiers by workload, not by taste

1. Production execution of known code: distroless. The workload is fixed, so the image can be too.
2. CI jobs and evals with pinned toolchains: slim, plus cached dependency layers.
3. Interactive agent sessions and devboxes: dev-full, because the point is unanticipated tooling.

We checked the distroless README on 26 October and its promise is unchanged: minimal contents, no shell, no package manager. The repository itself carries 2,716 commits of maintenance, and rough compressed sizes on Docker Hub put debian bookworm slim near 30 MB against roughly 350 MB for a dev-full node image, a tenfold pull difference on every cold start. That is exactly the property you want under untrusted execution and exactly the property that makes an interactive session miserable. The tiers are not a maturity ladder; they are different tools.

The mistake is treating these as a maturity ladder to climb once. They are three tools with different failure modes, and a team that picks one image for everything inherits that tool's worst day in every single workload class at once.

The cold-start and caching mechanics

Image size lands directly on first-boot latency, as we break down in microVM cold start: every megabyte is pulled or restored before your init runs. Layer order matters more than layer count: put stable runtime layers first and volatile dependency layers last, so cache hits cover the bulk. Snapshotting a warmed dev-full image, the pattern from CI isolation choices, converts most of the dev-full tax into a storage cost. Portable image workflows, like the one in our exportable infrastructure guide, keep the three tiers reproducible across regions.

Promotion rules that stop tier drift

A session that starts dev-full and finishes with a pinned toolchain should graduate: freeze its installed packages into a slim derivative for CI, then into distroless for production execution. Conversely, a distroless job that needs mid-run installs is mis-tiered and belongs in slim. Review tier assignments quarterly, because dependency graphs drift faster than anyone remembers. The same review cadence appears in our self-service devbox tutorial, where labels make the tiers auditable.

Verdict

We recommend three tiers with explicit promotion rules, and stop arguing about one universal image. Distroless for fixed workloads, slim for pinned pipelines, dev-full for human and agent exploration: each tier is correct exactly where its tradeoffs match the workload.

Limitations

• Image size and pull-time figures are directional; however, registry proximity and cache warmth dominate in practice.
• Distroless debugging workflows assume you ship logs and metrics out of the sandbox, but not every stack does.
• Slim variants differ between distributions; debian slim is not alpine, and musl surprises cannot be ignored.
• We run our own demos on slim and dev-full tiers; our distroless notes come from docs and the project README.

FAQ

Is alpine a fourth tier?

It behaves like slim on size but swaps glibc for musl, which breaks some prebuilt wheels and binaries; test before adopting.

Can agents install packages into a distroless sandbox?

Not inside the session. The pattern is to let the agent propose packages in a dev-full session, then bake them into the next image build.

Does a smaller image improve isolation?

Indirectly: fewer packages mean fewer vulnerable binaries reachable at runtime, but the boundary itself comes from the sandbox technology, not the image.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "Sandbox Base Images: Pick From Three Tiers",
      "datePublished": "2026-10-26",
      "dateModified": "2026-10-26",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/agent-sandbox-base-images-distroless-slim-dev"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Is alpine a fourth tier?",
          "acceptedAnswer": {"@type": "Answer", "text": "It behaves like slim on size but swaps glibc for musl, which breaks some prebuilt wheels and binaries; test before adopting."}
        },
        {
          "@type": "Question",
          "name": "Can agents install packages into a distroless sandbox?",
          "acceptedAnswer": {"@type": "Answer", "text": "Not inside the session. The pattern is to let the agent propose packages in a dev-full session, then bake them into the next image build."}
        },
        {
          "@type": "Question",
          "name": "Does a smaller image improve isolation?",
          "acceptedAnswer": {"@type": "Answer", "text": "Indirectly: fewer packages mean fewer vulnerable binaries reachable at runtime, but the boundary itself comes from the sandbox technology, not the image."}
        }
      ]
    }
  ]
}