Every Hoody container includes 19 HTTP services for building, deploying, and operating software. They are provisioned when the container starts, so there is nothing to install or configure. Most of them start on the first request that reaches their URL; Terminal, Cron, Watch and Egress run from container boot.
Each service is a URL. That URL opens in a browser on a laptop or a phone, embeds in an iframe, goes to a teammate in a chat message, and can be called by an AI. Hoody Agent, the terminal-native AI agent that ships in every container and starts on your first request to it, reaches all of them: open it in a browser tab, or type ssh hoody.com for the same agent in your terminal.
Screenshot Coming Soon
Hoody Agent running as a terminal-native TUI in a browser tab, with a multi-pane chat grid beside live terminals, files, and a display preview
Multiple services visible at once through the Hoody Agent
Each service is complete on its own and speaks HTTP, so any service can call any other:
Terminals execute any command. Pair one with Displays and GUI applications appear in the browser.
Files reaches any storage. Combine it with SQLite for indexed metadata, or Exec for automated processing.
Agent orchestrates workflows. Give it Terminal access and it drives the rest of your infrastructure.
Browser automates web tasks. Combine it with cURL for API calls and SQLite for storing results.
One service handles a task; two or more compose into a workflow. Because the interface is HTTP rather than a fixed feature list, the combinations available to you are not limited to the ones documented here. Each service is a primitive, and what you build out of them is your decision.
https://PROJECT-CONTAINER-egress.SERVER.containers.hoody.com # Egress — one proxy per container; the index is optional and defaults to 1
Nothing here needs installing or starting by hand. Most of these services, Hoody Agent among them, start on the first request that reaches their URL; Terminal, Cron, Watch and Egress run from container boot instead. Either way you do nothing: open a URL and use it. Daemon and Proxy Logs are the two exceptions to the pattern, because neither is a program the daemon supervises: Daemon runs as a systemd unit and Proxy Logs is served by the proxy.
The container catalogue registers a few further service slugs that are not counted among the 19, because each one is a companion to a service above rather than a service of its own: desktop opens the terminal kit in a desktop session, cdp is the Chrome DevTools Protocol endpoint paired with a Browser instance, and d-tcp is direct TCP access to a display rather than an HTTP service. Two more are registered but not documented on this page: workspaces, and bot, which is only present when the container image is built with the bot enabled.
Hoody Agent includes a Model Context Protocol (MCP) client that connects to external MCP servers and discovers their tools at runtime.
Dynamic tool discovery: the number of available tools depends on which MCP servers you connect. There is no fixed list.
Local and remote servers: local servers over stdio, remote servers over Streamable HTTP or the legacy HTTP+SSE transport.
Spec coverage: built on the official Go SDK. It speaks every revision from 2024-11-05 through 2026-07-28 and negotiates the version with each server.
Managed in place: add, import, enable, disable and reconnect servers from the agent’s Agents ▸ MCP servers mode or over HTTP. There is no settings file to hand-edit and no session to restart. Paste a config from Claude, Cursor or VS Code and it is understood; imported servers land disabled until you review them.
Credentials stay deliberate: a stdio server starts with your provider keys and platform token scrubbed out of its environment, and you share one by naming it. Destructive operations still require confirmation.
An MCP server you configure runs with your privileges, on the same footing as a shell command you run yourself, so add only servers you trust. Full details on the Agent page →
Realtime multi-user notes over HTTP, with inline databases and file attachments.
Key capabilities:
Realtime multi-user editing
Inline tables / databases
File attachments per note
REST + WebSocket API
Permissions are checked again when each write is saved, so many clients and scripts can write at once safely: a write whose author lost access before it saved is refused and nothing is stored (sync batches report refusals per item). Only notebook owners can grant or change the owner role.
Common uses: Shared runbooks, team knowledge bases, embedded checklists
Installing tools locally means setup, configuration, dependencies, and compatibility checks on each machine, repeated every time you switch computers. On Hoody each tool is a URL: open it and the tool is there, on any device with a browser, including a phone, tablet, laptop, or TV.
Open the terminal URL for a shell, the SQLite URL for a database, the code URL for VS Code. Nothing is downloaded, installed, or configured on the device you are working from.
Most services can run several instances in the same container. For the daemon service the number makes no difference: there is one daemon per container, and daemon-1, daemon-2 or any other number reach that same daemon and its program list. To run several copies of your own program, give it a port_range.
terminal-1, terminal-2, terminal-3, terminal-4...
display-1, display-2, display-3, display-4...
exec-1, exec-2, exec-3...
sqlite-1, sqlite-2, sqlite-3...
browser-1, browser-2, browser-3...
curl-1, curl-2, curl-3...
cron-1, cron-2, cron-3...
code-1, code-2, code-3...
pipe-1, pipe-2, pipe-3...
SQLite is like the daemon: sqlite-1, sqlite-2 or any other number reach the same SQLite service, and the db query parameter selects the database. Pipe is the same: pipe-1, pipe-2 or any other number reach one pipe service, so use different pipe names for separate transfers.
Typical uses:
Separation of concerns: terminal-1 for frontend, terminal-2 for backend, terminal-3 for the database
Parallel operations: run tests in exec-1 while building in exec-2
Specialized agents: agent-1 for code, agent-2 for docs, agent-3 for DevOps
Multi-user collaboration: each user gets their own terminal or display instance
All instances share the same container filesystem, processes, and network. It is one computer with multiple access points.
VS Code requires a desktop OS, which normally rules out coding from a phone or tablet. The code, terminal, and display URLs put the whole development environment in a mobile browser:
https://PROJECT-CONTAINER-code-1.SERVER.containers.hoody.com → Full VS Code in mobile browser
https://PROJECT-CONTAINER-terminal-1.SERVER.containers.hoody.com → Run builds and tests
Managing 10+ projects means switching between terminals, editors, and databases. A workspace shows every project at once, with each service one click away:
Prefer Exec when the job deserves a script: run cd /app && npm test && echo "done" by POSTing {"command":"cd /app && npm test && echo \"done\""} as JSON to /api/v1/terminal/execute on the desired terminal-N service URL, but POSTing to /test-runner.ts on the desired exec-N service URL gets you logging, error handling, and structure. Prefer Terminal when the job is one command: creating an Exec script just to run ls -la is overhead, so POST {"command":"ls -la"} as JSON to /api/v1/terminal/execute on the desired terminal-N service URL instead.
Yes, when you create a container with hoody_kit: true. If you set hoody_kit: false, you get a plain Linux container without these HTTP services (SSH access only), which suits minimal containers and custom setups.
Yes. The Kit services the daemon supervises are daemon programs, so you can stop or disable one through the Daemon API like any other program. Daemon itself and Proxy Logs are not. Most of them start only when first accessed, so a service that never receives requests uses almost no CPU or memory. Terminal, Cron, Watch and Egress run from container boot.
How do services communicate within the same container?
They share the same filesystem, processes, and network. A file created via the Files service is immediately readable via Terminal. A database created via SQLite is accessible from Exec scripts. They’re all running on the same Linux computer.
Can multiple users access the same service at once?
Yes. Terminals and Displays support multiplayer, so several users can type in the same terminal or use the same desktop. Other services (Files, SQLite, Exec) are accessible simultaneously with standard HTTP concurrency.
What happens to services when I snapshot a container?
Snapshots capture the container filesystem: file contents, on-disk database state, daemon configuration, and terminal history that has been written to disk. They do not capture RAM, running processes, or in-flight connections, so restoring starts the container from that filesystem instead of resuming it mid-execution.
Do I need different authentication for each service?
No. Proxy permissions control access to all services in a container. Set permissions once at the project or container level, and they apply to terminals, displays, files, SQLite, exec, and the rest.
Yes. Containers on the same server can communicate via internal networking. Use Shared Storage (/hoody/shares/) for file sharing. For a database, call the SQLite service of the container that owns it; /hoody/databases/ is local to each container.
The proxy adds the iframe headers (Content-Security-Policy: frame-ancestors and Cross-Origin-Resource-Policy) to the browser pages of the terminal, desktop, display, browser, code, files, notes, SQLite, notifications, pipe, cron, bot, Hoody Run, watch and exec services. On the Agent service only the web UI gets them. A page your own application serves on an http-{port} or https-{port} URL keeps the headers the application sends, and the chat bot’s sign-in and secret-entry pages still refuse to be framed. The cURL service has no page to frame and gets no iframe headers.
Terminals → embed a live shell
Desktop → embed a full graphical desktop
Displays → embed a display in the web viewer
Files → embed a file browser or editor
Code → embed VS Code
Browser → embed a live browser view
SQLite → embed the database overview, tables and query pages
Notes → embed a notebook
Embed URLs lists every page you can frame, with its parameters, and hoody.embeds in the SDK builds those URLs.
This is how you build custom dashboards: compose service iframes.
A service works from your laptop but not from a phone or public WiFi. This usually means proxy permissions restrict access by IP or require authentication. To open access:
Terminal window
# Check current permissions (note the file_version for the If-Match header)
GET/api/v1/containers/{id}/proxy/permissions
# Remove the IP restriction by opening the default policy to "allow".
# Write operations require the If-Match: file:v<current file_version> header.
