The Vibe

Your laptop is a viewport. Your server is the computer.

Every process you run — terminals, GUIs, databases, AI agents, cron jobs, file browsers, code editors — gets an HTTPS URL the moment it starts. No certificates. No ports. No reverse proxies. HTTP/2 and HTTP/3, automatically, forever. Share the URL and someone else is looking at it. Embed it in an iframe and it’s part of a dashboard. Call it from curl and it’s an API.

The sibling pages explain the architecture. This one describes what it’s like to actually work this way — a normal day, hour by hour, on infrastructure where everything answers over HTTP.

The Primitive: URLs

Spawn one Kit container and it comes up with eighteen services, each already listening at its own URL:

https://{projectId}-{containerId}-terminal-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-display-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-files-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-sqlite-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-exec-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-browser-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-agent-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-code-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-curl-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-n-1.{server}.containers.hoody.icu         # notifications
https://{projectId}-{containerId}-daemon-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-cron-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-pipe-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-notes-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-watch-1.{server}.containers.hoody.icu
https://{projectId}-{containerId}-run-1.{server}.containers.hoody.icu       # app launcher
https://{projectId}-{containerId}-logs-1.{server}.containers.hoody.icu      # proxy access logs
https://{projectId}-{containerId}-tunnel-1.{server}.containers.hoody.icu

One grammar carries all of it: project, container, service, instance, server. Instances start at 1, and most services let you run several side by side — terminal-2 for the backend, display-2 for a second desktop, sqlite-3 for the scraper’s scratch data. Anything you start yourself answers at http-{port}. The only thing that lives elsewhere is the control plane: api.hoody.icu is where you create containers; these URLs are the containers.

Run a process, it gets a URL. Share the URL, someone joins you. Embed it, it’s part of something bigger. Call it, it’s an API. That’s the entire model — the rest of this page is just that one fact colliding with an ordinary workday. See The Hoody Kit for what each service does.

Morning: Screens You Can Hand to Anyone

Every GUI application in your container — Firefox, Blender, a full Linux desktop — streams live at its display URL. Not a screenshot, not a recording: the real session, interactive, in a browser tab. Pair a terminal with a display (start terminal-5 with display=5) and whatever you launch from that shell appears on that screen. Staging on display-1, the release candidate on display-2 — two isolated worlds in adjacent tabs, zero interference.

So the morning design review isn’t a calendar event with screen-share ceremony. You paste the display URL into the channel. The designer opens it on their monitor, the PM opens it on their phone, and everyone is looking at the same running app — because they’re literally connected to the same session, not a video of it.

What displays do for the server, hoody-pipe does for everything else. It’s a named pipe over the internet: send bytes to a path, anyone reading that path receives them in real time. Your laptop screen, a phone camera, a file mid-transfer, a build log — one sender fans out to up to 256 receivers, and spectators can follow transfer progress over SSE without taking a receiver slot.

Debugging with a colleague in another timezone? Pipe your screen to a URL, they open it from wherever they are, and you both type into the same terminal URL to fix it. Nobody installed anything, on either end.

Afternoon: The Agent Rides the Same Rails

The AI agent built into every container doesn’t get a special integration layer. It gets what you get — the URLs:

GET /api/v1/terminal/raw          # what happened in the shell
GET /api/v1/display/screenshot    # what's on the screen
GET /api/v1/files/{path}          # what's in the repo
GET /api/v1/sqlite/query          # what's in the database
GET /api/v1/browser/health        # whether the test browser is up

That symmetry is the whole trick. When you ask it to chase a failing test, it reads the terminal output you’d read, opens the file you’d open, screenshots the display you’d squint at — then runs the fix in a terminal you can watch. It can spawn fresh containers for experiments and hand subtasks to agents running in them, because container creation is just another HTTP call. There’s no boundary between “AI tooling” and “your environment”; there’s one protocol and everything speaks it.

The model behind the agent is a config value, not a commitment. The built-in Hoody AI gateway serves 300+ models, and you can bring your own from 100+ providers — Anthropic, OpenAI, Google, Mistral, a local Ollama, any OpenAI-compatible endpoint. Switch mid-conversation. A/B test two models in two containers. Today’s frontier model, next month’s, your own fine-tune: a config change, never a migration.

And it isn’t only your agent. Give any AI on the internet the address @hoody.com — ChatGPT, Claude, Codex, anything that can fetch a URL — and it downloads a Skill: a structured HTTP map of your entire infrastructure. No MCP server to host, no plugin to install.

ssh hoody.com  →  any human, any terminal, full environment
@hoody.com     →  any AI, any platform, full environment

Same portability, different era.

Night: It Reaches You, You Reach It

Your environment doesn’t stop when you close the lid — it runs 24/7, and notifications are how it gets your attention. A container posts to its notification URL; the message surfaces as a desktop notification on subscribed displays and streams over WebSocket to whatever dashboard you left open. The useful part is that notifications carry URLs, so the path from “something happened” to “I’m looking at it” is one click.

The 45-minute build finishes while you’re at dinner: “Build complete. 3 warnings. Preview: [URL].” You tap, you see the live app, you tell the agent to ship it. A production alert lands at 2am: tap, terminal URL, three commands, back to sleep. No laptop retrieved, no VPN dance, no SSH keys hunted down.

This is also why “did you bring your laptop?” stops meaning anything. Nothing lives on the laptop. Your processes, files, databases, AI conversations — all of it is already running at URLs on your server. Lose the device, borrow any other one, log in: everything is exactly where it was, because it never moved.

The OS Is Just Windows Around URLs

Hoody Agent — the terminal-native AI agent in every container — is the working surface over all of this. Its FLEET capsule is your machines: live terminals and filesystems beside each computer, published scripts, domains, and the platform console. And because every kit service embeds in an iframe, any dashboard you assemble yourself is just windows onto service URLs.

Ask it for an app — the run service resolves the name across Nix, pkgx, AppImage, and Docker/OCI registries, and it’s running in a display before you’d have finished reading an install guide.

The front doors are addresses too: os.hoody.com signs you in and opens your container’s agent full-bleed in the browser. And from any machine with an SSH client:

ssh hoody.com

That’s the same agent as a TUI — the gateway answers with a sandboxed Hoody CLI that signs you in and launches hoody agent. Login, then your full environment, from a Raspberry Pi, a datacenter box with no GUI, or a phone’s terminal app.

Screenshot Needed The Hoody Agent TUI in a browser tab — AGENT, FLEET, and SYSTEM tab capsules over a multi-pane chat grid, beside a live terminal and file view

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

The Ground It Stands On

All of this runs on a machine that is actually yours. Marketplace servers are physical bare metal — no shared hypervisor, no other tenants’ workloads, no noisy neighbors. The proxy that mints every URL on this page runs on that server, so your traffic resolves straight to that machine — there is no central Hoody proxy tier in the path. The API at api.hoody.icu sees management operations, and nothing else.

That matters more now than it ever did. In the AI era you routinely execute code you haven’t fully read. Here, each experiment and each agent task gets its own container on hardware you control, and you snapshot before anything risky — restore takes seconds if it goes sideways.

The economics land the same way. The VPS model charges per isolated box: dev, staging, and production is $120/month of machines idling 90% of the time. On Hoody, containers cost nothing once the server exists — so you stop rationing them. A container per experiment. A container per AI task. A disposable demo environment per client. The marginal cost of “just spin one up” hits zero, and that changes how you work more than it changes your bill.

The Vibe

No installation. No sync. No “works on my machine.” No certificate headaches. No deployment rituals.

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

Everything you need. Nothing installed. From anywhere. On anything. Your server. Your privacy. Your URLs.

Next: Understanding Hoody → | The HTTP Revolution → | The Embeddability Revolution →