Understanding Hoody

Add up what a computer costs you before it does any work.

You install, and update, and install again on the next machine. You sync, then resolve the conflicts syncing created. You configure the same editor for the third time this year. You carry one specific laptop everywhere, because that is the one where everything is set up. You write software that runs on your machine and nowhere else, then spend a day making “somewhere else” exist: ports, certificates, DNS, a deploy pipeline, a VPN to reach any of it.

None of that is the work. All of it is friction. And every line of it is a symptom of the same bug:

Your computer is a place. It should be an address.

A place has to be visited. It chains your state to a disk, a desk, a power cable. Leave, and your work stays behind — so you copy, sync, ship, and hope. Let someone in, and you’re packaging, deploying, screen-sharing, or physically handing over hardware.

An address just resolves. From any device. For anyone you allow. Every time.

Why This Exists

Every generation of computing added a toll booth between a person and their work. Installers. Drivers. Dotfiles. Sync clients. Certificates. Port forwards. VPNs. Deploy pipelines. “Works on my machine.” Each toll was small, each was just this once — and together they became the shape of the job, so gradually that paying them started to feel like the work itself.

Meanwhile, all along, the web quietly demonstrated the alternative — for exactly one kind of thing. You have never installed a website. You have never synced one to your phone, carried the specific laptop that has your bank on it, or VPN’d into a search engine. Any page, any device, one protocol, zero setup. We all accepted that this grace applied to documents and to nothing else.

Hoody exists because that acceptance was wrong. One decision, and everything downstream rebuilt around it:

Your server is the computer. Your device is a viewport. Everything is a URL.

Your terminals, desktops, files, databases, editors, browsers, scripts, schedulers, and agents run on a server whose whole job is to keep them available — one that can’t be left in a taxi and never needs its environment lovingly recreated. Each one answers at its own HTTPS URL. Opening your computer becomes exactly as hard as opening a link — from your laptop, your phone, a borrowed machine, a terminal on a plane.

We are not selling a better deployment experience. We are removing the reasons “deployment”, “installation”, and “setup” exist as categories, so that what remains is the part you actually wanted: a computer that is simply there, wherever you are, with everything running and nothing to carry.

Friction is a tax on thought, and it compounds — every idea that dies at I’ll set that up later is a smaller life. That is the bug Hoody exists to fix: your computer, your work, and your tools, simply available — no setup, no syncing, no allegiance to one particular device. Automation benefits from the same frictionless world, but the world was built for you.

Everything Is an Address

With Hoody you don’t have one computer. You have as many as your server’s capacity and your operator’s limits allow — each a full Linux container of its own, each answering at its own URL. Here is a single container, seen through four of its doors:

https://67e89abc123def456789abcd-890abcdef12345678901cdef-terminal-1.node-us.containers.hoody.icu https://67e89abc123def456789abcd-890abcdef12345678901cdef-display-1.node-us.containers.hoody.icu https://67e89abc123def456789abcd-890abcdef12345678901cdef-agent-1.node-us.containers.hoody.icu https://67e89abc123def456789abcd-890abcdef12345678901cdef-http-8080.node-us.containers.hoody.icu

Read the address like a sentence: project, container, service, instance, server. Two 24-character IDs name the computer, a word names the door, a number names the instance. Instances are 1-based by convention and multiply within each service’s bounds — terminal-2 for the backend, display-2 for a second screen, sqlite-3 for the scraper’s scratch data. Native SSH is part of the same grammar: ...-ssh works with any SSH client.

Now notice what is missing. No DNS record that anyone created. No certificate anyone requested. No ingress object, no port mapping, no reverse-proxy stanza, no deploy step. The route is a parse of the name. The proxy reads the hostname and knows exactly which process you mean — so the moment a process exists its URL works, and a URL you have never used yet costs nothing at all. TLS comes with it: the proxy handles certificates automatically, so an ordinary Kit URL never asks you to mint or renew one.

That last row is the escape hatch: bind anything that speaks HTTP on 0.0.0.0 — a dev server, a notebook — and http-8080 in the hostname routes to it, provided the container’s proxy and its permissions allow. The route carries HTTP, HTTPS, and WebSockets; UDP and other non-HTTP protocols take a different networking path.

And what answers at the named doors is the whole machine, not a demo layer. A real shell (terminal), a graphical desktop (display), your filesystem (files), VS Code (code), SQLite over HTTP (sqlite), realtime multi-user notes (notes), automatable Chromium (browser), scripts served as endpoints (exec), supervised background programs (daemon), scheduled jobs (cron), filesystem events as a live stream (watch), an app resolver that fetches and launches almost anything (run), an HTTP client with sessions and scheduling (curl), a streaming pipe (pipe), desktop notifications (n), request logs (logs), a tunnel that goes both ways (tunnel), and the resident agent (agent). Every one born with a URL. Every one usable from a browser or curl. See The Hoody Kit for the full tour.

The Frictions, One by One

Hold each cost from the opening of this page against that model, and watch it stop existing.

”First, install it”

On your device there is nothing to install — a browser is the entire client, and any SSH client works too. On the server, you ask the run service for an app and it resolves it across Nix, pkgx, AppImage, Docker/OCI, and manifest registries, handing back the exact command. Run it at a terminal URL, watch it at a display URL. Your device didn’t change at all — and never will.

”Now deploy it”

Bind an HTTP port and it’s live at http-8080. Point your own domain at any container with a proxy alias: add the CNAME, and the certificate is provisioned for you. Showing a client the prototype stops being a release and becomes pasting a link. Staging-versus-production stops being two machines you maintain and becomes two containers you name.

”Now wire it up”

Everything that has a URL can be called by anything that speaks HTTP — which is everything. Drop a script into the exec directory and it is an API endpoint the instant the file exists: no framework, no router, no rebuild. Wrap a gnarly authenticated API call with curl and get back a single URL you can put in a bookmark, a webhook, a QR code. Hand a process to daemon and it stays up; hand the timing to cron and it runs while you sleep. The integrations you used to write are now URLs calling URLs.

”Bring the right laptop”

There is no right laptop. You’re in a café holding a tablet that isn’t yours and the staging bug won’t wait, so you type an address — and the screen fills with your shell, your history, your half-finished command, the log still tailing. You fix it on a borrowed device with nothing installed, and hand the tablet back.

That works because nothing had to move. Devices became interchangeable the day the computer stopped living in them; lose one and you’ve lost hardware, not work. And when something genuinely does live on a device — a database on your laptop, say — the tunnel service pulls it down into the container’s loopback, so the server reaches into your machine instead of you reaching into the server.

”Don’t close that window”

At six you close the laptop, and here is the whole trick: nothing happens. The dev server keeps serving. The scraper under daemon keeps scraping. The cron entry keeps waiting for 03:00, and watch keeps streaming file events to whatever is listening. Your window was never the process — it was one viewport into a process that runs on the server all night, every night. When a long job finishes it can raise a desktop notification on whichever display you name, and that display is itself a URL: open it from wherever you are and look.

”Works on my machine”

Then share the machine. Your terminal URL is the actual session — a teammate opens it and you’re both in the same shell, and you can hand out a read-only view to spectators in the same breath. Your display URL is the running app, interactive, not a video of it: the designer opens it on a monitor, the PM on a phone, and everyone is connected to the same live session. Need to broadcast something else? The pipe service streams anything — a screen, a file mid-transfer, a build log — from one sender to up to 256 receivers, with no server-side storage.

“Can you see my screen?” dies here. The question becomes “did you open the URL?” — and the answer is a link, not a meeting.

Screenshot Needed The same GUI application streaming live at its display URL, open simultaneously in a laptop browser and on a phone

Not screen sharing. The same session, many viewports.

”Get on the VPN”

A VPN grants access by putting your body on the right network. Hoody grants access at the address itself. A fresh container is open by default; when you want a lock, you set policy at the edge — passwords over HTTP Basic, IP addresses and CIDR ranges, JWTs, bearer tokens — per service, per instance. Your apps never need auth code of their own, because the lock lives at the address: securing everything is a policy change, never a redeploy. You can go further and put your own JavaScript in front of your container’s tenant-facing services — a hook that runs inside your own container’s exec, sees the real client IP, and inspects, rewrites, or blocks requests before they land.

Caution

Open by default means the two 24-character IDs in the hostname are the credential. That’s what makes “paste the URL to a teammate” work — and it’s why you treat container URLs like passwords. Set proxy permissions before you share anything you care about.

”Careful — don’t break anything”

Caution is a tax too. Snapshot a container before anything risky: snapshots capture the filesystem incrementally — after the first, changed blocks consume new storage rather than another full copy — and restoring puts files, packages, and database rows back exactly as they were. When you’d rather explore than gamble, copy the container instead — an independent duplicate with its own URLs, on the same server or another one. Branching a computer should feel like branching code. Now it does, so experiments stop being scary and start being Tuesday.

The Agent in Residence

Every container ships with Hoody Agent — an AI that lives where your work lives, not in a chat window next to it. It runs as two parts: hoody-agent-d, a daemon that streams the models, executes tools, and keeps your sessions, workflows, and memory; and hoody-agent, a fast terminal UI that connects to it. That split is why closing a window never costs you a session. And because the agent shares the container, “look at my failing test” isn’t an upload. It’s already there.

Its tabs read like a map of a whole computing life, grouped in three capsules:

AGENT    Sessions | Chat | Agents | Skills | Workflows | Hooks | TODOs
FLEET    Computers | Files | Scripts | Domains | Console
SYSTEM   Models | Settings | Vault | Memory | Logs

You never install it — it is already running on your server. You just pick whichever door is closest.

A browser. Open the container’s agent-1 URL. The terminal service runs the agent binary as the tab’s own process and streams it straight to your browser — the same TUI, character for character. Not a port. Not a web rewrite. The binary itself, rendered where you are.

An SSH client. From any machine on Earth — a Raspberry Pi, a datacenter box with no GUI, a phone’s terminal app:

ssh hoody.com

Two hops, nothing installed: a sandboxed Hoody CLI answers, signs you in, and hands you off to the Agent. In a hurry, your token can be the username:

ssh -tt hdy_xxxxxxxx@hoody.com

The CLI. From wherever you already work:

hoody agent
hoody agent <container>

Same binary through all three doors — which is this page’s thesis proving itself. When the interface is a terminal and the terminal is a URL, “where can I use it?” stops being a question. (Rendered in a browser, the TUI has one extra trick: a chat pane can hold a live web page when the agent needs to show you one. Still a terminal — just one that can look at the web it works on.)

The model behind it is a preference, not a marriage. The built-in Hoody AI gateway serves 300+ models, and you can bring your own keys from 100+ providers — switch mid-conversation, A/B test two models in two containers, swap this year’s frontier model for next year’s with a config change, never a migration.

Screenshot Needed The Hoody Agent terminal UI open in a browser tab — the Chat tab active, with the Agent, Fleet, and System tab capsules along the top

One TUI, three doors: a browser tab, ssh hoody.com, or hoody agent

The Same Addresses Work for Automation

Everything above is written as if you’ll open these URLs by hand — and you will. But they are ordinary HTTP surfaces, so everything you can click you can also call: from a script, a webhook, a bookmark, any tool you choose. Start a service in your container and it is immediately something you can open on your phone, share with a teammate, or test from another device.

The same holds when you bring an AI tool into your work. It can help you through the addresses you already use, instead of asking you to rebuild or upload your environment somewhere else — and for any tool that can fetch a URL, Hoody publishes a machine-readable Skill, a structured map of its HTTP surface, at hoody.com/llms.txt and hoody.com/.well-known/skill.md.

You stay at the center: one environment, one set of addresses, yours to open by hand or call by code.

Nothing Has a Meter

Friction isn’t only ceremony — it’s also the flinch before spinning something up, because it costs money to exist.

Start on the free tier, a slice of a shared machine, and graduate to the bare metal marketplace when you want hardware that answers to you alone. On a machine of your own there is no per-container fee, no CPU-second charge and no per-request pricing — containers cost nothing once the server exists, so you stop rationing them: a container per experiment, per client demo, per agent task, and every one of them a URL. The free slice runs the same model with guardrails, and it never expires. Its current defaults — environment-tunable, not guarantees, so an operator may set different values — are shared CPU and RAM, an operator-set disk quota for the slice, up to 10 containers with 10 snapshots each, 100 Mbit/s in each direction, and 20 proxy aliases. The habit forms there, and the ceiling lifts when you move. The marginal cost of “just spin one up” reaching zero changes how you work far more than it changes your bill.

The bytes behave the same way the billing does. The proxy that answers every URL on this page runs on the machine your containers live on, so your traffic resolves straight to that machine’s IP — there is no central Hoody proxy tier in the path. api.hoody.icu stays a pure control plane: it creates machines and containers and writes policy, and it never proxies your traffic. The full story, including exactly what we can and cannot see, lives in Security.

The Whole Argument, Backwards

Work from anywhere fell out of “the shell is a URL.” Zero deployment fell out of “the port is a URL.” Real collaboration fell out of “the session is a URL.” Automation without glue fell out of “the script is a URL.” A life that keeps running while you sleep fell out of “the process is not in your window.” And AI that needs no integration fell out of all of it at once.

One decision, carried all the way down.

The Weight, Lifted

Somewhere along the way you learned to accept that computers charge rent in attention: before the work, the setup; after the work, the shipping; in between, the constant tending of the one device that has everything on it.

You can just stop paying.

Your server runs. Your containers run. Your agent runs. When you want to look, you open a URL and you’re there — from any device, at any hour, on anything. When you want company, you share the URL and they’re there too.

Nothing to install. Nothing to sync. Nothing to lose. Your computer was a place. We made it an address. Open the URL. You’re already there.

Next: The Vibe → | The HTTP Revolution → | Security →