The HTTP Mindset

The only tool you need is fetch.

Every terminal, file, database, desktop, browser, script, and background service in Hoody is an HTTP endpoint. Not “accessible via HTTP.” Not “has an API wrapper.” Is HTTP. Your entire computing stack speaks one language, and you already know it.

This means any system that can make an HTTP request can control any computing resource you have. A CI/CD pipeline. A webhook. A browser extension. A phone. An AI agent. A curl command from any terminal on Earth.

No SSH client. No FTP client. No VNC viewer. No database GUI. No proprietary SDK. Just HTTP.

---

One Protocol, Zero Friction

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. Each one is another surface to secure, another thing to install, another thing to break.

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
Push notifications	HTTPS	fetch or curl

One protocol. One authentication model. One way to monitor, log, and debug. The cognitive overhead drops to near zero.

---

What This Looks Like in Practice

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

https://{projectId}-{containerId}-{service}-{serviceIndex}.{serverName}.containers.hoody.icu

Here is what a developer’s day looks like when everything is HTTP:

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

// 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({ title: 'Build complete', body: 'Deployed successfully' })
});

// SSH into a remote server — through 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 })
});

No setup. No installation. No configuration file. Just HTTP calls — all over HTTPS with HTTP/2 and HTTP/3, automatically, on servers you own. This works from anywhere: a Node.js script, a Python notebook, a GitHub Action, a Zapier trigger, an AI agent, or Hoody OS — the web-based operating system where you see all these services as floating windows on your screen. You can SSH in too (ssh hoody.com), but honestly, once everything is an HTTPS endpoint, you’ll wonder why you ever bothered with SSH for anything other than the fun of it.

Screenshot Needed Hoody OS — developer's day: terminal executing build, file browser showing config, SQLite query results, and a notification popup — all as HTTP requests

A developer's day when everything is HTTP — all visible through Hoody OS

Notice that last example: a regular HTTP POST just executed a command on a different server via SSH. Your Hoody container becomes an HTTP-to-SSH bridge — you can manage any server from any device that speaks HTTP, including your phone.

---

Why This Changes Integration Forever

The integration problem in software has always been: “How do I make System A talk to System B?” The answer usually involves SDKs, adapters, message queues, or custom glue code.

When everything is HTTP, the answer is always the same: make an HTTP request.

Any automation platform works instantly

Every CI/CD system, every workflow tool, every monitoring platform already speaks HTTP. That means they can already control Hoody containers with zero integration work:

• GitHub Actions — curl in a step controls your entire 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 — HTTP provider manages Hoody resources

No Hoody plugin. No Hoody SDK. No Hoody-specific anything. HTTP is the integration.

Scripts become APIs instantly

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

scripts/api/deploy.js

// @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://abc123-def456-exec-1.node-us-1.containers.hoody.icu/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 didn’t need a web framework, a server setup, or deployment configuration. It just exists at a URL.

Any REST API becomes a GET URL

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

GET https://abc123-def456-curl-1.node-us-1.containers.hoody.icu/api/v1/curl/request
    ?url=https://api.stripe.com/v1/charges
    &method=POST
    &headers=Authorization:Bearer sk_live_xxx
    &body={"amount":2000,"currency":"usd"}

This means any context that supports GET requests (iframes, QR codes, email links, simple webhooks, AI chatbots with link-fetching) can now trigger any REST API call. Wrap your entire deploy pipeline into a GET URL. An AI agent, a Slack bot, or a QR code on a whiteboard can fire it. The composability is infinite.

---

Why This Changes Security Forever

One protocol means one place to enforce security. When everything is HTTP:

One authentication layer. Hoody Proxy handles auth for all 18 services through a single permission system. JWT, password, IP-based, or bearer token — configure once, applies everywhere.

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

One encryption standard. TLS everywhere, automatic certificates, no mixed-protocol encryption headaches.

One attack surface. Instead of securing SSH + FTP + VNC + database wire protocols + custom ports, you secure HTTPS. That’s it. The attack surface shrinks by an order of magnitude.

Total observability. Since everything is HTTP, you can intercept any operation with hoody-exec. Log every database query. Validate every file access. Rate-limit every API call. Add custom authorization logic to any endpoint. HTTP makes the invisible visible.

---

Why AI Needs This

LLMs were trained on the web. They understand HTTP natively — GET, POST, JSON payloads, headers, status codes. This isn’t a nice-to-have. It’s the foundation of AI-driven computing.

When your infrastructure is HTTP:

• No SDK needed — AI already knows how to call HTTP endpoints
• No custom training — request/response patterns are universal
• No adapter layer — AI generates fetch() calls directly
• Full autonomy — an AI agent with a container URL can operate the entire 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. No MCP server required (though Hoody’s built-in MCP client can connect to external MCP servers for additional tools). No special integration. The HTTP surface IS the AI interface.

This is why Hoody containers are peer-to-peer: an AI in Container A can orchestrate Container B, which spawns Container C. No coordinator. No message bus. Just HTTP calls between URLs.

@hoody.com is the proof point. Any AI on the internet — ChatGPT, Codex, Cline, any agent with web-fetch — visits that address and receives a Skill: the full HTTP surface of your infrastructure, ready to operate. No SDK, no onboarding, no custom integration. The AI already speaks HTTP. @hoody.com just hands it the keys.

---

The Mental Shift

Stop thinking about infrastructure. Start thinking about URLs.

Old question	New question
”How do I connect to this server?"	"What’s the URL?"
"What do I need to install?"	"What endpoint do I call?"
"How do I integrate these two systems?"	"Can it make HTTP requests?"
"Which SDK do I use?”	fetch()
”How do I give AI access?"	"Give it the URL.”

If it can make HTTP requests, it can control everything. That’s the HTTP mindset.

The Litmus Test

Can your tool make HTTP requests? Then it can run terminal commands, access files, query databases, automate browsers, execute scripts, manage processes, and orchestrate AI agents — all in any Hoody container, from anywhere.

---

Use Cases

Replace your entire 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, it becomes an API. No server provisioning, no framework boilerplate, no deployment pipeline. A script at /scripts/api/report.js is immediately callable at https://...-exec-1.../api/report.

Ship integrations in minutes, not weeks

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

Give AI complete autonomy

Hand an AI agent a container URL. It has 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 all actions flow through HTTP, build a single monitoring dashboard that captures terminal commands, file changes, database queries, and API calls — all from one 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 — 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 you don’t need it. Everything SSH does (run commands, transfer files, tunnel ports) has an HTTP equivalent in the Hoody Kit. Most users never touch SSH.

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.

What about performance? Isn’t 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 negligible compared to the integration and security benefits.

Can I still use traditional tools if I want?

Yes. Containers are full Debian Linux machines. You can install and use any tool. But once you experience the HTTP approach, you’ll find that curl replaces most of your 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. You get real-time when you need it, standard HTTP for everything else.

Troubleshooting

”I can’t reach the service URL”

1. Verify the container is running: GET https://api.hoody.icu/api/v1/containers/{id}
2. Check the URL format: {projectId}-{containerId}-{service}-{instance}.{serverName}.containers.hoody.icu
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 with HTTP:

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

Dive deeper into the vision:

• The HTTP Revolution — The full architectural vision
• Everything is a URL — The foundational principle
• Security Principles — How one protocol simplifies security

See the API in action:

• API Reference — Every endpoint documented