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.com`
File system	`files-1.containers.hoody.com`
Database	`sqlite-1.containers.hoody.com`
Desktop display	`display-1.containers.hoody.com`
Browser automation	`browser-1.containers.hoody.com`
Script execution	`exec-1.containers.hoody.com`
AI agent (Hoody Agent)	`agent-1.containers.hoody.com`
VS Code	`code-1.containers.hoody.com`
HTTP composition	`curl-1.containers.hoody.com`
Background processes	`daemon-1.containers.hoody.com`
Scheduled tasks	`cron-1.containers.hoody.com`
Push notifications	`n-1.containers.hoody.com`
Data streaming	`pipe-1.containers.hoody.com`
Collaborative notebooks	`notes-1.containers.hoody.com`
File watching	`watch-1.containers.hoody.com`
Application launch	`run-1.containers.hoody.com`
TCP tunneling	`tunnel-1.containers.hoody.com`
Proxy access logs	`logs-1.containers.hoody.com`

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

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

# List your containers
hoody containers list

import { HoodyClient } from 'hoody-sdk';
const client = new HoodyClient({ baseURL: 'https://api.hoody.com', 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);

curl -X POST https://api.hoody.com/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.com

For example:

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

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.com
terminal-2.containers.hoody.com
terminal-3.containers.hoody.com
sqlite-1.containers.hoody.com
sqlite-2.containers.hoody.com
browser-1.containers.hoody.com

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

Container Lifecycle

# 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

// 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);

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

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

# Snapshot
curl -X POST https://api.hoody.com/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.com/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 →