Company · 2026-07-28

Why I build Daedalus? The story behind the name and the tool

Named after the mythical craftsman who built the Labyrinth. A dead SSD, a bootable USB stick, and one year of building on 8GB of RAM with no disk.

Ted Kouhouenou

Software & Security Engineer - Encapsul

The Labyrinth - Daedalus and the Minotaur

Every tool has an origin story, and most of the time it is embarrassingly mundane. This one started with a hard drive that died twice in a week, a bootable USB stick, and a very specific shower thought. Here is the whole thing, in order.

Why the name

In Greek mythology, Daedalus was the brilliant craftsman and inventor who built the Labyrinth - a maze so intricate that even its creator could barely escape it. He gave his name to the very word "daedalic," meaning ingenious or cunningly designed.

That felt right for a tool that packages an application and its entire runtime into one self-extractible binary. You are not shipping a loose bundle of dependencies that can drift apart; you are handing the device a single, self-contained artifact that already knows the shape of its own maze.

Curiously, the project did not start with that name. Its working title was Hephaestus - the god of the forge and craftsmanship. It stuck for the first few weeks until we realized that naming a packaging tool after the divine blacksmith was a little too grand for something that spent its first month running off a USB stick. Daedalus, the mortal who built incredible things with his hands, fit much better.

The origin story

It began with hardware. My SSD died - twice - in the same week. The first death was annoying. The second one was a pattern. Rather than wait for a third, I booted a Linux Mint session straight off a USB key using Ventoy, which lets you drop ISO files onto a FAT-formatted drive and boot any of them directly.

That machine has 8GB of RAM and, at the moment I am writing this, no internal disk at all. It has been running like that for over a year now. Everything lives on external drives; the OS boots from the key, and the toolchain, sources and caches sit on a USB-attached disk I carry around.

That arrangement forces a weird kind of discipline. The package manager has to work offline against a local cache, because there is no guarantee the network - or the same disk - will be there next time. And because I kept losing the exact dependency set across re-boots, I started packing runtimes into the artifacts themselves. That is the entire thesis of daedalus in one sentence.

The idea, under the shower

The specific moment came while building toboggan, a small project of mine. Building from source over and over, on a machine with no disks to spare, made the fan spin up and the room warm up. Standing in the shower, hearing the PC work two rooms away, it hit me: I did not want to rebuild the same app and its runtime a hundred times. I wanted to build it once, package the whole thing into a single file, and drop it onto any device - no network, no "I left my dependencies on another disk" problem.

That is why daedalus packages the runtime with the app: so you never have to reproduce a build environment on the target, and never depend on the network being up when you ship.

Why VFAT matters

There is a small detail worth highlighting. Because my whole OS boots from a VFAT-formatted stick, daedalus is designed to run straight off a fat-formatted, bootable drive - no install, no weird filesystem requirements, just copy it over and go. It is a tiny, probably useless, but honestly satisfying property that the packaging tool itself is packaged to travel.

Hardware underground

Right now I am experimenting with running daedalus on what I affectionately call hardware underground - the kind of low-end, forgotten machines that would never run a cloud toolchain. ARM gateways, old x86 boxes, devices with a gigabyte of RAM and a hard life. The whole point is that the software-update problem should be solvable on the devices that actually need it, not just on the ones with money for a datacenter. If it runs on an 8GB no-disk laptop booted from a USB key, it will probably survive in a rural clinic.

Use cases

Offline-first deployments - clinics, farms, and ships where the network is a rumor. Package once, ship the file, let the device verify and install it locally.
Air-gapped fleets - signed binaries with SHA-256 + Ed25519 verification and a full SBOM, all resolved on-device with zero connectivity.
Bring-your-own-runtime - pick the exact Node, Python, Go or Rust runtime your app needs; it ships inside the binary so the target needs nothing pre-installed.
Throwaway hardware - exactly the sort of box it currently runs on: no disk, no package manager to speak of, just a filesystem and a bootloader.

On constraints

“Constraint is easier than discipline.”

A phrase I keep coming back to, said by Steeve Morin on the French podcast À la French - an Épitech alumnus and the CEO of ZML, who previously ran engineering at Zenly. It resonated because losing a disk is a constraint no one chooses, yet it produced better tooling than any New-Year’s resolution about discipline ever did. When the machine forces you to be careful, you become careful.

It is open source. Help build it

daedalus is fully open source. If you hit a bug, find some rough edge, or have a specific use case you would like the tool to support, please open an issue - or better, open a pull request on github.com/Encapsul/daedalus. The tool was born out of a very personal constraint, but it is meant to be shaped by the people who actually deploy it: rural clinics, workshop floors, off-grid farms, and any device with more ambition than bandwidth.

Sources

daedalus attestation →