Every Hoody container includes 19 HTTP services for building, deploying, and operating software. They are already running when the container starts, so there is nothing to install or configure.
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 already running in every container, reaches all of them: open it in a browser tab, or type ssh hoody.com for the same agent in your terminal.
Each service is complete on its own and speaks HTTP, so any service can call any other:
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.
When you spawn a container with hoody_kit: true, you get URLs for all 19 services:
https://PROJECT-CONTAINER-terminal-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-display-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-files-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-sqlite-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-exec-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-browser-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-agent-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-code-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-curl-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-n-1.SERVER.containers.hoody.com # Notificationshttps://PROJECT-CONTAINER-daemon-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-cron-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-pipe-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-notes-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-watch-1.SERVER.containers.hoody.comhttps://PROJECT-CONTAINER-run-1.SERVER.containers.hoody.com # Runhttps://PROJECT-CONTAINER-logs-1.SERVER.containers.hoody.com # Proxy Logshttps://PROJECT-CONTAINER-tunnel-1.SERVER.containers.hoody.comThe services are running before your first request reaches them. Open a URL and use it.
Hoody Agent includes a Model Context Protocol (MCP) client that connects to external MCP servers and discovers their tools at runtime.
2024-11-05 through 2026-07-28 and negotiates the version with each server.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 →
Agent (WebOS)
Manage all containers, projects, and services from one browser interface.
Key capabilities:
Common uses: Project management, monitoring, client presentations
Terminals
Run shell commands over HTTP: the container’s Linux terminal as a web service, reachable from anywhere.
Key capabilities:
Common uses: Command execution, automation, remote server management, AI agent control
Displays
Remote desktop over HTTP: run graphical applications and see them in your browser, with nothing to configure.
Key capabilities:
display=5 on terminal-5 to connect to display-5)Common uses: Visual development tools, GUI applications, browser automation, design software
Files
Read, download, and manage files over HTTP across local storage and 60+ cloud providers.
Key capabilities:
Common uses: Cloud aggregation, download verification, cross-container file sharing
SQLite
Run SQLite queries and use a KV store through HTTP endpoints.
Key capabilities:
Common uses: Configuration management, feature flags, session storage, shared state
Exec
Turn a script file into an HTTP endpoint, with dependency management and AI generation.
Key capabilities:
Common uses: API endpoints, webhooks, automation, service customization
cURL
Make web requests from your container, with scheduling, sessions, and response storage.
Key capabilities:
Common uses: API integrations, web scraping, scheduled tasks, workflow automation
Browser
Control Chromium instances over a REST API for testing and automation.
Key capabilities:
Common uses: Web scraping, automated testing, screenshot services
Daemons
Manage long-running background services through an HTTP API.
Key capabilities:
Common uses: Background services, worker processes, monitoring daemons
Cron
Create, update, enable, disable, and auto-expire scheduled tasks through a REST API.
Key capabilities:
Common uses: Scheduled backups, periodic data processing, maintenance tasks, temporary monitoring
Notifications
Trigger desktop push notifications through HTTP endpoints.
Key capabilities:
Common uses: Build alerts, monitoring notifications, user engagement
Code
A full VS Code editor in the browser, reachable at a web URL.
Key capabilities:
Common uses: Web-based development, collaborative coding, mobile development
Pipe
Named pipes over the internet. Send to a path, receive from the same path, and the data streams through as it arrives.
Key capabilities:
openssl enc | curl -T -) for end-to-end secrecyCommon uses: Screen sharing, file transfers, live data piping, event forwarding, multiplayer collaboration
Notes
Realtime multi-user notes over HTTP, with inline databases and file attachments.
Key capabilities:
Common uses: Shared runbooks, team knowledge bases, embedded checklists
Watch
Watch paths recursively and stream the file system events over SSE or WebSocket.
Key capabilities:
Common uses: Build triggers, live reload, file-change-driven automation
Run
A multi-source app resolver. Query app names across Nix, pkgx, AppImage, Docker/OCI, and manifest registries, and get back the exact shell command.
Key capabilities:
Common uses: AI agent app discovery, portable install flows, cross-source launchers
Proxy Logs
Query and tail the Hoody Proxy access log for the container over HTTP.
Key capabilities:
Common uses: Debugging access issues, traffic analysis, audit trails
Tunnel
TCP tunneling over HTTP: expose local services online, or pull remote services into the container through the relay.
Key capabilities:
Common uses: Sharing local dev servers, bridging networks, remote access
Egress
The container’s outbound HTTP proxy: CONNECT for HTTPS, absolute-URI forwarding for plain HTTP, and optional chaining to an upstream proxy.
Key capabilities:
Common uses: Routing container traffic through a fixed exit IP, reaching APIs that allowlist an address
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.
Because everything speaks HTTP, everything composes:
// Terminal executes command that queries databasefetch(terminalUrl + '/api/v1/terminal/execute', { method: 'POST', body: JSON.stringify({ command: `curl -X POST ${sqliteUrl}/api/v1/sqlite/db?db=app -H 'Content-Type: application/json' -d '{"transaction":[{"statement":"SELECT * FROM users"}]}'` })});
// Exec script reads file, processes data, stores in databasefetch(execUrl + '/process-data.ts', { method: 'POST', body: JSON.stringify({ input_file: filesUrl + '/data/input.csv', output_db: sqliteUrl })});
// Agent orchestrates entire workflow across all services// 1. Create a sessionconst session = await fetch(agentUrl + '/api/v1/agent/sessions', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ realm: 'global' })}).then(r => r.json());
// 2. Dispatch a turn and block until it completes (:sync)fetch(agentUrl + `/api/v1/agent/sessions/${session.session_id}/prompt:sync`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ text: "Deploy the app using terminal, monitor with browser, store logs in database" })});Each service is independent, and together they make up a complete development environment.
The 19 services fall into 4 groups:
Services you use to see and control your containers:
Services that store and return information:
Services that run code and coordinate systems:
Services that manage and observe what is running:
Most services can run several instances in the same container:
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...daemon-1, daemon-2, daemon-3...cron-1, cron-2, cron-3...code-1, code-2, code-3...pipe-1, pipe-2, pipe-3...Typical uses:
All instances share the same container filesystem, processes, and network. It is one computer with multiple access points.
# Type in terminal-5terminal-5.hoody.com → firefox &
# See in display-5 (terminal-5 was created with display=5)https://PROJECT-CONTAINER-display-5.SERVER.containers.hoody.com → Firefox appearsGUI applications appear in the display configured for that terminal session.
# Terminal with embedded agent panelterminal-1.hoody.com/?panel=...agent-1.hoody.com&panel-width=40%The AI assistant helps with commands, explains output, and suggests approaches, all in one window.
// Read CSV from cloud storageconst data = await fetch(filesUrl + '/google-drive/data.csv');
// Process with exec scriptconst processed = await fetch(execUrl + '/etl.ts', { method: 'POST', body: data});
// Store in SQLiteawait fetch(sqliteUrl + '/api/v1/sqlite/db?db=analytics', { method: 'POST', body: JSON.stringify({ transaction: [{ statement: 'INSERT INTO analytics VALUES (...)' }] })});// Agent has access to all container services// 1. Create a sessionconst session = await fetch(agentUrl + '/api/v1/agent/sessions', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ realm: 'global' })}).then(r => r.json());
// 2. Dispatch a turn and block to completion (:sync).// ?policy=auto_approve auto-answers confirm gates for hands-off automation.const agent = await fetch(agentUrl + `/api/v1/agent/sessions/${session.session_id}/prompt:sync?policy=auto_approve`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ text: "Set up production environment" })});
// Agent coordinates:// 1. Terminal - Install dependencies// 2. Files - Download config from cloud// 3. SQLite - Initialize database schema// 4. Exec - Run deployment script// 5. Notifications - Alert when completeOne task description drives multiple services.
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 browserhttps://PROJECT-CONTAINER-terminal-1.SERVER.containers.hoody.com → Run builds and testshttps://PROJECT-CONTAINER-display-1.SERVER.containers.hoody.com → Preview GUI applicationsManaging 10+ projects means switching between terminals, editors, and databases. A workspace shows every project at once, with each service one click away:
Workspace shows all projects ├─ Project A: terminal-1, display-1, sqlite-1 (frontend app) ├─ Project B: terminal-1, agent-1, exec-1 (API service) ├─ Project C: browser-1, curl-1, sqlite-1 (scraper) └─ Project D: terminal-1, code-1, files (docs site)AI agents normally cannot install tools or reach infrastructure. Here the agent has HTTP access to every service:
agent-1.hoody.com → AI has HTTP access to: ├─ terminal (execute commands) ├─ files (read/write code) ├─ exec (run scripts) ├─ sqlite (manage state) └─ browser (test web apps)The AI orchestrates the development workflow over HTTP, and a human approves critical decisions.
To share a development environment with a team across time zones, share the workspace URL; everyone works in the same environment, from anywhere:
# Share workspace URL with teamhttps://PROJECT_ID-CONTAINER_ID-agent-1.node-us-1.containers.hoody.com
# Team sees:- Live terminal sessions (multiplayer)- Shared displays (see what others see)- Common file access- Shared database stateAfter you spawn a container, there are three ways to find its service URLs.
When you create a container, the response includes the server details:
{ "data": { "id": "def456", "project_id": "abc123", "server_name": "node-us-1", "status": "running" }}Construct URLs:
https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us-1.containers.hoody.comhttps://PROJECT_ID-CONTAINER_ID-display-1.node-us-1.containers.hoody.comOpen the Agent, select your container, and every service URL is listed with a copy button.
GET /api/v1/containers/{id}Returns full container details including project_id, id, and server_name, which are the fields you need to construct service URLs.
Prefer exec when the job deserves a script: cd /app && npm test && echo "done" through terminal.run/execute works, but exec.run/test-runner.ts gets you logging, error handling, and structure. Prefer the terminal when the job is one command: creating an exec script just to run ls -la is overhead, so send {"command": "ls -la"} to terminal.run/execute instead.
Give instances semantic meaning:
terminal-1 → Frontend workterminal-2 → Backend workterminal-3 → Database managementterminal-4 → DevOps/deployment
agent-1 → Code and testsagent-2 → Documentationagent-3 → Infrastructure
exec-1 → API endpointsexec-2 → Scheduled tasksexec-3 → Data processingServices do more in pairs:
For cross-container workflows:
/hoody/shares/: files accessible from all containers/hoody/databases/: SQLite databases accessible from all containersSee Shared Storage → and SQLite Drive →
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.
Currently, all services come together. Unused services activate only when accessed, so a terminal service that never receives requests uses almost no CPU or memory.
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.
Yes. Terminals and Displays support multiplayer, so several users can type in the same terminal or watch the same desktop. Other services (Files, SQLite, Exec) are accessible simultaneously with standard HTTP concurrency.
Snapshots capture the complete container state, including all services and their data. When you restore a snapshot, all services come back exactly as they were, including terminal history, file contents, database state, and daemon configurations.
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 or SQLite Drive (/hoody/databases/) for database sharing across containers.
All of them. Every service is web-native:
This is how you build custom dashboards: compose service iframes.
https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us.containers.hoody.com returns 404. The usual causes:
GET /api/v1/containers/{id}.To diagnose:
# Verify container is runningcurl "https://api.hoody.com/api/v1/containers/{container_id}" \ -H "Authorization: Bearer $HOODY_TOKEN" | jq '.data.status'
# Check server name matches# Should be: node-us-1, node-eu-1, etc. (check container response)
# Verify proxy permissions allow accesscurl "https://api.hoody.com/api/v1/containers/{container_id}/proxy/permissions" \ -H "Authorization: Bearer $HOODY_TOKEN"Service URLs respond slowly. The usual causes:
To diagnose:
# Check server resource usagecurl "https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us-1.containers.hoody.com/api/v1/system/resources"
# Check running processescurl "https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us-1.containers.hoody.com/api/v1/system/processes?sort=cpu"
# Consider moving to less loaded server or upgrading server resourcesA 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:
# 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.PATCH /api/v1/containers/{id}/proxy/permissions/defaultIf-Match: file:v3
{ "default": "allow"}See Proxy Permissions → for access control details.
Explore individual services:
Understand the platform:
For the complete technical specs: