This has been quite a few nights and weekends, and I’m at the point where OTP 27 boots, Elixir runs, and TCP works — so I figured it was time to share it.
Tyn is a minimal Rust kernel that does one thing: host the BEAM. It boots directly on KVM/QEMU, loads the real unmodified OTP 27 ERTS, and runs your Erlang/Elixir code. No Linux, no containers, no POSIX — just BEAM on bare metal.
$ echo "hello" | nc localhost 5555
Hello from OTP 27 on Tyn!
Why?
The thought that kept bugging me: BEAM already has its own scheduler, its own memory management, its own process isolation, its own supervision, its own distribution protocol. It’s basically an operating system for your application. So why are we running it on top of another operating system that duplicates all of that?
Tyn is the experiment: what if you strip away everything the BEAM doesn’t need and give it a purpose-built host? The entire kernel is about 5,000 lines of Rust. It handles memory, interrupts, virtio drivers, a TCP/IP stack (smoltcp), and an in-memory VFS serving .beam files from a cpio archive baked into the image. BEAM handles everything else.
How it works
ERTS is compiled against musl (statically linked, same as Alpine Linux). musl translates libc calls into Linux syscalls. Tyn traps those syscalls and handles them in Rust. ERTS genuinely doesn’t know it’s not running on Linux — it’s the same binary you’d run on Alpine.
┌─────────────────────────────────────────┐
│ Your Elixir / Erlang / Gleam code │
├─────────────────────────────────────────┤
│ OTP 27 (unmodified ERTS, SMP) │
├─────────────────────────────────────────┤
│ ~50 Linux syscalls implemented (Rust) │
├─────────────────────────────────────────┤
│ Tyn Kernel — 5,000 LOC Rust │
│ SMP · Memory · TCP/IP · VFS · Drivers │
├─────────────────────────────────────────┤
│ KVM / QEMU │
└─────────────────────────────────────────┘
What actually works
-
Unmodified OTP 27 — no source patches. Same ERTS you’d build for Alpine.
-
8-way SMP — APIC timers, per-CPU scheduling, proper blocking futex. All the threading machinery ERTS expects.
-
TCP networking —
gen_tcp:listen/accept/send/closeend-to-end through virtio-net. -
Elixir 1.18.3 —
IO.puts("Hello from Elixir on Tyn!")works.System.versionreturns"1.18.3". -
Stable — last stability run was 1 hour, 153 TCP connections, 41 OTP processes, zero faults.
What doesn’t work yet
-
JIT is disabled. Bytecode interpreter only. I/O-bound workloads are fine; compute-heavy code takes a hit. The kernel needs
mprotectwith executable page support — known fix, just haven’t done it yet. -
No interactive shell. Code runs via
-evalat boot. Interactive IEx needs terminal I/O handling I haven’t built. Remote shell over distributed Erlang is probably the better path anyway. -
No SSL/TLS. This is deliberate — OpenSSL would be the single largest component in the system. TLS termination at the load balancer is the expected model.
-
No Phoenix yet. OTP 27 + Elixir + TCP all work, so the pieces are there. Cowboy/Bandit testing is next on the list.
Some context
This isn’t the first attempt at BEAM-on-bare-metal. LING (Erlang on Xen) proved the concept around 2013 but died because it reimplemented the BEAM VM and couldn’t keep up with OTP releases. That was the lesson I took to heart — Tyn runs the real ERTS. When OTP 28 ships, it should just work.
Nerves and GRiSP are doing great work in the embedded space. Tyn is targeting a different niche — cloud deployments on KVM, where each BEAM node gets its own tiny VM instead of a container on shared Linux.
The pitch (if you need one)
-
~5,000 lines of Rust kernel vs a general-purpose OS. Smaller attack surface.
-
Boots in milliseconds. Good for elastic scaling.
-
Images are megabytes, not gigabytes.
-
VM-level isolation (hardware-enforced) instead of container isolation.
-
Scale by adding more Tyn VMs and connecting them via distributed Erlang — which is what BEAM was designed for.
Code & contributing
Everything is at github.com/tyn-os/kernel — MIT/Apache-2.0.
You’ll need an x86_64 Linux host with KVM, Rust nightly, and QEMU. The README walks through building ERTS against musl and packaging the VFS.
If any of this sounds interesting, I’d welcome questions, feedback, and ideas !
