Cygnus

Details

External ID

49046973

Source

HN

Company

—

Product

Cygnus

Website domain

cygnus.run

Launched

July 25, 2026

Cohort

—

Upvotes

8

Upvotes percentile

0.46176821983273597

Tags

—

Fetched at

Sept. 7, 2026, 9:26 p.m.

Updated at

Sept. 7, 2026, 9:26 p.m.

Description

I built Cygnus because of a long standing frustration with the compromises needed to be made when choosing a deployment option for web applications.The ecosystem is fragmented into a few distinct camps, each sacrificing user experience or runtime compatibility to balance isolation, startup latency, and their own profit margins.Docker: Heavier and slower because it has to supervise more than web apps. Paying overhead you don't need. MicroVM's: Good isolation, but huge maintenance surface area and substantial overhead. Great for untrusted code, overkill for your own apps. Workerd: Tries to dance around hardware isolation by enforcing an in-process V8 isolate model. Neutered runtime to prevent arbitrary syscall execution. Personally I still find the tradeoff worthwhile for their edge footprint, but I still find myself complaining about it from time to time. Vercel/Managed serverless: Delivers a great developer experience, uses microVM's which is good for compatibility but has a business model that eventually hands you a six-figure bill with a straight face ($0.15/GB bandwidth when budget providers charge cents per TB) and makes you sacrifice statefulness.These constraints make sense for hyperscalers or enterprises, but I don't have those kinds of needs.I just wanted something as light and fast as workerd(not exactly but closest i guess), but more rigid than just running them as bare userspace processes. Containers are just standard Linux processes wrapped in namespaces, cgroups, seccomp, and netns. You can do the same with systemd. And with Bun mature enough for production, combining an all-in-one JavaScript runtime directly with native Linux kernel primitives becomes a no-brainer.So I combined them into Cygnus, a single Rust daemon that turns raw kernel primitives and Bun into a self-hosted, scale-to-zero application platform.[ CLIENT: HTTP/1.1 · HTTP/2 · HTTP/3 (QUIC) ] | v [ Cygnus Daemon ] ├─ TLS termination (rustls) + ACME manager ├─ H1/H2/H3 front, normalized to H1 upstream ├─ Routing: SNI/Host → ArcSwap<HashMap> ├─ io_uring proxy loop (splice UDS↔TCP) ├─ Cage supervisor (spawn, health, drain, reap, crash backoff) └─ Admin API (root-only UDS) + Tenant-0 bridge (typed commands) | | HTTP/1.1 over per-app UDS (pooled, keep-alive) v ========== CAGE — per app, warm, reused ========== userns · mntns · pidns · ipcns · utsns · netns cgroup v2 (mem/cpu/pids) · seccomp allowlist bun (text shared via page cache, per version) ├─ preload shim: listen()/Bun.serve → UDS └─ artifact: bundle.js + bundle.jsc (RO mount) egress: veth ─ nftables policy ─ host NAT DNS: host-side forwarder at gateway IP What you get:- ~50ms cold starts with 0 guest kernel overhead - Page-cache shared runtime(low resource usage) - 100% native compatibility(it's literally running bun) - Zero-config setup(injects a listener shim to serve the app, no manual changes needed) - Dogfooded control plane with a great UX and dashboard running as tenant 0Cygnus uses cages, a shared-kernel process isolation model. The way it currently is, it's designed for trusted code(your apps or apps you trust). It provides defense-in-depth against buggy code, supply-chain attacks, and SSRF. However, it is not designed for untrusted, anonymous multi-tenancy (yet).I'd love to hear your thoughts on the architecture, kernel primitive choices, and seccomp filtering strategy!Trying it out is a 1 liner, it works on macOS too but without any of the Linux isolation benefits, for testing it out or running locally.curl -fsSL https://cygnus.run/install.sh | bashGithub repo has a demo gif if you want to see what it looks like!https://cygnus.run https://github.com/0xchasercat/cygnus

• Source listing
• Website