You run it
Boot Vulos OS on a mini-PC, a spare laptop, or your own cloud VPS — same binary either way. Self-hostable, always.
vulos · an open operating system
Your own server.
Your own keys.
Your own everything.
Vulos is a web-first operating system you run on hardware you own. Open any browser and land on a real desktop: your files, your apps, your terminal, your own private AI. Reach it from anywhere through the built-in Vulos relay. You hold the keys; nobody stores them. Not privacy theatre — agency.
vulos · Desktopvulos.org
How it worksYour box. Your OS.
Your box. Your OS.
Reachable anywhere.
The whole model in one line: you run Vulos OS on hardware you own, it holds your desktop, apps, files and private AI, and it stays reachable from any browser, carrying ciphertext nobody in the middle can read. With a static IP it’s reached directly over TLS; behind NAT the built-in Vulos relay — a role of the same binary, so you just run one yourself — makes it reachable. (Pier is an experimental alternative broker.) Nothing exposed, nobody holds your keys.
The OS is the authority
Your desktop, apps, files and private AI all live on your box — never in a shared central database.
The relay reaches it
Your box dials out — direct-first, relay-fallback — carrying ciphertext it can’t open. The relay is a role of Vulos itself, so you run your own; no ports to forward, nothing exposed. (Pier is an experimental alternative.)
You, anywhere
Sign in once and reach the same desktop from any browser, laptop or phone. Walk away with all of it anytime.
The operating systemA web-first operating system,
A web-first operating system,
built on Debian Linux.
Web apps run as first-class citizens in the browser. Native Linux GUI apps — GIMP, LibreOffice, Blender, games via Wine and Lutris — stream individual windows on demand over WebRTC. The shell, the file manager, the terminal, the dock: a real OS that happens to live in a tab.
shell · windows · dock
Web-native shell
Windows, dock, file manager, terminal, settings — a real OS shell rendered in the browser. Open it from your laptop, phone, or any browser anywhere and you get the same desktop.
Web-app sovereignty
Self-host the apps you would rent from SaaS. Memos, Navidrome, Uptime Kuma, Vaultwarden — installed as proper OS apps with their own subdomain and isolated namespace. Not iframes, not bookmarks.
Peering, not federation
Every Vulos instance is a server with an Ed25519 identity and a vulos:<id> URI. Instances message, share files, and place WebRTC calls directly. No middleman. No account on someone else’s server.
Real baremetal
Flash the same image to a USB stick. Boot into a labwc/cage compositor that renders the browser shell fullscreen, with native Linux app windows beside it. The same OS, end to end.
Vulos in motion
What you actually run.
Real screenshots from the open-source OS — the home you land in, every device and peer box in one roster, the app hub, your files and a real terminal. Reach any of them through the built-in Vulos relay; this is the OS itself.
One OS, every screen
One OS everywhere.
The same desktop, the same apps, the same identity — whether you open Vulos on a big monitor, a tablet on the couch, or your phone across the world. Reached through the built-in Vulos relay; no app store, no separate build.
Desktopany browser · full shell
Tablettouch · same session
Phonereach it anywhere
Private AIYour own AI,
Your own AI,
on your own data.
Vulos doesn’t sell you a model or ship your mailbox to someone else’s GPU. It’s AI-friendly: the OS and every app expose clean, gated context and tool seams to whatever model you plug in. Run a local model on your box, or point it at a provider you trust — you decide, per request.
- Bring your own model.llmux is a drop-in OpenAI-compatible gateway (or bring litellm). Ollama and llama.cpp on-box, or any provider — same API, your choice.
- Compute stays on your box.GPU and AI inference run on hardware you own or rent. Nothing runs on our machines — there is no shared pool your prompts or data pass through.
- Sovereign by default.The gateway only dials on-box, loopback backends by default. A remote provider is denied at dispatch — and never even contacted — unless you explicitly, and loggably, allow egress.
- Your corpus, AI-accessible.On-box embeddings and retrieval make your mail, files and docs answerable — without a byte leaving the box you control.
- Agency, not a black box.Every call is inspectable, every backend is yours to swap. No opaque model in the loop deciding what you can see.
# local model — dialed on-box, no network $ curl localhost:4000/v1/chat/completions -d '{"model":"ollama/llama3", ...}' → 200 OK backend=loopback egress=none # remote provider — denied at dispatch $ curl localhost:4000/v1/chat/completions -d '{"model":"openai/gpt-4o", ...}' → 403 sovereignty_error "remote backend blocked; set allow_egress:true" # opt in, explicitly + logged $ export LLMUX_ALLOW_EGRESS=true → 200 OK backend=openai egress=logged
The gateway layer
Convenience, not custody.
NAT traversal is hard. Firmware rollouts are hard. Recovering a locked-out box is hard. The built-in Vulos relay — a role of the same binary, so you run your own on any public-IP box — handles the parts your devices cannot do alone, forwarding encrypted bytes only. With a static IP you skip it and go direct. (Pier is an experimental alternative broker.) The OS keeps running regardless.
device · relay · device
- 01The built-in relayThe relay forwards encrypted circuits between your devices — direct peer-to-peer first, relayed only as a fallback. Ciphertext, never payload. It is a role of the same Vulos binary, so you run your own; Pier is an experimental alternative.optional
- 02Peering signallingRequest → approve handshake establishes signed server-to-server links. No open inboxes, no spam, no platform reading your messages.ed25519
- 03OTA updatesSigned firmware and app updates delivered over the air. Atomic rollback if a release misbehaves. Channels you control.signed
- 04SSH recoveryLocked out? An encrypted recovery channel restores access without a truck roll or factory reset. Off by default; opt in per device.opt-in
- 05Fleet managementCentral policy, roles, audit trails and single sign-on across a whole organisation is on the roadmap — not offered yet. Running a fleet and want it? Get in touch.roadmap
The front door
How the front door works Sign in once. Reach your box anywhere.
Your account lives on your own box — a username and password, with a 24-word recovery kit you save at setup and a PIN that locks the screen. Sign in once, and the built-in Vulos relay makes the box reachable from any browser. There is no central login server: your sign-in and your data both stay on hardware you own, and your identity is a keypair only you hold.
- 01Password, PIN, recovery kitSign in with a username and password, verified on your own box. A PIN locks the screen when you step away, and the 24-word recovery kit you saved at setup gets you back in. Nothing is held centrally, and no one else can open it.account
- 02Identity ≠ your dataLogin proves who you are; it never grants access to your content. The durable copy of everything is yours, on your box — never in a shared central database.decoupled
- 03One codebase, your hardwareThe OS and apps are open source and run on your own box — no fork, no hosted variant. Your identity is a keypair you hold; your data lives on your box.self-host
- 04Sovereign by exitBring your own mail (Gmail/Outlook/IMAP) as a connector, and self-host the whole box any time. Every central service is replaceable and exportable — convenience, never lock-in.byo
Built differentlyThree foundations you won't
Three foundations you won't
find elsewhere.
A verifiable boot chain from image to running OS. One account across every instance. A sync model with no elected leader. Each is a deliberate architectural choice, not a feature flag.
Signed boot chain, end to end.
Vulos ships as a squashfs image signed with an Ed25519 trust key baked in at build time. Whether you boot from USB or over PXE netboot, the kernel verifies the image before it runs anything. No unsigned firmware, no mutable rootfs, no post-install drift.
Boot architectureOne account. Every instance.
Your Vulos account is an Ed25519 keypair, not a row in a shared directory. Sign in to home.vulos, studio.vulos, or pi-lab.vulos with the same identity — no OAuth dance, no delegated trust, no shared secret store between instances.
Identity modelNo elected leader. No single point of failure.
Configuration and state sync across your instances uses a leaderless CRDT model: every node can write, all nodes converge, and none is authoritative. Partition tolerance is structural, not bolted on. Works offline; catches up when reconnected.
Sync internalsFirst-boot
From bare metal to a running OS in minutes.
Flash the image to a USB stick or point your BIOS at boot.vulos.org. Either way the trust key is baked in — the loader verifies the squashfs before the kernel hands off. No key-on-first-boot ceremony, no unsigned init phase.
- USB boot. Flash to any drive, boot immediately. No installer — the whole OS is the image.
- iPXE / netboot. PXE boot from boot.vulos.org. Machine picks up its signed image over the network.
- Ed25519 chain. Each image is signed at build time. The baked trust key verifies before execution.
- A/B update slots. A new image stages into the idle slot, and the initramfs boots the slot the boot state names — so a flip, or a rollback, takes effect on the next reboot. A missing or damaged state file keeps the image you are running.
signed squashfs · trust key baked in
ed25519 · peer to peer · no middleman
Open peering
Instances talk directly. No inbox to spam.
Every Vulos instance has an Ed25519 identity and a vulos:<id> URI. A request-approve handshake establishes a signed server-to-server link. After that, your instances message, share files, and place WebRTC calls peer-to-peer — no relay unless NAT forces it.
- Ed25519 identity. Cryptographic, portable, no platform dependency. Your key is the account.
- Request → approve. Explicit handshake, no open inboxes, no spam. You control who reaches you.
- P2P by default. WebRTC direct when possible. Relay as encrypted fallback when NAT requires.
- No middleman. vulos.org does signalling only. It never relays your content unless you opt in.
- Any relay can run this. Peer discovery and content-blind signalling are an open, key-addressed protocol — self-host a relay, or use ours. Standalone apps already peer this way with no Vulos OS involved.
One person, many instances
Your home box and your laptop. Both yours, always in step.
Vulos isn't locked to a single machine. Run it on your always-on home box and your laptop, and they sync as peers — your apps, settings and workspace follow you. Reach either one from your phone, whether you're on the couch or across the world.
- Reach from anywhere. Your phone dials your own instances directly — even behind NAT, with no port to open.
- Peers, not a hierarchy. A home box and a laptop you own sync state as equals. No elected leader, no central account.
- You hold every key. Instances authenticate over their own Ed25519 identities — the same peering model as messaging and calls.
reach from anywhere · instances stay in sync as peers
No lock-in
Your exit costs nothing.
We mean that literally. Vulos is open source. You run it on hardware you own, your data lives on your box or a storage bucket you choose, and your identity is a keypair you hold. There is nothing to unsubscribe from.
- Open-source OS. Fork it, study it, ship a build that disagrees with ours. The repo is the spec.
- One open binary. The same open-source binary is the one you run — no private blobs, no hosted-only features.
- Your data stays yours. It lives on your box, or a storage bucket you choose — never a store we run.
- Yours to take. Export your data and your keypair whenever — no lock-in.
- Portable identity. Export your Ed25519 keypair; the same Vulos ID survives the move.
- Open protocol, not just open source. Peering and reachability are a published, key-addressed spec, not a private wire format — other implementers can and do build on the same substrate.
your key · your bucket · zero egress
The honest part
What you take on.
The reason to run your own machine is that nobody else gets to change the terms on it — not the price, not the features, not who reads what. The price of that is a list of jobs that stop being somebody else’s. Here is the list: what actually lands on you, what the OS ships to meet it, and the chapter you can check us against.
A machine that stays on.
Vulos runs on hardware you own — a mini-PC, a spare laptop, a VPS. The floor is UEFI firmware with Secure Boot switched off (the bootloader is not Secure-Boot-signed today, so a machine with it enabled will simply refuse to start), 2 GB of RAM and 10 GB of disk. When that machine is off, so is your desktop.
In the boxOne image covers every shape: boot it live off a USB stick, install it to disk, or run it under Docker first if you would rather look before you commit.
Five secrets, kept offline.
A self-hosted box has a keys drawer, and none of it is ours: the 24-word recovery phrase shown once at account creation, the backup passphrase, the cluster passphrase, your credential-vault master password, and the recovery-kit file. The phrase resets a forgotten password without losing encrypted content — it does not recover the other four.
In the boxYour master key exists only as a doubly-wrapped envelope, sealed under your password and under the phrase. The plaintext is never written down or logged, so there is no copy of it for anyone to lose or be compelled to hand over.
Backups you have actually restored.
There is no one-click restore, and the manual says so under a heading called Honest gaps. The hourly encrypted vault covers your working data directory and only that — databases, key stores and your box’s peer identity sit outside its scope, and a box with no object store attached has no built-in offsite copy of Drive documents at all.
In the boxHourly Restic snapshots to a bucket you name, a database snapshot command built into the server binary, point-in-time snapshots of the bucket itself, and a written quarterly restore drill. As the chapter puts it: a backup you have never restored is a hope, not a backup.
Reachability is a machine too.
Vulos operates no relay for you. That is the trade-off that keeps anyone else out of your path — and it means reaching a box behind NAT is a small VPS with a public IP and a domain you control, which the manual costs at roughly €4 a month. The relay role is not a release artifact either; you build it from the same repo.
In the boxThe relay is a role of the same software, not a separate service or a company you sign up with. With a static IP you skip it entirely and go direct over TLS — and either way what passes through is ciphertext it cannot read.
The storage bill is yours, or nobody’s.
Attach an S3-compatible bucket and you pay that provider directly — we charge nothing for any of this and run no store of our own. Object pricing has well-known traps, egress fees and minimum-duration charges chief among them, so which provider you pick is a decision rather than a detail.
In the boxYou may not need one at all. By default the box keeps its objects as plain files on its own disk: no endpoint, no bucket, no credentials, no third party in the picture.
The next image needs somewhere to land.
An A/B update wants room for a second root filesystem — about 593 MB — beside the one you are running, and on a disk sized for exactly one there is nowhere to stage it. Block-level integrity has an edge of its own: booted from the live USB the root is checked by dm-verity as it is read, but a netboot install does not yet copy the hash tree in beside the image, so an installed box runs an image whose signature was checked rather than one being re-checked block by block. The architecture chapter writes both down (OSDIST-FLIP-01) instead of glossing them.
In the boxThe slot flip is real, and proven by an actual reboot rather than a unit test: a new image stages into the idle slot, the initramfs reads the boot state and boots the slot it names, and a rollback is that same mechanism in the other direction. A state file that is missing, truncated or nonsense keeps the image you are already running, so a half-written update cannot boot you into nothing. Every image is signed with an Ed25519 key baked in at build time, and the published live image writes nothing to your disk at all.
None of this is copy you have to take our word for. It is written down in what it takes to install, backup & recovery, running a relay, and the OS architecture — the same chapters that ship with the source.
By construction
Numbers you can verify in the repo.
Every limit and guarantee on this site is implemented in code, not promised in copy. The source is open — verify the math yourself.
MITOpen sourceEvery line is in the repo. Read it, fork it, ship your own.
0Ports to openYour box dials out to the broker — nothing exposed to the internet.
E2ERelay payloadsWe forward ciphertext only. No decryption keys held.
BYOStorageYour bucket, your bytes — take them with you anytime.
Open source
Read every line. Star what you trust.
Vulos is built in the open across the vul-os organisation — the OS shell, every app in the suite, and the engines beneath them. Star counts are pulled live from GitHub. Everything that runs your box is open source.
Built on the open ecosystem
- Debian Linux
- Linux
- Go
- React
- Vite
- TypeScript
- WebRTC
- PostgreSQL
vulos
diwan
lilmail
wede
slipscan
envoir
pier
gitstate
soko
kerf
aql
zana
sirboard
vuna
molao
athar
beepbite
cackle
pango
openrate
evermesh
magnetite
wibbly
kilio
patala
basin
kotva
llmuxReady when you areRun it now.
Run it now.
Leave whenever.
The whole suite is open source and runs on your own box. No account to create, nothing to lock you in — run it, read every line, and walk away whenever you like.
Runs on your hardware · MIT open source · No key custody · No payload logging