The HTTP Mindset

Every terminal, file, database, desktop, browser, script, and background service in Hoody is an HTTP endpoint. Not an API wrapper sitting in front of another protocol: the endpoint is the service. Your whole computing stack speaks one language, and fetch is enough to drive all of it.

Anything that can make an HTTP request can therefore control any computing resource you have: a CI/CD pipeline, a webhook, a browser extension, a phone, an AI agent, or a curl command from any terminal anywhere. That also removes the client software each of the old protocols required: you install no SSH client, FTP client, VNC viewer, database GUI, or proprietary SDK, because every one of those jobs is an HTTPS request.

---

One protocol for every service

Traditional infrastructure requires a different protocol for each task:

Task	Legacy Protocol	Tools Required
Shell access	SSH	ssh client, key management
File transfer	SFTP/SCP	sftp client, scp, rsync
Desktop access	VNC/RDP	VNC viewer, RDP client
Database	PostgreSQL/MySQL wire protocol	psql, mysql CLI, GUI client
Process management	systemd/init over SSH	SSH + systemctl
Scheduled tasks	cron over SSH	SSH + crontab

Each protocol has its own authentication, encryption, tooling, and failure modes. Every one of them is another surface to secure and another dependency to install and keep working.

In Hoody, every row collapses to one:

Task	Protocol	Tool Required
Shell access	HTTPS	fetch or curl
File access	HTTPS	fetch or curl
Desktop access	HTTPS	A browser
Database	HTTPS	fetch or curl
Process management	HTTPS	fetch or curl
Scheduled tasks	HTTPS	fetch or curl
Script execution	HTTPS	fetch or curl
Browser automation	HTTPS	fetch or curl
AI orchestration	HTTPS	fetch or curl
Desktop notifications	HTTPS	fetch or curl

That leaves one protocol, one authentication model, and one way to monitor, log, and debug.

---

Service URLs and fetch calls

Every service in a Hoody container lives at a predictable URL:

https://{projectId}-{containerId}-{service}-{instance}.{serverName}.containers.hoody.com

A developer’s day, when everything is HTTP, looks like this:

const BASE = 'https://abc123-def456';
const NODE = 'node-us-1.containers.hoody.com';

// Run a build command
await fetch(`${BASE}-terminal-1.${NODE}/api/v1/terminal/execute`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ command: 'npm run build', wait: true })
});

// Read a config file
const config = await fetch(`${BASE}-files-1.${NODE}/api/v1/files/home/app/config.json`);

// Query the database
const users = await fetch(`${BASE}-sqlite-1.${NODE}/api/v1/sqlite/db?db=app`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ transaction: [{ query: 'SELECT * FROM users WHERE active = 1' }] })
});

// Take a screenshot of the desktop
const screenshot = await fetch(`${BASE}-display-1.${NODE}/api/v1/display/screenshot`);

// Send a notification
await fetch(`${BASE}-n-1.${NODE}/api/v1/notifications/notify`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ display: '1', summary: 'Build complete', body: 'Deployed successfully' })
});

// SSH into a remote server over HTTP (no SSH client needed)
await fetch(`${BASE}-terminal-2.${NODE}/api/v1/terminal/execute?ssh_host=prod.example.com&ssh_user=admin&ssh_password=hunter2`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ command: 'systemctl status nginx', wait: true })
});

None of it requires a setup step, an installed client, or a configuration file. Every one of those URLs is HTTPS with HTTP/2 and HTTP/3, on servers you own. The same calls work from a Node.js script, a Python notebook, a GitHub Action, a Zapier trigger, an AI agent, or Hoody Agent, the built-in agent that drives all of these services from a terminal tab in your browser. ssh hoody.com still works if you prefer a shell, but nothing on this page needs it.

Screenshot Coming Soon A developer's day: terminal executing a build, file browser showing config, SQLite query results, and a notification popup, all as HTTP requests

A developer's day when everything is HTTP

Notice the last example: a regular HTTP POST ran a command on a different server over SSH. The container acts as an HTTP-to-SSH bridge, so you can manage any server from any device that speaks HTTP, including a phone.

---

Integration without SDKs

Connecting system A to system B usually means an SDK, an adapter, a message queue, or custom glue code. When every resource is an HTTP endpoint, the connection is an HTTP request.

Automation platforms

CI/CD systems, workflow tools, and monitoring platforms already speak HTTP, so they can drive Hoody containers without any integration work:

• GitHub Actions: a curl step controls the whole container
• Zapier/Make: HTTP request nodes connect to any Hoody service
• Datadog/Grafana: HTTP checks monitor any service endpoint
• Slack/Discord bots: webhooks trigger container operations
• Terraform/Pulumi: the HTTP provider manages Hoody resources

None of them needs a Hoody plugin, a Hoody SDK, or anything else Hoody-specific. HTTP is the integration.

Scripts as endpoints

With hoody-exec, any script you write is automatically an HTTP endpoint:

scripts/default/1/api/deploy.ts

// @mode serverless

const version = metadata.query.version || 'latest';

// Run deployment via terminal
const terminalBase = new URL(metadata.url).origin.replace('-exec-1', '-terminal-1');
await fetch(`${terminalBase}/api/v1/terminal/execute`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ command: `./deploy.sh ${version}`, wait: true })
});

return { status: 'deployed', version, timestamp: new Date().toISOString() };

Now accessible at:

POST https://PROJECT_ID-CONTAINER_ID-exec-1.node-us-1.containers.hoody.com/api/deploy?version=2.1.0

That URL can be called from a webhook, an AI agent, another container, or a button in your dashboard. The script needs no web framework, server setup, or deployment configuration; the file itself is the endpoint.

REST APIs as GET URLs

hoody-curl transforms complex HTTP operations into simple GET requests:

GET https://PROJECT_ID-CONTAINER_ID-curl-1.node-us-1.containers.hoody.com/api/v1/curl/request
    ?url=https://api.stripe.com/v1/charges
    &method=POST
    &bearer_token=sk_live_xxx
    &data={"amount":2000,"currency":"usd"}

Any context that can issue a GET request can then trigger a REST API call: iframes, QR codes, email links, simple webhooks, or AI chatbots that fetch links. A whole deploy pipeline can sit behind one GET URL, fired by an AI agent, a Slack bot, or a QR code on a whiteboard.

---

Security under one protocol

When every service speaks HTTP, there is one place to enforce security.

One authentication layer. Hoody Proxy handles auth for all 18 services through a single permission system. Configure JWT, password, IP-based, or bearer-token rules once and they apply everywhere.

One audit trail. Every action across every service flows through HTTP, so every file read, command executed, database query, and notification sent is observable in one protocol.

One encryption standard. TLS everywhere, with automatic certificates and no mixed-protocol encryption to reconcile.

One attack surface. Instead of securing SSH, FTP, VNC, database wire protocols, and custom ports separately, you secure HTTPS, and there is one surface left to review.

One interception point. Because every operation is an HTTP request, hoody-exec can sit in front of any of them: log a database query, validate a file access, rate-limit an API call, or add custom authorization logic to an endpoint.

---

AI agents over HTTP

LLMs were trained on the web, so they already handle GET, POST, JSON payloads, headers, and status codes. Infrastructure that is HTTP end to end needs no translation layer for them.

When your infrastructure is HTTP:

• No SDK: the model already calls HTTP endpoints directly
• No custom training: request and response patterns are universal
• No adapter layer: the model generates fetch() calls itself
• Full autonomy: an agent holding a container URL can operate the whole machine

An AI agent can build software, run tests, query databases, manage files, take screenshots, and deploy, all through HTTP calls it already knows how to make. It needs no MCP server and no special integration, though Hoody’s built-in MCP client can connect to external MCP servers when you want extra tools. The HTTP surface is the AI interface.

It also makes containers peer-to-peer: an AI in Container A can orchestrate Container B, which spawns Container C. There is no coordinator and no message bus, only HTTP calls between URLs.

@hoody.com is where that shows up in practice. Any AI that can fetch a URL, including ChatGPT, Codex, Cline, or any agent with web-fetch, reads that address and receives a Skill: a machine-readable map of your infrastructure’s HTTP surface, ready to operate. There is no SDK, onboarding, or custom integration step, because the agent already speaks HTTP.

---

What HTTP replaces

The full map from old tool to Hoody service lives at The Mental Model: which service takes over from which tool, and what you stop maintaining once it does. Anything that can make an HTTP request can operate all of it.

The litmus test

If a tool can make HTTP requests, it can run terminal commands, access files, query databases, automate browsers, execute scripts, manage processes, and orchestrate AI agents in any Hoody container, from anywhere.

---

Use cases

Replace the local toolchain

Instead of installing ssh, sftp, vnc, psql, and IDE extensions for each project, bookmark one set of URLs. Access everything from any device with a browser.

Build internal tools without infrastructure

Write a script and it becomes an API. There is no server to provision, no framework boilerplate, and no deployment pipeline: a script at scripts/default/1/api/report.ts is immediately callable at https://...-exec-1.../api/report.

Connect external services

Connect any external service to your computing resources. If it can send a webhook or make an HTTP call, the integration is done, with no middleware, adapters, or glue code.

Give AI agents autonomy

Hand an AI agent a container URL. It gets a terminal, a filesystem, a database, a browser, and the ability to create more containers, all through HTTP calls it already understands.

Observe everything in one place

Because every action flows through HTTP, one monitoring dashboard can capture terminal commands, file changes, database queries, and API calls from a single protocol.

Best practices

Use the right service for the job

• Quick commands → Terminal (/api/v1/terminal/execute)
• Persistent scripts with logic → Exec (scripts become endpoints)
• Data storage → SQLite (/api/v1/sqlite/db)
• File operations → Files (direct path access)
• Long-running processes → Daemons (/api/v1/daemon/programs)
• Scheduled work → Cron (/users/{user}/entries)
• HTTP composition → cURL (/api/v1/curl/request)

Compose services, don’t duplicate

An Exec script can call Terminal, SQLite, Files, and cURL endpoints. Use each service for what it does best instead of reimplementing functionality.

Secure at the proxy level

Configure authentication once on the Hoody Proxy and it applies to all 18 services uniformly. Don’t implement auth per-service.

Use hoody-curl for external API calls

When integrating with external APIs, use hoody-curl to transform complex requests into simple GET URLs. This makes them embeddable, cacheable, and composable.

Useful questions

Do I really never need SSH?

SSH is available if you want it, but it is not required. Everything SSH does (run commands, transfer files, tunnel ports) has an HTTP equivalent in the Hoody Kit.

Even when you do need to reach a remote server via SSH, you don’t need an SSH client. Hoody Terminal acts as an HTTP-to-SSH bridge: add ssh_host, ssh_user, and optionally ssh_password or ssh_key (a base64-encoded private key) as query parameters to any terminal endpoint, and the container makes the SSH connection for you. You can also route through a SOCKS5 proxy with socks5_host and socks5_port. This works both in the browser (web terminal UI) and programmatically via the execute API. See Terminals for details.

Is HTTP slower than native protocols?

For interactive terminal sessions, Hoody uses WebSocket, which runs over HTTP. For file transfers, HTTP/2 multiplexing and streaming handle large files efficiently. The overhead is small compared with the integration and security benefits.

Can I still use traditional tools if I want?

Yes. Containers are full Debian Linux machines, so you can install and use any tool. The HTTP endpoints cover most of what those tools do, so curl can replace much of the toolchain.

How does authentication work across services?

The Hoody Proxy authenticates requests before they reach any service. You configure auth once (JWT, password, IP whitelist, or token), and it protects all services in the container uniformly. See Proxy Permissions for details.

What about WebSocket and real-time connections?

HTTP-based services that need real-time communication (terminals, displays) use WebSocket, which upgrades from HTTP. The Hoody Proxy handles WebSocket connections natively, so you get real-time transport where it is needed and standard HTTP everywhere else.

Troubleshooting

”I can’t reach the service URL”

1. Verify the container is running: GET https://api.hoody.com/api/v1/containers/{id}
2. Check the URL format: {projectId}-{containerId}-{service}-{instance}.{serverName}.containers.hoody.com
3. Verify proxy permissions allow your access method

”I get 401 Unauthorized”

Proxy permissions are configured for the container. Either authenticate with the correct method (JWT, password, token) or check that your IP is whitelisted. See Proxy Permissions.

”The endpoint returns 404”

Check the API path for the specific service. Each service has its own path prefix (e.g., /api/v1/terminal/, /api/v1/sqlite/). Refer to the API Reference for exact paths.

What’s next

Start building:

• Projects & Containers: create your first container and get service URLs
• The Hoody Kit: all 18 HTTP services available in every container
• Hoody Proxy: how URLs route to services

Design background:

• The HTTP Revolution: the full architectural vision
• Everything is a URL: the foundational principle
• Security Principles: how one protocol simplifies security

Reference:

• API Reference: every endpoint documented