FELF bundles a Linux program with its own glibc into one executable that needs no FUSE, root or install
The catch is what stays outside: config and data files, system fonts, certificates and GPU drivers still come from the host. The README's own benchmark has ten running Perl processes at 15 MB instead of 53, and three releases landed in about two hours on November 8.
Take a Linux program that runs on your machine and breaks on your friend’s, usually because the two machines carry different libraries. FELF’s answer is to ship the libraries too, all the way down to the C library. The project’s README puts it in six words: “One executable file. Its own glibc.”
The packing is one command: felf pack ./myapp -o myapp.felf. Other subcommands (inspect, verify, list, extract, sql) let you look inside the result. You can bundle extra libraries a program loads at runtime with --include, add search paths with --lib-dir, set environment variables with --env, and compress with --compress. --program puts several programs in one file so they share libraries, and --alias covers multicall binaries such as coreutils and busybox.
Starting it up has an odd shape. A static bootstrap picks which program to run from argv[0], unpacks the program and its libraries into memfds (files that live in memory), and hands off to a patched glibc loader. The loader then maps the libraries “straight out of the FELF file” instead of copying them, which, per the README, lets the kernel’s page cache share pages between processes. The README’s own benchmark, on one x86-64 machine, has ten running Perl processes using about 15 MB of memory under FELF against 53 MB with plain memfds, and a startup of 3.4 ms against 10.2 ms. That’s the project grading its own homework, so treat the numbers as the maker’s.
The README is blunter than most about the limits. FELF is a “distribution format, not a sandbox.” It controls which libraries load. It does not control which files a program can read. Data and config files aren’t bundled either: a program that needs them ships as a .tar.gz tree next to the FELF. Files the system provides, like /etc/fonts and CA certificates, still come from the host. Paths compiled into the program aren’t redirected, and host GPU drivers (GL, Vulkan) come from the host too. Strict mode is the default, and --permissive lets unknown libraries fall back to host copies. And since the file carries glibc, redistributing one comes with glibc’s LGPL terms, loader patch included.
It’s Apache-2.0 licensed and brand new. The releases page shows v0.1.0 on November 8 at 14, v0.2.0 at 15 and v0.3.0 at 17, about two hours and fifteen minutes from first release to third. Prebuilt static command-line builds for x86-64 and aarch64 are on it, and CMake integration is available. The release notes are bare changelog links, so what changed between those three is anyone’s guess. The repository shows about 15 commits, and everything in this piece comes from the project’s own pages.
The pitch gets more convincing the closer your program is to a self-contained tool. A command-line utility that only needs libraries is the good case: pack it, copy it, run it. A desktop app that wants your fonts, your certificates and your GPU driver is the harder one, and the README says outright which of those it leaves to the machine.
Fast-moving projects deserve a skeptical first week, and this one has had three releases in about two hours. A tool that fixes library mismatches by carrying its own libraries will probably keep growing a list of things it must carry, and the most useful thing to watch is whether the “stays on the host” list gets shorter. The README doesn’t promise it will.
Bring your own config.