I checked the docker run in snackup.sh. The baseline is already pretty solid: read-only rootfs, dropped capabilities, no-new-privileges, non-root execution, CPU/memory limits and bounded tmpfs mounts.

I wouldn't add a custom seccomp profile just for the sake of having one — Docker uses its built-in seccomp profile by default unless it's explicitly disabled.

A couple of things I'd still consider:

• add --pids-limit so a session can't exhaust the host's process table;
• if the user doesn't actually need every GPU, expose a specific GPU with --gpus '"device=0"' instead of --gpus all;
• for a stronger host boundary on Linux, rootless Docker or daemon-level userns-remap is worth considering.

The GPU boundary is inherently weaker than CPU-only isolation because the workload has to talk to the host NVIDIA driver, so I wouldn't describe GPU passthrough as equivalent to a VM security boundary.

One thing I'd change in the detection logic: docker info | grep -qi nvidia is a fairly indirect test. I'd distinguish "Docker isn't running" from "GPU runtime/toolkit isn't usable" and report the latter separately rather than silently treating it as CPU-only.

This is exactly what I was hoping for RunSnack, thanks for actually reading the script.

All four land. --pids-limit is a real gap and I don't have a good reason for it not being there.

Fair point on seccomp: I'd have been adding a profile to look thorough rather than to fix anything.

On --gpus, you're right that a specific device should be the sane default and all-GPUs the opt-in, not the reverse.

And docker info | grep -qi nvidia does conflate two very different failures — silently falling back to CPU-only when the toolkit is broken is the worst of the options.

Also noted on rootless and userns-remap, and I'll keep saying plainly that GPU passthrough isn't a VM boundary.

Marking this as the answer :)

NEW — now compatible with DGX Spark (in addition to NVIDIA Jetson (JetPack 6.1) and AMD64) 😊 We keep growing.