comparison.html

---
layout: default
title: "Sandlock vs Containers, MicroVMs, and gVisor"
description: "An honest comparison of Sandlock against containers, microVMs, gVisor, and bubblewrap, including the cases where Sandlock is the wrong tool."
permalink: /comparison.html
---

<style>
.alt-grid {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
    gap: var(--space-4);
    margin-top: var(--space-8);
}

@media (max-width: 880px) {
    .alt-grid {
        grid-template-columns: 1fr;
    }
}

.alt-card {
    padding: var(--space-6) var(--space-7);
    background: white;
    border: 1px solid var(--gray-200);
    border-left: 3px solid var(--gray-300);
    border-radius: var(--radius-lg);
}

.alt-card h3 {
    font-size: var(--text-base);
    font-weight: 700;
    color: var(--gray-900);
    letter-spacing: -0.01em;
}

.alt-card .what {
    font-size: var(--text-sm);
    line-height: var(--leading-snug);
    color: var(--gray-500);
    margin: var(--space-1) 0 var(--space-5);
    padding-bottom: var(--space-4);
    border-bottom: 1px solid var(--gray-100);
}

.alt-card dt {
    font-family: var(--font-mono);
    font-size: 10px;
    font-weight: 600;
    text-transform: uppercase;
    letter-spacing: 0.1em;
    color: var(--gray-400);
    margin-bottom: var(--space-1);
}

.alt-card dd {
    font-size: var(--text-sm);
    line-height: var(--leading-relaxed);
    color: var(--gray-600);
    margin-bottom: var(--space-4);
}

.alt-card dd:last-child {
    margin-bottom: 0;
}

.alt-card strong {
    color: var(--gray-900);
    font-weight: 600;
}

.alt-card a {
    color: var(--accent-700);
    text-decoration: underline;
    text-decoration-color: rgba(201, 161, 62, 0.35);
    text-underline-offset: 2px;
}

.alt-card a:hover {
    color: var(--accent-600);
    text-decoration-color: var(--accent-500);
}


.not-for {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: var(--space-4);
    margin-top: var(--space-8);
}

@media (max-width: 1000px) {
    .not-for {
        grid-template-columns: repeat(2, 1fr);
    }
}

@media (max-width: 660px) {
    .not-for {
        grid-template-columns: 1fr;
    }
}

.not-for-item {
    padding: var(--space-5) var(--space-6);
    background: rgba(255, 255, 255, 0.03);
    border: 1px solid rgba(255, 255, 255, 0.07);
    border-left: 2px solid var(--error);
    border-radius: var(--radius-md);
    display: flex;
    flex-direction: column;
}

.not-for-item h3 {
    font-size: var(--text-base);
    font-weight: 700;
    color: white;
    margin-bottom: var(--space-2);
    letter-spacing: -0.01em;
}

.not-for-item p {
    font-size: var(--text-sm);
    line-height: var(--leading-relaxed);
    color: rgba(255, 255, 255, 0.55);
    flex: 1;
}

.not-for-item .instead {
    flex: none;
    margin-top: var(--space-4);
    padding-top: var(--space-3);
    border-top: 1px solid rgba(255, 255, 255, 0.07);
    font-size: var(--text-sm);
    line-height: var(--leading-snug);
    color: rgba(255, 255, 255, 0.75);
}

.not-for-item .instead b {
    display: block;
    font-family: var(--font-mono);
    font-size: 10px;
    font-weight: 600;
    text-transform: uppercase;
    letter-spacing: 0.1em;
    color: rgba(255, 255, 255, 0.35);
    margin-bottom: var(--space-1);
}

.not-for-item .instead a {
    color: var(--accent-400);
    text-decoration: underline;
    text-decoration-color: rgba(215, 176, 87, 0.4);
    text-underline-offset: 2px;
}
</style>

<section class="hero hero-page">
    <div class="hero-container">
        <div class="hero-badge">
            <i data-lucide="git-compare"></i>
            <span>Comparison</span>
        </div>
        <h1>Where Sandlock Fits</h1>
        <p class="subtitle">Sandlock is not a container runtime with a smaller footprint, and it is not a lightweight VM. It occupies a different point entirely: strict, kernel-enforced confinement of a process, with no image, no privilege, and no boot.</p>
    </div>
</section>

<section class="section">
    <div class="section-container">
        <div class="section-header">
            <div class="section-badge">
                <i data-lucide="table-2"></i>
                <span>Side by side</span>
            </div>
            <h2 class="section-title">Sandlock, Containers, and MicroVMs</h2>
            <p class="section-subtitle">The measured figures come from Sandlock's own benchmark suite on a typical Linux workstation. Treat them as an order of magnitude, not a guarantee for your hardware.</p>
        </div>

        <div class="data-table-wrap">
            <table class="data-table">
                <thead>
                    <tr>
                        <th scope="col">Property</th>
                        <th scope="col" class="col-highlight">Sandlock</th>
                        <th scope="col">Container</th>
                        <th scope="col">MicroVM (Firecracker)</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <th scope="row">Root required</th>
                        <td class="col-highlight"><span class="yes">No</span></td>
                        <td>Yes<sup>*</sup></td>
                        <td>Yes (KVM)</td>
                    </tr>
                    <tr>
                        <th scope="row">Image build</th>
                        <td class="col-highlight"><span class="yes">No</span></td>
                        <td>Yes</td>
                        <td>Yes</td>
                    </tr>
                    <tr>
                        <th scope="row">Startup time</th>
                        <td class="col-highlight">~5 ms</td>
                        <td>~200 ms</td>
                        <td>~100 ms</td>
                    </tr>
                    <tr>
                        <th scope="row">Kernel</th>
                        <td class="col-highlight">Shared</td>
                        <td>Shared</td>
                        <td>Separate guest</td>
                    </tr>
                    <tr>
                        <th scope="row">Filesystem isolation</th>
                        <td class="col-highlight">Landlock + seccomp COW</td>
                        <td>Overlay</td>
                        <td>Block-level</td>
                    </tr>
                    <tr>
                        <th scope="row">Network isolation</th>
                        <td class="col-highlight">Landlock + seccomp notify</td>
                        <td>Network namespace</td>
                        <td>TAP device</td>
                    </tr>
                    <tr>
                        <th scope="row">HTTP-level ACL</th>
                        <td class="col-highlight">Method + host + path rules</td>
                        <td><span class="no">Not available</span></td>
                        <td><span class="no">Not available</span></td>
                    </tr>
                    <tr>
                        <th scope="row">Syscall filtering</th>
                        <td class="col-highlight">seccomp-bpf</td>
                        <td>seccomp</td>
                        <td><span class="no">Not applicable</span></td>
                    </tr>
                    <tr>
                        <th scope="row">Resource limits</th>
                        <td class="col-highlight">seccomp notify + SIGSTOP</td>
                        <td>cgroup v2</td>
                        <td>VM configuration</td>
                    </tr>
                    <tr>
                        <th scope="row">Programmable interception</th>
                        <td class="col-highlight">Handler API on any syscall</td>
                        <td><span class="no">Not available</span></td>
                        <td><span class="no">Not available</span></td>
                    </tr>
                </tbody>
            </table>
        </div>
        <p class="table-note"><sup>*</sup> Rootless containers exist, but they require user-namespace support and a configured <code>/etc/subuid</code>. On a locked-down host, that configuration is itself a privileged operation.</p>
    </div>
</section>

<section class="section section-alt">
    <div class="section-container">
        <div class="section-header">
            <div class="section-badge">
                <i data-lucide="scale"></i>
                <span>Adjacent tools</span>
            </div>
            <h2 class="section-title">Overlap With Related Tools</h2>
            <p class="section-subtitle">Each solves part of the same problem. This is where the overlap ends, and which tool to reach for instead.</p>
        </div>

        <div class="alt-grid">
            <div class="alt-card">
                <h3>gVisor</h3>
                <p class="what">A userspace kernel that reimplements the Linux syscall interface.</p>
                <dl>
                    <dt>Difference</dt>
                    <dd><strong>Every syscall is serviced by the Sentry</strong>, and compatibility depends on how completely it reimplements the interface. Sandlock leaves the host kernel in the syscall path and intercepts only the calls that carry a policy decision.</dd>
                    <dt>Prefer gVisor when</dt>
                    <dd>You are running a full untrusted OS image and can absorb the per-syscall cost.</dd>
                </dl>
            </div>

            <div class="alt-card">
                <h3>bubblewrap and firejail</h3>
                <p class="what">Confinement assembled from mount, PID, and user namespaces.</p>
                <dl>
                    <dt>Difference</dt>
                    <dd>Sandlock's policy is <strong>an access-control ruleset, not a constructed namespace</strong>, so there is no filesystem to assemble and no user-namespace requirement. It also covers ground namespaces do not: destination-IP allowlists, HTTP method and path rules, credential injection, and copy-on-write rollback.</dd>
                    <dt>Prefer them when</dt>
                    <dd>You are sandboxing desktop applications, where a private namespace view is itself the goal.</dd>
                </dl>
            </div>

            <div class="alt-card">
                <h3>OpenShell</h3>
                <p class="what">An agent-first control plane from NVIDIA: a gateway, a policy engine, and privacy-aware routing for model calls.</p>
                <dl>
                    <dt>Difference</dt>
                    <dd>OpenShell is a <strong>layer above a sandbox rather than a sandbox</strong>. It requires Docker, Podman, a microVM, or Kubernetes underneath and coordinates their lifecycle; Sandlock is the confinement itself, with no runtime to install and no image to build. They compose more naturally than they compete.</dd>
                    <dt>Prefer OpenShell when</dt>
                    <dd>You want the control plane around the sandbox, particularly its inference routing, which keeps sensitive context on sandbox compute and swaps model backends at runtime. Sandlock has no equivalent; its HTTP ACL and credential injection govern the request, not which model serves it.</dd>
                </dl>
            </div>

            <div class="alt-card">
                <h3>runc and Kubernetes</h3>
                <p class="what">The default OCI runtime, built from namespaces, cgroups, and <code class="inline">pivot_root</code>.</p>
                <dl>
                    <dt>Difference</dt>
                    <dd>Not either/or. <a href="/docs/oci.html"><code class="inline">sandlock-oci</code></a> implements the same runtime interface, producing a <strong>namespace-less, cgroup-less container</strong> that runs unprivileged, so existing OCI images need no changes.</dd>
                    <dt>Prefer runc when</dt>
                    <dd>Your workload depends on a container-private PID or network namespace specifically, rather than on the isolation they provide.</dd>
                </dl>
            </div>
        </div>
    </div>
</section>

<section class="section section-dark">
    <div class="section-container">
        <div class="section-header">
            <div class="section-badge">
                <i data-lucide="triangle-alert"></i>
                <span>Honest limits</span>
            </div>
            <h2 class="section-title">When Sandlock Is the Wrong Tool</h2>
            <p class="section-subtitle">Picking the wrong isolation primitive is worse than picking none, because it buys confidence you have not earned. In these cases, reach for something else.</p>
        </div>

        <div class="not-for">
            <div class="not-for-item">
                <h3>You need a separate kernel</h3>
                <p>The workload runs on your kernel, so a kernel-level vulnerability is a shared risk. If your threat model includes an attacker willing to spend a kernel exploit, you need a hypervisor boundary.</p>
                <p class="instead"><b>Use instead</b>A microVM, or <a href="https://multikernel.io" target="_blank" rel="noopener noreferrer">Multikernel's per-workload kernel</a>.</p>
            </div>

            <div class="not-for-item">
                <h3>You need to boot a system</h3>
                <p>Sandlock confines processes, not machines. A workload that expects init, systemd, a full device tree, or its own kernel modules is asking for the wrong abstraction.</p>
                <p class="instead"><b>Use instead</b>A virtual machine.</p>
            </div>

            <div class="not-for-item">
                <h3>Your kernel is older than 6.12</h3>
                <p>Landlock ABI v6 lands in 6.12, and the strict default refuses to start without the protections it expects. Usually only the two v6 IPC scopes are at stake; every earlier protection has its own, lower kernel floor.</p>
                <p class="instead"><b>Use instead</b>Sandlock with the missing protections <a href="/docs/protections.html">degraded per policy</a>, accepting that each one waived is confinement you no longer have.</p>
            </div>

            <div class="not-for-item">
                <h3>You need hard CPU or memory guarantees</h3>
                <p>Limits come from the supervisor, not cgroups: memory by tracking allocation syscalls, CPU by cycling SIGSTOP and SIGCONT. That bounds consumption without reserving capacity.</p>
                <p class="instead"><b>Use instead</b>A cgroup on the Sandlock process itself. The two compose.</p>
            </div>

            <div class="not-for-item">
                <h3>You are not on Linux</h3>
                <p>Landlock and seccomp are Linux facilities, and the entire design rests on them. There is no port to another platform and there will not be one.</p>
                <p class="instead"><b>Use instead</b>A VM, or platform-native sandboxing.</p>
            </div>

            <div class="not-for-item">
                <h3>You need rotating secrets</h3>
                <p>Credential injection loads the secret once at supervisor start, so a leased or rotating value is only picked up on the next run.</p>
                <p class="instead"><b>Use instead</b>Restart the sandbox on rotation. Sandlock composes with a secret manager rather than embedding one.</p>
            </div>
        </div>
    </div>
</section>

<section class="cta-band">
    <div class="cta-band-inner">
        <h2>Still Deciding?</h2>
        <p>Read the security model to see exactly what each layer enforces and what it does not, or bring us the workload and we will tell you honestly whether Sandlock is the right boundary for it.</p>
        <div class="button-group">
            <a href="/security.html" class="btn btn-primary">
                <i data-lucide="shield-check"></i>
                Security Model
            </a>
            <a href="/enterprise.html" class="btn btn-secondary">
                <i data-lucide="messages-square"></i>
                Talk to an Engineer
            </a>
        </div>
    </div>
</section>