Containers

Forget everything you know about containers.

Docker containers are build artifacts. Lightweight, disposable, stateless. You bake an image, ship it, run it, throw it away. They are packaging — not computing.

Hoody containers are computers. Full Debian 13 Linux machines with systemd, their own filesystem, their own network stack, their own process tree. They boot. They run services. They persist state. They have terminals and desktops and databases and browsers. They are not ephemeral throw-away images. They are machines you live in.

The difference is not incremental. It is categorical. And they run on machines that answer to you — flat-rate bare metal you rent from the marketplace (or a shared free-tier server to start), with no opaque cloud fabric in between. Years of privacy and security engineering at Hoody went into making sure your containers are yours.

---

What You Actually Get

When you create a Hoody container, you get a complete Linux computer:

• Debian 13 (Trixie) with full package manager (apt)
• systemd init system (real service management, not hacked entrypoints)
• Own filesystem (persistent, writable, full Linux FHS)
• Own network stack (own IP, own DNS, own routing table)
• Own process tree (PID namespace, proper process isolation)
• 18 built-in HTTP services (terminal, display, files, exec, sqlite, browser, agent, code, curl, notifications, daemons, cron, pipe, notes, watch, run, tunnel, proxy logs)

Every one of those services is a URL. The moment the container spawns, you have 18 live endpoints. No setup, no configuration, no deployment pipeline.

CLI

# Create a container -- a full Linux computer
hoody containers create --project abc123def456789012345678 \
  --server-id node-us-server-id \
  --name "dev-environment" \
  --hoody-kit \
  --dev-kit

# The moment it's running: 18 HTTP services, all live

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.icu', token: process.env.HOODY_TOKEN });

// Spawn a full Linux computer
const container = await client.api.containers.create('abc123def456789012345678', {
  server_id: 'node-us-server-id',
  name: 'dev-environment',
  hoody_kit: true,
  dev_kit: true
});

// Immediately available:
// container.data?.id -> 890abcdef12345678901cdef
// Terminal, Display, Files, Exec, SQLite, Browser, Agent,
// Code, cURL, Notifications, Daemons, Cron, Pipe, Notes,
// Watch, Run, Tunnel, Proxy Logs — all at predictable URLs

HTTP

# One POST, one computer
curl -X POST "https://api.hoody.icu/api/v1/projects/abc123def456789012345678/containers" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "server_id": "node-us-server-id",
    "name": "dev-environment",
    "hoody_kit": true,
    "dev_kit": true
  }'

# Response includes container ID
# Construct any service URL:
# https://{projectId}-{containerId}-terminal-1.node-us.containers.hoody.icu

---

Containers vs Docker: Not Even the Same Category

Docker solved packaging. Hoody solves computing. They are not competitors. They are different tools for different problems.

	Docker Container	Hoody Container
What it is	A process running from a filesystem image	A full Linux computer
Init system	None (or hacked PID 1)	systemd
Persistence	Ephemeral by default (volumes are add-ons)	Persistent by default
Network	Shared bridge / host network	Own network stack with own IP
Services	One process per container (convention)	18 built-in HTTP services + anything you install
Access	docker exec from the host	URL from anywhere on Earth
State	Destroy and rebuild	Snapshot, restore, branch
OS	Stripped-down layers	Full Debian 13 with apt
Purpose	Ship software	Run computers

Docker asks: “How do I package and deploy this app?” Hoody asks: “How do I give someone a computer that is instantly accessible from anywhere?”

Note

You can still run Docker INSIDE a Hoody container. A Hoody container is a full Linux machine — install Docker, Podman, or anything else. The container is the computer. What you run inside it is up to you.

---

Containers vs VMs: Same Goal, Different Era

Virtual machines also give you full computers. But VMs were designed for the pre-web era. They assume you will SSH into them, configure them manually, and manage them like pets.

Hoody containers are designed for the HTTP era:

	Traditional VM	Hoody Container
Access	SSH, VNC, RDP (specialized clients)	HTTPS (browser or curl)
Boot time	Minutes	Seconds
Overhead	Full OS + hypervisor	Lightweight (LXC + namespaces)
Density	Low — full OS per VM	High — containers share what is identical
Isolation	Hardware-level (hypervisor)	Kernel-level (namespaces + seccomp)
Built-in services	None — install everything	18 HTTP services out of the box
Embeddable	No	Yes — every service is an iframe-able URL
AI-accessible	Requires SSH adapter	Native — AI speaks HTTP
Snapshots	Slow (full disk image)	Instant (copy-on-write)

You get your own full computers without VM-grade overhead. You get them without the boot time. You get dedicated machines without the density penalty.

---

The 18 Built-In Services

Every Kit-enabled container (the default) comes with the Hoody Kit — 18 services that abstract Linux capabilities into HTTP endpoints. They are the container’s native interface.

Service	URL Segment	What It Does
Terminal	terminal-N	Shell sessions via HTTP + WebSocket
Display	display-N	Full desktop environments (Xfce, etc.) via browser
Files	files-N	Filesystem access (read, write, delete, list)
SQLite	sqlite-N	SQL databases queryable via HTTP
Exec	exec-N	Scripts that become HTTP endpoints automatically
Browser	browser-N	Chrome/Chromium automation via REST
Agent	agent-N	Hoody Agent — the built-in AI agent (chat, sessions, memory) in your browser
Code	code-N	VS Code instances in the browser
cURL	curl-N	Transform any REST call into a GET URL
Notifications	n-N	Push notifications via HTTP
Daemons	daemon-N	Background process management
Cron	cron-N	Scheduled task management
Pipe	pipe-N	Streaming data transfer between devices
Notes	notes-N	Collaborative notebooks with real-time sync
Watch	watch-N	File change notifications via HTTP + WebSocket
Run	run-N	Multi-source app resolver (Nix, pkgx, AppImage, Docker/OCI)
Tunnel	tunnel-N	TCP tunneling over HTTP (expose or pull services)
Proxy Logs	logs-N	Access logs and traffic inspection for Hoody Proxy

Every service is a URL. Every URL is accessible from anywhere. The container is not just a Linux machine — it is a Linux machine that speaks HTTP natively.

CLI

# Run a command in the container
hoody terminal sessions exec -c 890abcdef12345678901cdef \
  --command "apt update && apt install -y nodejs"

# Read a file
hoody files get /home/user/app.js -c 890abcdef12345678901cdef

# Query a database
hoody db exec-transaction -c 890abcdef12345678901cdef \
  --db /data/app.db \
  --transaction '[{"query":"SELECT * FROM users"}]'

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.icu', token: process.env.HOODY_TOKEN });
const containerClient = await client.withContainer({
  id: CONTAINER_ID,
  project_id: PROJECT_ID,
  server: SERVER_NAME
});

// Terminal: run a command
const result = await containerClient.terminal.execution.execute({
  command: 'node --version',
  wait: true
});

// Files: read application code
const code = await containerClient.files.get('/home/user/app.js');

// SQLite: query the database (via direct fetch to the container service URL)
const base = `https://${PROJECT_ID}-${CONTAINER_ID}`;
const node = `${SERVER_NAME}.containers.hoody.icu`;
const data = 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 count(*) FROM users' }] })
});

HTTP

# Terminal: install software
curl -X POST "https://$PROJECT-$CONTAINER-terminal-1.$SERVER.containers.hoody.icu/api/v1/terminal/execute" \
  -H "Content-Type: application/json" \
  -d '{"command": "apt install -y python3", "wait": true}'

# Files: download a log file
curl "https://$PROJECT-$CONTAINER-files-1.$SERVER.containers.hoody.icu/api/v1/files/var/log/syslog" \
  -o syslog.txt

# Display: take a screenshot of the desktop
curl "https://$PROJECT-$CONTAINER-display-1.$SERVER.containers.hoody.icu/api/v1/display/screenshot" \
  -o desktop.png

# Browser: navigate to a page
curl "https://$PROJECT-$CONTAINER-browser-1.$SERVER.containers.hoody.icu/browse?browser_id=0&url=https%3A%2F%2Fexample.com"

---

Container Isolation

Each container is its own private computer. Its files, its processes, its network — yours, and separate.

Own filesystem. Containers cannot see each other’s files. No shared volumes by default. Each container has its own root filesystem, its own /home, its own /etc. You can explicitly share directories between containers if you choose, but isolation is the default.

Own network. Each container has its own IP address, its own routing table, its own DNS configuration. Containers do not share a network bridge. They communicate via HTTP URLs through the proxy, the same way any two computers on the internet communicate.

Own processes. PID namespaces give every container its own process tree — what runs on one of your machines is invisible to the next, exactly as with two separate computers.

Kernel-enforced. This separation is not application-level. It is enforced by Linux namespaces, seccomp filters, and a hardened kernel.

Caution

Containers share the host kernel. This is lighter than a hypervisor but means kernel vulnerabilities could theoretically affect container separation. Hoody uses a custom hardened Hoody kernel with seccomp filters and restricted syscalls to minimize this surface.

---

Multiple Instances

A container can expose multiple parallel sessions for instance-aware services. For those services, the instance number in the URL (-1, -2, -3) selects the session:

https://...890abc-terminal-1.node-us.containers.hoody.icu   # Developer's shell
https://...890abc-terminal-2.node-us.containers.hoody.icu   # Build process
https://...890abc-terminal-3.node-us.containers.hoody.icu   # AI agent's session

https://...890abc-display-1.node-us.containers.hoody.icu    # Main desktop
https://...890abc-display-2.node-us.containers.hoody.icu    # Secondary monitor

https://...890abc-sqlite-1.node-us.containers.hoody.icu     # SQLite service
https://...890abc-sqlite-2.node-us.containers.hoody.icu     # Same SQLite service; the instance segment does not select a database
# Both reach the same files -- pick the database with ?db=app or ?db=analytics

Same container. For instance-aware services, different URLs identify concurrent sessions for different users or agents; SQLite instead selects the database with the db query parameter.

This is multiplayer by architecture, not by feature flag.

---

The Economics: Infinite Containers

Traditional VMs consume fixed resources whether you use them or not. A 2-core, 4GB VM costs the same idle as it does under load.

Hoody containers share what is identical: BTRFS copy-on-write storage means containers cloned from the same base image share disk blocks, and the shared host kernel and page cache mean one hundred containers running the same base Debian image do not cost 100x the resources. You pay only for what differs.

This means:

• Development containers cost nearly nothing when idle
• Test containers share base OS memory with production containers
• Staging environments are not a budget conversation
• Per-feature containers become practical, not extravagant
• AI agents can each get their own container without resource anxiety

You are not rationing computers. You are spawning them.

CLI

# Spawn 10 containers for parallel testing
for i in $(seq 1 10); do
  hoody containers create --project $PROJECT_ID \
    --server-id $SERVER_ID \
    --name "test-runner-$i" \
    --hoody-kit
done

# Each gets 18 HTTP services, each isolated
# Shared memory pages keep resource usage low

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.icu', token: process.env.HOODY_TOKEN });

// Spin up containers for each team member
const names = ['alice', 'bob', 'carol', 'dave'];

const containers = await Promise.all(
  names.map(name =>
    client.api.containers.create(projectId, {
      server_id: serverId,
      name: `dev-${name}`,
      hoody_kit: true,
      dev_kit: true
    })
  )
);

// 4 full Linux computers, each with 18 services
// Cloned from the same base image, so they share disk blocks (BTRFS CoW)

HTTP

# Create containers in parallel -- they're cheap
for name in frontend backend database worker; do
  curl -X POST "https://api.hoody.icu/api/v1/projects/$PROJECT_ID/containers" \
    -H "Authorization: Bearer $HOODY_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"server_id\": \"$SERVER_ID\",
      \"name\": \"$name\",
      \"hoody_kit\": true,
      \"dev_kit\": true
    }" &
done
wait

# 4 computers created in parallel
# Each with terminal, display, files, exec, sqlite...

---

Container Lifecycle

Containers are not disposable. They have state, history, and continuity.

Create — a POST to the API. The container comes up with all services running.

Run — the container operates as a full Linux machine. Install software, run servers, write code, train models. Everything persists.

Snapshot — capture the entire filesystem state instantly. Snapshots are copy-on-write, so they cost almost nothing.

Stop — the container halts but preserves its filesystem. Start it again, and everything is where you left it.

Restore — revert to any snapshot. Time travel in one API call.

Copy — duplicate a container to another server or project. Clone your development environment for a new team member in one API call.

Delete — destroy the container. The URL ceases to exist.

At every stage, the container’s identity is its URL. Create it, and URLs appear. Delete it, and URLs vanish.

---

The Atomic Unit of Computing

In legacy infrastructure, the “unit” is ambiguous. Is it a server? A VM? A pod? A process? A function? Teams spend more time debating the abstraction than building on it.

In Hoody, the atomic unit is the container. It is the answer to every question:

• “Where does this service run?” In a container.
• “How do I give the AI access?” Give it the container URL.
• “How do I try something risky without touching anything else?” Put it in a container.
• “How do I roll back?” Restore the container snapshot.
• “How do I share this environment?” Share the container URL.

One abstraction. One mental model. One URL pattern. Everything else is built on top of containers, not beside them.

The Container Mindset

When in doubt, create a container. They are cheap, they are fast, they are yours, and they are HTTP-native. The overhead of a new container is less than the overhead of configuring a shared one.

---

Next: The Hoody Proxy — how URLs reach containers.