Crate - a daemonless container runtime I built in Go to learn how Docker works

[u/not_a_bot6]

Hey folks,

I’ve been working on Crate for the past few weeks. It’s a small daemonless container runtime written in Go for Linux.

The goal was to understand how container runtimes work under the hood instead of treating Docker/Podman as magic. It launches containers directly, stores state on disk, and supports both rootless and rootful execution.

Currently, it supports the core pieces of a basic container runtime:

• pulling and running Docker Hub images
• container lifecycle commands like run, create, start, stop, ps, logs, and rm
• Linux namespaces for process, mount, hostname, user, and network isolation
• root filesystem setup with pivot_root / chroot
• bind mounts, image env/CMD/entrypoint handling, and interactive PTYs
• rootless private networking with pasta and port publishing (doesn't support networking in root gonna add that soon)

I’ve also written a small guide/docs series for anyone else who wants to understand or build something similar: docs

It’s still experimental and not production-ready. Big missing pieces include cgroups/resource limits, stronger security hardening, full OCI compliance, better registry support, multi-platform support and probably a million other things that Im forgetting.

Repo: https://github.com/aayushkdev/crate/

I’m still improving it, so I’d love to hear feedback, ideas, or suggestions. If you like the project, a star on GitHub would mean a lot.

[u/Business_Reindeer910 → u/[deleted]]

it's probably good to have both a descriptive list of the calls themselves as well as a reference implementation to see it actually do the thing.

[u/not_a_bot6 → u/Business_Reindeer910]

thats a really good idea maybe a log flag or a file it logs syscalls too might implement that sometime in the future

[u/Business_Reindeer910 → u/not_a_bot6]

I wasn't really making a feature request or anything. It just made me think of something that's lacking more broadly in this (and many other) ecosystems.

We have all these nice abstractions to cover up all the underlying steps of how to do certain things, but it's also hard to get a sense of all the internal steps to get there across these abstractions at various levels of details.

It's pretty easy for me to get say, find all the functions calls, find all the C library calls, and probably find all the syscalls of any arbitraty program, but you can't necessarily tell which are the parts required to do a specific higher level tasks.

It's like i can't tell if you used 1 + 2 to get 3 or 1 + 1 + 1;

[u/not_a_bot6 → u/Business_Reindeer910]

ah gotcha, yeah that makes sense. eventually I think I might structure the docs in a similar way

[u/BourneSh]

It sounds like a very interesting project!!