Understanding Hoody
Section titled “Understanding Hoody”Add up what a computer costs you before it does any work: install and update on every machine, sync and then resolve the conflicts syncing created, configure the same editor for the third time this year, carry the one laptop where everything is set up. Software that runs on your machine and nowhere else costs a day of making “somewhere else” exist: ports, certificates, DNS, a deploy pipeline, a VPN to reach any of it.
None of that is the work. It follows from one fact: your computer is a place, and a place has to be visited. Hoody is built on the opposite premise: a computer should be an address, one that resolves from any device, for anyone you allow, every time.
Why Hoody exists
Section titled “Why Hoody exists”Each generation of computing added another step between a person and their work, each step small and one-time, until doing the steps became the shape of the job.
The web has demonstrated the alternative all along, for exactly one kind of thing. You have never installed a website, synced one to your phone, or joined a VPN to reach a search engine: any page works on any device over one protocol with no setup, yet everyone accepted that this applied to documents and to nothing else.
Hoody exists because that acceptance was wrong. It rests on one decision: your server is the computer, your device is a viewport, and everything is a URL. Your terminals, desktops, files, databases, and agents run on a server whose job is to keep them available, each service at its own HTTPS URL. A server cannot be left in a taxi, and replacing the device you reach it with does not mean rebuilding its environment. The goal is not a better deployment experience; it is to remove the reasons “deployment”, “installation”, and “setup” exist as categories of work.
Container URLs
Section titled “Container URLs”You do not have one computer but as many as your server’s capacity and your operator’s limits allow, each a full Linux container with its own set of URLs. Here is one, seen through four of its services:
The address reads in order: project, container, service, instance, server. Two 24-character IDs name the computer, a word names the service, and 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 follows the same pattern: ...-ssh works with any SSH client.
Nothing in that hostname was set up in advance: no DNS record, certificate request, ingress object, port mapping, reverse-proxy stanza, or deploy step. The route is a parse of the name: the proxy reads the hostname, so a URL works from the moment its process exists and one you have never used costs nothing. TLS works the same way: the proxy issues and renews the certificates, and an ordinary Kit URL never asks you to create or renew one.
Row four is the catch-all: bind anything that speaks HTTP on 0.0.0.0 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.
What answers at those URLs is the whole machine: 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 built-in agent (agent). Each is usable from a browser or curl; The Hoody Kit has the full list.
The frictions
Section titled “The frictions”Here is each cost from the opening, held against that model.
”First, install it”
Section titled “”First, install it””Nothing installs on your device: a browser is the entire client, and any SSH client works. On the server, the run service resolves an app name across Nix, pkgx, AppImage, Docker/OCI, and manifest registries and returns the exact command: run it at a terminal URL, watch it at a display URL.
”Now deploy it”
Section titled “”Now deploy it””Bind an HTTP port and it’s live at http-8080. To serve your own domain, point a proxy alias at any container and add the CNAME; the proxy provisions the certificate. A prototype is a pasted link rather than a release, and staging versus production is two containers you name rather than two machines you maintain.
”Now wire it up”
Section titled “”Now wire it up””A script dropped into the exec directory is an API endpoint the instant the file exists: no framework, router, or rebuild. curl wraps an authenticated API call into a single URL for a bookmark, a webhook, or a QR code; daemon keeps a process up; cron runs it while you sleep.
”Bring the right laptop”
Section titled “”Bring the right laptop””There is no right laptop: on a borrowed tablet you type an address and your shell is there, history and tailing log intact, nothing installed. A lost device is lost hardware, not lost work. For what genuinely lives on a device, such as a database on your laptop, the tunnel service pulls it into the container’s loopback: the server reaches into your machine rather than the reverse.
”Don’t close that window”
Section titled “”Don’t close that window””Close the laptop and nothing happens: the dev server keeps serving, the scraper under daemon keeps scraping, the cron entry waits for 03:00, and watch keeps streaming file events. The window was only ever a viewport; the process runs on the server. A finished job can raise a desktop notification on whichever display you name, and a display is itself a URL.
”Works on my machine”
Section titled “”Works on my machine””Then share the machine. A terminal URL is the session itself: a teammate opens it into the same shell while spectators get a read-only view. A display URL is the running app, interactive rather than a video of it, open on a monitor and a phone at once. For anything else, the pipe service streams a screen, a file mid-transfer, or a build log from one sender to up to 256 receivers with no server-side storage.
”Get on the VPN”
Section titled “”Get on the VPN””A VPN grants access by putting your device on the right network; Hoody grants it at the address itself. A fresh container is open by default, and access control is policy set at the edge, per service and per instance: passwords over HTTP Basic, IP addresses and CIDR ranges, JWTs, and bearer tokens. The check happens at the address, so your apps carry no auth code and securing everything is a policy change rather than a redeploy. Beyond policy, your own JavaScript can sit in front of your container’s tenant-facing services: a hook running inside your own exec that sees the real client IP and inspects, rewrites, or blocks requests before they reach the service.
”Careful, don’t break anything”
Section titled “”Careful, don’t break anything””Caution is a cost like the others. Snapshot before anything risky: snapshots are incremental, so after the first one changed blocks consume new storage rather than another full copy, and a restore puts files, packages, and database rows back exactly as they were. To keep both versions, copy the container instead: an independent copy with its own URLs, on the same server or another.
The Mental Model covers the same ground as a working checklist: what to keep in your head, what to stop maintaining, and which service replaces which tool.
Hoody Agent
Section titled “Hoody Agent”Every container ships with Hoody Agent, an AI that runs where your work runs rather than in a chat window beside it: showing it a failing test involves no upload. It has 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. The split is why closing a window never costs a session.
Its tabs are grouped in three capsules:
AGENT Sessions | Chat | Agents | Skills | Workflows | Hooks | TODOsFLEET Computers | Files | Scripts | Domains | ConsoleSYSTEM Models | Settings | Vault | Memory | LogsYou never install it; it is already running on your server, with three entry points.
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, the same TUI character for character, not a port forward or a web rewrite.
An SSH client. From any machine that has one, including a phone’s terminal app:
ssh hoody.comTwo hops, nothing installed: a sandboxed Hoody CLI answers, signs you in, and hands you off to the Agent. Your token can also serve as the username:
ssh -tt hdy_xxxxxxxx@hoody.comThe CLI. From wherever you already work:
hoody agenthoody agent <container>The same binary answers in all three cases; in a browser, its chat pane can also hold a live web page when the agent needs to show you one. The model behind it is a setting: the built-in Hoody AI gateway serves 300+ models, you can bring your own keys from 100+ providers, and you can switch models mid-conversation or A/B test two models in two containers.
The same addresses for automation
Section titled “The same addresses for automation”Everything on this page was built to be opened by hand, and it is also an ordinary HTTP surface: whatever you can click you can also call from a script, a webhook, a bookmark, or any other tool. The same goes for AI: any tool that can fetch a URL works through the addresses you already use rather than a rebuilt or uploaded copy of your environment, and 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.
Pricing and the traffic path
Section titled “Pricing and the traffic path”Start on the free tier, a slice of a shared machine, and move to the bare metal marketplace when you want a physical machine allocated to you alone. On your own server there is no per-container fee, CPU-second charge, or per-request pricing: containers consume only the server’s capacity, so an experiment, a client demo, or an agent task can each have its own container. The free slice runs the same model with guardrails and never expires. Its current defaults are operator-configurable, not guarantees: 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 ceilings rise on hardware of your own.
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.com is a pure control plane: it creates machines and containers and writes policy, and it never proxies your traffic. The full picture, including what we can and cannot see, is in Security.
How the model fits together
Section titled “How the model fits together”Each capability on this page is the same decision applied to a different noun: the shell, the port, the session, and the script are each a URL, and the process never lived in your window. AI that needs no integration follows from all of it.
The resulting workflow
Section titled “The resulting workflow”Your server, your containers, and your agent keep running whether or not you are looking. When you want to look, you open a URL from any device. When you want company, you share the URL.
Next: The Mental Model → | The HTTP Revolution → | Security →