Positioning

Customer profile

A developer (solo or small team) building a web application, server, or CLI who wants to distribute it to users or colleagues who have nothing installed — neither Docker, nor Python, nor Node, nor anything else. They want a single, self-extracting file they can sign to prove its origin, and update incrementally.

The segment: universal application packaging

	Docker	PyInstaller/pkg	llamafile	daedalus
Runtime	Container daemon	Mono-language	C++ only	Multi-runtime
Delta updates	Layer cache (partial)	None	None	SISR content-defined
Sandbox	Namespace	None	None	seccomp + Landlock
Portable format	Image OCI	Executable	Single file	Single .daedalus file
Self-contained	Needs daemon	Runtime bundled	All-in-one binary	Stub + rootfs + app

Who has this problem today?

Multi-runtime web app developers: publish a repo with requirements.txt + package.json, but their users must install Python + Node + all the dependencies. Setup: 30+ minutes.
SaaS startups: build an API with Python + a FastAPI server, but deploying onto heterogeneous edge servers (x64/ARM64, Linux/macOS/Windows) requires per-architecture builds.
Prototyping teams: want to share an experimental app between colleagues without creating a Docker image (too heavy), without PyInstaller (mono-language), without manual setup.

Why now?

Multi-language apps are the norm: a modern project combines a Python backend + a Node frontend. PyInstaller handles Python only, Bun handles JS/TS only — you need two tools.
llamafile (Mozilla-Ocho, 25k★): the direct competitor, but C++ only, no delta updates, no sandbox, no multi-runtime.
Docker is too heavy for the laptop: daemon, root, resources. An app should start in 2 seconds, not require a container engine.
Multi-arch deployment: fragile cross-compilation, manual per-architecture runtime management.

Why daedalus?

Against llamafile

llamafile = a C++ binary that packages a model + the llama.cpp runtime. It is built to run a model, not to package a complete application with web server + API + runtime.

daedalus = packages any runtime (Python, Node, Go, Binary) + code + config into a unified format, with SISR delta updates (llamafile downloads the entire file on every update) and seccomp+Landlock sandbox (llamafile has no isolation).

Against Docker

Docker is built for orchestration, not local distribution. It requires a daemon, root (or user namespaces), and network to pull the image.

daedalus = a single executable file (./app.daedalus), atomic extraction, works without a daemon and without root privileges (user namespaces).

Against PyInstaller/pkg

Mono-language: PyInstaller works for Python, pkg for Node. But a modern app often needs multiple languages: a Python/Node backend, a Go worker, a native binary.

daedalus = multi-runtime in a single format. An app can have a Python runtime for the API, a C++ binary for an engine, and a Node script for a worker — all inside one .daedalus.

What daedalus is NOT (a new format)

We are not creating a new standard. The .daedalus format is:

A valid ELF (Linux) — chmod +x && ./app.daedalus works
A tar/zstd or SquashFS payload — extractable with tar/unsquashfs
Standard Ed25519 signatures — verifiable with the standard crypto library
A POSIX rootfs — no proprietary kernel features

The format has evolved from v2 (plain) → v3 (signed) → v4 (encrypted) → v5 (squashfs), and reads older versions. We never fork the format.

What daedalus is NOT

Not a Docker killer: Docker remains for orchestration and multi-container.
Not a VM: we do not virtualize the kernel; the app runs on the host kernel.
Not a package manager: no central registry required (optional).
Not desktop packaging: AppImage/Snap/Flatpak handle desktop integration (icons, menus, X11/Wayland). daedalus targets headless web/server apps — "I launch the binary, a server starts, I open my browser."
Not a cross-language bridge: daedalus does not compile Python into WASM. Each runtime runs in its own environment (Python/venv, Node/node_modules, Go/binary).

The most promising use case

Distributing multi-runtime web applications: package a FastAPI server (Python) + a Node bundler (frontend) + a Go binary (worker) into a single file that starts with ./app.daedalus and updates via SISR delta updates (15MB instead of 80MB).

Today this case has no clean solution:

Docker: too heavy, requires a daemon, not made for the laptop
AppImage: not made for headless servers
PyInstaller/pkg: mono-language, does not handle multi-runtime

← The Problem Architecture →