Every Hoody container includes 18 HTTP services — your complete toolkit for building, deploying, and operating software. No installation. No configuration. Just instant HTTP access to everything you need.
The revolutionary part: Each service is a URL. Open it in a browser. Use it from your phone. Embed it in an iframe. Share it with a teammate. Control it via AI. Access it all through Hoody OS — a floating-window web-based operating system that lives inside each of your containers — or type ssh hoody.com for the same OS in your terminal. Everything is accessible because everything is HTTP.
These 18 services unlock unlimited potential—not through rigid feature sets, but through creative combination.
Each service is designed to be complete on its own while composing naturally with others:
The pattern: One service enables the task. Two services multiply capability. Three or more services create workflows impossible on traditional platforms.
You’re not limited to “supported features.” With HTTP as the universal interface, every service can talk to every other service. Build workflows we never imagined—because the tools compose infinitely through HTTP.
This is intentional. Each service is a primitive. Your creativity determines what they become.
When you spawn a container with hoody_kit: true, you immediately get URLs for all 18 services:
https://PROJECT-CONTAINER-terminal-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-display-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-files-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-sqlite-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-exec-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-browser-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-workspaces-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-code-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-curl-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-n-1.SERVER.containers.hoody.icu # Notificationshttps://PROJECT-CONTAINER-daemon-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-cron-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-pipe-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-notes-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-watch-1.SERVER.containers.hoody.icuhttps://PROJECT-CONTAINER-run-1.SERVER.containers.hoody.icu # Runhttps://PROJECT-CONTAINER-logs-1.SERVER.containers.hoody.icu # Proxy Logshttps://PROJECT-CONTAINER-tunnel-1.SERVER.containers.hoody.icuNo setup. No installation. Already running. Just use the URLs.
Hoody Agent includes a production-ready Model Context Protocol (MCP) client that connects to external MCP servers, dynamically discovering their tools at runtime.
🖥️ Workspaces (Hoody UI)
Your floating operating system—manage all containers, projects, and services from one browser interface.
Key Capabilities:
Perfect for: Project management, monitoring, client presentations
🔤 Terminals
Execute shell commands via HTTP—your Linux terminal as a web service, accessible from anywhere.
Key Capabilities:
Perfect for: Command execution, automation, remote server management, AI agent control
🖼️ Displays
Remote desktop via HTTP—run graphical applications and see them in your browser. Zero configuration.
Key Capabilities:
Perfect for: Visual development tools, GUI applications, browser automation, design software
📂 Files
Unified file access via HTTP—read, download, and manage files across local storage and 60+ cloud providers.
Key Capabilities:
Perfect for: Cloud aggregation, download verification, cross-container file sharing
🗄️ SQLite
Database via HTTP—SQLite queries and KV store accessible through HTTP endpoints.
Key Capabilities:
Perfect for: Configuration management, feature flags, session storage, shared state
⚡ Exec
Execute any script via HTTP—turn code into instant API endpoints with dependency management and AI generation.
Key Capabilities:
Perfect for: API endpoints, webhooks, automation, service customization
🌐 cURL
HTTP requests as a service—make web requests from your container with scheduling, sessions, and storage.
Key Capabilities:
Perfect for: API integrations, web scraping, scheduled tasks, workflow automation
🌍 Browser
Chrome automation via HTTP—control Chromium instances through REST API for testing and automation.
Key Capabilities:
Perfect for: Web scraping, automated testing, screenshot services
⚙️ Daemons
Process management via HTTP—manage long-running background services through HTTP API.
Key Capabilities:
Perfect for: Background services, worker processes, monitoring daemons
🕐 Cron
Managed cron jobs via HTTP—create, update, enable/disable, and auto-expire scheduled tasks through a REST API.
Key Capabilities:
Perfect for: Scheduled backups, periodic data processing, maintenance tasks, temporary monitoring
🔔 Notifications
Push notifications via HTTP—trigger desktop/mobile notifications through HTTP endpoints.
Key Capabilities:
Perfect for: Build alerts, monitoring notifications, user engagement
💻 Code
VS Code in browser via HTTP—full-featured code editor accessible through web URL.
Key Capabilities:
Perfect for: Web-based development, collaborative coding, mobile development
📡 Pipe
Streaming data transfer over HTTP—named pipes over the internet. Send to a path, receive from the same path, data flows through in real-time.
Key Capabilities:
openssl enc | curl -T -) for end-to-end secrecyPerfect for: Screen sharing, file transfers, live data piping, event forwarding, multiplayer collaboration
📝 Notes
Collaborative notes via HTTP—realtime multi-user notes, inline databases, and file attachments.
Key Capabilities:
Perfect for: Shared runbooks, team knowledge bases, embedded checklists
👁️ Watch
File system watchers via HTTP—recursive path monitoring streamed over SSE or WebSocket.
Key Capabilities:
Perfect for: Build triggers, live reload, file-change-driven automation
🚀 Run
Multi-source app resolver—query app names across Nix, pkgx, AppImage, Docker/OCI, and manifest registries; get back the exact shell command.
Key Capabilities:
Perfect for: AI agent app discovery, portable install flows, cross-source launchers
📜 Proxy Logs
Access logs from Hoody Proxy via HTTP—query and tail the request log for the container.
Key Capabilities:
Perfect for: 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:
Perfect for: Sharing local dev servers, bridging networks, remote access
Traditional approach: Install tools on your computer. Each requires setup, configuration, dependencies, compatibility checks. Switching computers means reinstalling everything.
Hoody approach: Everything is a URL. Open the URL, you have the tool. Works on any device with a browser—phone, tablet, laptop, or TV.
Need a terminal? Open the terminal URL.
Need a database? Open the SQLite URL.
Need VS Code? Open the code URL.
No installation. No configuration. Just URLs.
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":[{"query":"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 servicesfetch(agentUrl + '/api/v1/agent/prompt', { method: 'POST', body: JSON.stringify({ ai: "Deploy the app using terminal, monitor with browser, store logs in database", wait: true })});Each service is independent. Together, they’re a complete development environment.
The 18 services organize into 4 logical groups:
See and control your containers:
Store and access information:
Run code and coordinate systems:
Manage and observe systems:
Here’s the power: You can run multiple instances of most services 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...Why this matters:
All instances share the same container filesystem, processes, and network—it’s one computer with multiple access points.
# Type in terminal-5terminal-5.hoody.icu → firefox &
# See in display-5 (auto-mapped)display-5.hoody.icu → Firefox appearsGUI applications automatically appear in matching display numbers. Zero configuration.
# Terminal with embedded agent panelterminal-1.hoody.icu/?panel=...workspaces-1.hoody.icu&panel-width=40%AI assistant helps with commands, explains output, suggests best practices—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 (...)' }] })});Services compose naturally through HTTP.
// Agent has access to all container servicesconst agent = await fetch(agentUrl + '/api/v1/agent/prompt', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ ai: "Set up production environment", wait: true })});
// 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. Multiple services orchestrated.
Problem: Need to code from your phone/tablet but VS Code requires desktop OS.
Solution:
code-1.hoody.icu → Full VS Code in mobile browserterminal-1.hoody.icu → Run builds and testsdisplay-1.hoody.icu → Preview GUI applicationsYour complete development environment, accessible from any device.
Problem: Managing 10+ projects switching between terminals, editors, databases.
Solution:
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)One workspace. All projects visible. Click to access any service instantly.
Problem: AI agents can’t install tools or access infrastructure.
Solution:
workspaces-1.hoody.icu → AI has HTTP access to: ├─ terminal (execute commands) ├─ files (read/write code) ├─ exec (run scripts) ├─ sqlite (manage state) └─ browser (test web apps)AI orchestrates entire development workflow via HTTP. Human approves critical decisions.
Problem: Share development environment with team across time zones.
Solution:
# Share workspace URL with teamhttps://abc123-def456-workspaces-1.node-us-1.containers.hoody.icu
# Team sees:- Live terminal sessions (multiplayer)- Shared displays (see what others see)- Common file access- Shared database stateEveryone works in the same environment, from anywhere.
How to find service URLs after spawning a container:
When you create a container, the response includes server details:
{ "data": { "id": "def456", "project_id": "abc123", "server_name": "node-us-1", "status": "running" }}Construct URLs:
https://abc123-def456-terminal-1.node-us-1.containers.hoody.icuhttps://abc123-def456-display-1.node-us-1.containers.hoody.icuOpen Workspaces, select your container, see all service URLs with copy buttons.
GET /api/v1/containers/{container_id}Returns full container details including computed service URLs.
Don’t use a terminal when exec makes more sense:
terminal.run/execute → cd /app && npm test && echo "done"exec.run/test-runner.ts → Clean script with logging, error handling, proper structureDon’t use exec when terminal is simpler:
ls -laterminal.run/execute → {"command": "ls -la"}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 work better together:
For cross-container workflows:
/hoody/shared/ → 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)—useful for minimal containers or custom setups.
Currently, all services come together. However, unused services consume minimal resources (they only activate when accessed). A terminal service that never receives requests uses almost no CPU/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—multiple users typing in the same terminal or seeing 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—terminal history, file contents, database state, daemon configurations.
No. Proxy permissions control access to ALL services in a container. Set permissions once at the project or container level, and it applies to terminals, displays, files, SQLite, exec, etc.
Yes. Containers on the same server can communicate via internal networking. Use Shared Storage (/hoody/shared/) 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.
Problem: https://abc123-def456-terminal-1.node-us.containers.hoody.icu returns 404
Causes:
GET /api/v1/containers/{id}Solutions:
# Verify container is runningcurl "https://api.hoody.icu/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.icu/api/v1/containers/{container_id}/proxy/permissions" \ -H "Authorization: Bearer $HOODY_TOKEN"Problem: Service URLs are very slow to respond
Causes:
Solutions:
# Check server resource usagecurl "https://abc123-def456-terminal-1.node-us.containers.hoody.icu/api/v1/system/resources"
# Check running processescurl "https://abc123-def456-terminal-1.node-us.containers.hoody.icu/api/v1/system/processes?sort=cpu"
# Consider moving to less loaded server or upgrading server resourcesProblem: Service works from laptop but not from phone/public WiFi
Cause: Proxy permissions restrict access by IP or require authentication
Solution:
# Check current permissionsGET /api/v1/containers/{id}/proxy/permissions
# Update to allow your IP or remove IP restrictionsPUT /api/v1/containers/{id}/proxy/permissions{ "groups": {}, "permissions": {}, "default": "deny"}See Proxy Permissions → for access control details.
Explore individual services:
Understand the platform:
See complete technical specs:
The Hoody Kit turns every container into a complete computing environment.
18 HTTP services. Zero installation. Infinite possibilities.
Everything you need, accessible via URL.