Understanding Containers

Forget Docker. Forget VMs. Hoody containers are something else entirely.

A Hoody container is a full Debian 13 Linux computer — with systemd, its own filesystem, its own network, and 18 HTTP services built in. The moment it exists, it’s online. Every process, every file, every database inside it has a URL.

You don’t SSH into them (though ssh hoody.com drops you into the Hoody CLI and Agent from any terminal). You don’t deploy to them (though nothing stops you). You fetch them. Every process running inside is already an HTTPS endpoint, with HTTP/2 out of the box. You’ll never think about a certificate again.

---

What You Get

Every container created with Hoody Kit enabled (hoody_kit: true) includes:

Capability	How You Access It
Shell access	terminal-1.containers.hoody.icu
File system	files-1.containers.hoody.icu
Database	sqlite-1.containers.hoody.icu
Desktop display	display-1.containers.hoody.icu
Browser automation	browser-1.containers.hoody.icu
Script execution	exec-1.containers.hoody.icu
AI agent (Hoody Agent)	agent-1.containers.hoody.icu
VS Code	code-1.containers.hoody.icu
HTTP composition	curl-1.containers.hoody.icu
Background processes	daemon-1.containers.hoody.icu
Scheduled tasks	cron-1.containers.hoody.icu
Push notifications	n-1.containers.hoody.icu
Data streaming	pipe-1.containers.hoody.icu
Collaborative notebooks	notes-1.containers.hoody.icu
File watching	watch-1.containers.hoody.icu
Application launch	run-1.containers.hoody.icu
TCP tunneling	tunnel-1.containers.hoody.icu
Proxy access logs	logs-1.containers.hoody.icu

All of this. In every container. Accessible from any device with a browser — or driven from any terminal via the Hoody CLI (ssh hoody.com).

Screenshot Needed Hoody Agent — container management view showing container list with status indicators, service URLs, and quick actions

Managing containers from the Hoody Agent

---

Create a Container

CLI

# Create a container in your project
hoody containers create --project $PROJECT_ID --name "backend" --server-id $SERVER_ID

# List your containers
hoody containers list

SDK

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

const container = await client.api.containers.create(PROJECT_ID, {
  server_id: SERVER_ID,
  name: 'backend'
});

// Your computer is already live
console.log(container.data.id);

HTTP

curl -X POST https://api.hoody.icu/api/v1/projects/$PROJECT_ID/containers \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"server_id": "'"$SERVER_ID"'", "name": "backend"}'

---

The URL Structure

Every service in every container has a predictable URL:

https://{projectId}-{containerId}-{serviceName}-{serviceId}.{node}.containers.hoody.icu

For example:

https://abc123-def456-terminal-1.node-us.containers.hoody.icu
https://abc123-def456-files-1.node-us.containers.hoody.icu
https://abc123-def456-display-1.node-us.containers.hoody.icu

Note

The URL IS the interface. No ports to memorize, no configuration files, no network setup. The URL tells you exactly what service you’re talking to.

---

How They Differ from Docker

Feature	Docker	Hoody Containers
Base system	Minimal layers	Full Debian 13 + systemd
Networking	Internal bridge, port mapping	Every service has a public URL
Access method	docker exec / SSH	HTTP from anywhere
Built-in services	None — BYO everything	18 HTTP services included
Collaboration	Not designed for it	Multiplayer by default
Snapshots	Volume snapshots only	Full filesystem snapshots and restore
Multiple instances	Separate containers	terminal-1, terminal-2… in same container

Docker containers are build artifacts. Hoody containers are computers.

---

Multiple Instances

Need three terminals, two databases, and a browser?

terminal-1.containers.hoody.icu
terminal-2.containers.hoody.icu
terminal-3.containers.hoody.icu
sqlite-1.containers.hoody.icu
sqlite-2.containers.hoody.icu
browser-1.containers.hoody.icu

Same container, different instances. Each one is its own URL, its own process, its own state.

---

Container Lifecycle

CLI

# Start a stopped container
hoody containers manage $CONTAINER_ID start

# Stop a running container
hoody containers manage $CONTAINER_ID stop

# Snapshot before making changes
hoody snapshots create --container $CONTAINER_ID --alias "before-experiment"

# Restore if something breaks
hoody snapshots restore --container $CONTAINER_ID --name $SNAPSHOT_NAME

SDK

// Start
await client.api.containers.manage(CONTAINER_ID, 'start');

// Stop
await client.api.containers.manage(CONTAINER_ID, 'stop');

// Snapshot
const snapshot = await client.api.containers.createSnapshot(CONTAINER_ID, {
  alias: 'before-experiment'
});

// Restore
await client.api.containers.restoreSnapshot(CONTAINER_ID, SNAPSHOT_NAME);

HTTP

# Start
curl -X POST https://api.hoody.icu/api/v1/containers/$CONTAINER_ID/start \
  -H "Authorization: Bearer $TOKEN"

# Stop
curl -X POST https://api.hoody.icu/api/v1/containers/$CONTAINER_ID/stop \
  -H "Authorization: Bearer $TOKEN"

# Snapshot
curl -X POST https://api.hoody.icu/api/v1/containers/$CONTAINER_ID/snapshots \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alias": "before-experiment"}'

# Restore
curl -X PUT https://api.hoody.icu/api/v1/containers/$CONTAINER_ID/snapshots/$SNAPSHOT_NAME \
  -H "Authorization: Bearer $TOKEN"

---

Infinite Containers, One Server

You don’t pay per container. You pay for bare metal — then spawn as many containers as you want.

Old model: $40/month per VPS. Three environments = $120/month. Hoody model: One server. Infinite containers. Experiment freely.

This changes how you think about computing. Dev containers, staging, experiments, AI playgrounds — they’re all free to create.

A container isn’t infrastructure. It’s a URL. Treat it like one.

Next: The Hoody Proxy →