Show HN: dockerc – Docker image to static executable "compiler"

Original Article ↗ Hacker News Discussion ↗

A new tool called dockerc packages Docker/OCI container images into standalone Linux executables by bundling a minimal container runtime, FUSE-based filesystems, and the image itself into a single binary. Commenters see it as a convenient way to ship complex apps (e.g., Python/Ruby stacks) without requiring users to install Docker, and compare it to alternatives like AppImage, Nix bundles, Singularity and Enroot. Key trade-offs raised include large binary sizes, reliance on FUSE and Linux container features, hurdles for Windows/macOS support via virtualization, and whether this pattern is a clever packaging hack or an operational antipattern in production stacks.

How dockerc Works

  • Wraps a container runtime (crun), FUSE-based squashfs and overlayfs implementations into one static binary.
  • Appends the Docker/OCI image as a squashfs; at runtime it mounts squashfs + overlayfs and starts the container.
  • Uses squashfs both to store the OCI bundle and as the lower layer in overlayfs.

Filesystem, FUSE, and Permissions

  • Relies on FUSE for mounting; this typically requires root or proper FUSE configuration for unprivileged users.
  • Known limitation: behaves similarly to AppImage here; alternative would be extracting the image to disk, which adds overhead.
  • On systems without user namespaces (e.g., CAP_SYS_USER_NS disabled), runtime errors like clone: Operation not permitted occur.

Language and Implementation

  • Implemented in Zig mainly due to a hackathon constraint plus its strong build system, easy static binaries, C interop, and file embedding.
  • Build system lets the “runtime” be a dependency of the “compiler,” which is highlighted as a nice fit.

Use Cases and Perceived Benefits

  • Targeted at distributing software to end users, especially projects that currently tell users to run docker run.
  • Promises “portable executables” for any Docker/OCI image, e.g., shipping Ruby/Python apps without requiring local runtimes.
  • Startup time is almost constant regardless of image size; runtime overhead is ~6–7 MB today, potentially reducible.

Limitations, Bugs, and Operational Concerns

  • Early users hit errors (missing trust policy, chown on /dev/pts), some fixed quickly, others tracked as known issues.
  • Generated binaries currently don’t work cleanly inside containers due to FUSE mount restrictions.
  • Thread notes potential networking/firewall and resource-sharing pitfalls, though author claims it behaves like a normal app, not a Docker daemon client.

Comparison to Existing Tools

  • Similar in spirit to AppImage (squashfs-based, single-file apps) but reuses existing Docker images and runs them in containers for stronger isolation.
  • Compared/contrasted with Singularity/Apptainer, Enroot bundles, Nix’s nix bundle/nix-bundle, ruby-packer/traveling-ruby, Cosmopolitan, WASM, and unikernels.
  • Some argue Nix or Nix-based fat binaries render this unnecessary when Nix is already in use.

Cross-Platform Ambitions

  • Linux works today; macOS/Windows support planned via QEMU or native virtualization (Apple Virtualization Framework, Hyper-V/WSL2).
  • Concerns raised about binary bloat, GUI integration, filesystem interaction on non-Linux, and need for admin privileges for virtualization.
  • Author aims for transparent UX (no manual Docker/Hyper-V setup) but acknowledges emulation may be needed in some cases.

Enthusiasm vs Skepticism

  • Many commenters are excited, see it as “awesome,” and want to use it for complex stacks or to avoid asking users to install Docker.
  • Others see it as an antipattern or “full circle” bloat: packaging containers into giant binaries instead of building native executables or using existing packaging systems.
  • Security discussion: tension between “just give me the EXE” convenience and modern needs for sandboxing, permission models, and trusted distribution channels.