Create, Edit, Delete

Containers are HTTP computers you spawn on demand. Create them in 1-5 seconds, configure them exactly how you need, and delete them when you’re done.

After understanding Projects & Containers, you need to know how to actually create and manage individual containers.

API Endpoints Summary

Official Technical Reference:

This Foundation page explains container CRUD concepts and workflows. For complete endpoint documentation:

Container Creation:

POST /api/v1/projects/{id}/containers - Create new container
GET /api/v1/containers - List all containers
GET /api/v1/containers/{id} - Get container details

Container Modification:

PATCH /api/v1/containers/{id} - Update container configuration

Container Deletion:

DELETE /api/v1/containers/{id} - Delete container permanently

Related Operations:

Container Operations - Start/stop/pause/resume
Projects - Project management

Creating Containers

Every container you create becomes a complete HTTP computer with the full Hoody Kit service stack.

The Basic Creation

POST Create a new container

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

Within 1-5 seconds:

Container is running (prespawn) or creating (regular)
The full Hoody Kit HTTP stack is live
URLs automatically generated

Startup timing:

With prespawn: Sub-second (claimed from warm pool)
Without prespawn: 1-5 seconds (created on demand)

Response includes container details:

{
  "statusCode": 201,
  "message": "Container created successfully",
  "data": {
    "id": "890abcdef12345678901cdef",
    "project_id": "67e89abc123def456789abcd",
    "server_id": "63f8b0e5c9a1b2d3e4f5a6b7",
    "server_name": "node-us",
    "name": "dev-environment",
    "status": "creating",
    "hoody_kit": true,
    "dev_kit": true
  }
}

Your container URLs are now live:

Terminal:  https://67e89abc123def456789abcd-890abcdef12345678901cdef-terminal-1.node-us.containers.hoody.icu
Display:   https://67e89abc123def456789abcd-890abcdef12345678901cdef-display-1.node-us.containers.hoody.icu
Files:     https://67e89abc123def456789abcd-890abcdef12345678901cdef-files-1.node-us.containers.hoody.icu
Exec:      https://67e89abc123def456789abcd-890abcdef12345678901cdef-exec-1.node-us.containers.hoody.icu
SQLite:    https://67e89abc123def456789abcd-890abcdef12345678901cdef-sqlite-1.node-us.containers.hoody.icu
+ the rest of the 18 Kit services...

Container Configuration Options

When creating a container, you can customize every aspect:

Essential Parameters

{
  "name": "my-container"
}

3-100 characters
Alphanumeric + hyphens/underscores
Unique within project
Use "rand" or omit for auto-generated name

{
  "server_id": "63f8b0e5c9a1b2d3e4f5a6b7"
}

Required during creation
Determines where container runs
Get via: GET /api/v1/rentals (or its alias GET /api/v1/servers) — your own inventory
Not GET /api/v1/servers/available: that’s the rental marketplace, and its ids are for renting a server, not for placing a container
Choose by geography, capacity, or price

{
  "hoody_kit": true
}

true: Install the Hoody Kit HTTP services (terminal, display, files, sqlite, browser, exec, agent, code, curl, cron, notifications, pipe, notes, watch, run, tunnel, proxy logs, daemon)
false: Plain Linux container
Recommended: Always use true
Can’t be changed after creation

{
  "dev_kit": true
}

true: Include developer-focused Kit services (editor, agent, and related developer tooling) on top of hoody_kit
false: Omit the developer stack to keep the image smaller
Default: true when hoody_kit: true
Can’t be changed after creation

Image Selection

Choose your operating system:

{
  "container_image": "debian/13"
}

Available images:

debian/13 - Debian 13 Trixie (recommended default)
ubuntu/24.04 - Ubuntu 24.04 LTS
ubuntu/22.04 - Ubuntu 22.04 LTS
alpine/3.19 - Alpine Linux (minimal)
fedora/<release> - Fedora (pick an available release from GET /api/v1/images/public?os=fedora)

Default: If omitted or null, the system default image is used — currently debian/13 (Debian 13 Trixie). You can override it with any image from the marketplace.

See: Container Images for complete marketplace and OS options.

Realm Assignment (API Segregation)

Assign container to specific realms for API-level isolation:

{
  "realm_ids": ["64a2c4e9f3d5e2b6a8c7d8e1", "65b3d5f0a4e6f3c7b9d8e9f2"]
}

Important: Realms are NOT private networks. They segregate the Hoody API:

Different realms use different API endpoints: https://{realmId}.api.hoody.icu
AI agents in one realm can’t discover containers in another
Auth tokens can be scoped to specific realms
Production/staging/development separated at API level

When creating from a realm-scoped host:

The target project must already include that realm.
The scoped realm is merged into container realm_ids.
Realm-restricted auth tokens are forced to the active scoped realm only.

See: Realms for complete API segregation details.

Environment Variables

Set environment variables for your application:

{
  "environment_vars": {
    "NODE_ENV": "production",
    "DATABASE_URL": "postgresql://...",
    "API_KEY": "your-secret-key"
  }
}

These are available in the container immediately.

SSH Access

Provide your SSH public key:

{
  "ssh_public_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGx..."
}

Critical SSH Key Rules:

Generate unique keys for each container:

# Generate new key pair for each container
ssh-keygen -t ed25519 -f ~/.ssh/hoody-container-1 -N ""
ssh-keygen -t ed25519 -f ~/.ssh/hoody-container-2 -N ""

# Use different public keys
container_1: {"ssh_public_key": "ssh-ed25519 AAAA... (from container-1.pub)"}
container_2: {"ssh_public_key": "ssh-ed25519 AAAA... (from container-2.pub)"}

Why unique keys matter: Hoody’s SSH Proxy identifies containers by public key. Reusing a key breaks routing - multiple containers can’t share the same SSH identity.

See: SSH Access for SSH configuration.

Visual Organization (Color)

Qubes-inspired color coding for instant visual identification:

{
  "color": "#3498db"  // HEX color (with or without #)
}

Why colors matter (inspired by Qubes OS):

Like Qubes OS uses colors to visually distinguish security domains (red = untrusted, green = trusted), Hoody lets you color-code containers for instant recognition.

Especially useful for:

WebOS builders - Color-code different workspaces/applications
Security zones - Red = public-facing, green = internal, blue = database
Multi-user teams - Each user/team gets distinct colors
Environment types - Yellow = dev, orange = staging, green = production

Visual scanning beats text - spot your production database instantly in 50 containers.

Additional Options

{
  "comment": "Development environment for Project X",
  "autostart": true,         // Auto-start when host reboots (default: true)
  "ai": true,               // Enable AI features (default: true)
  "cache": true,            // Use cached images (faster creation)
  "bypass_prespawn": true,  // Non-default: skip warm claiming only when you require a guaranteed fresh build
  "ramdisk": true,          // enabled by default, set false to disable
  "ramdisk_scope": "container" // "container" is the only accepted value today
}

About autostart (default: true):

When true: Container automatically starts when host machine reboots
When false: Container stays stopped after host reboot (manual start required)
Default behavior: Containers auto-start to ensure services remain available after server maintenance/restarts

About ramdisk (default: enabled):

/ramdisk available by default for ultra-fast temporary storage in RAM
Set ramdisk: false to disable if you don’t need it
Zero RAM consumed when empty - RAM allocated on-demand as you store files
Capacity is a shared per-server pool - 512 MiB by default (never more than 50% of that server’s memory), shared by all your containers on that server. The size is not adjustable.
It is memory, not disk - it counts against your server’s memory, not its disk space
ramdisk_scope - /ramdisk is private to each container. A shared project scope exists in the data model but is not currently accepted: asking for ramdisk_scope: "project" on create or update returns 400 while a permission boundary is corrected. container is the only value the API takes today.
Data persists through container restarts (unique Hoody feature!)
Data lost only when HOST machine reboots (not when container restarts)
Perfect for cache, build artifacts, temporary processing that needs speed
See: /ramdisk for usage patterns and memory balancing

Complete Creation Examples

Example 1: Development Container

Full-featured development environment:

POST Create a development container

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

Use case: Your daily driver - full resources, all services, auto-starts.

Example 2: Production API Container

Optimized for running APIs:

POST Create a production API container

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

Then configure:

Create proxy alias for clean URL
Set proxy permissions for authentication
Configure firewall rules for security

Example 3: Minimal Utility Container

Lightweight container for specific tasks:

POST Create a minimal utility container

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

Use case: Run occasionally for backups, minimal resource footprint.

Example 4: AI Agent Container

Dedicated container for AI orchestration:

POST Create an AI agent container

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

With hoody-agent service:

https://67e89abc123def456789abcd-890abcdef12345678901cdef-agent-1.node-us.containers.hoody.icu

Editing Containers

Update container configuration via the API.

Update Workflow

No stop is normally required. PUT /api/v1/containers/{id} accepts updates while the container is running, paused, or stopped, except that narrowing ramdisk_scope to container is rejected while running. Updates are refused while the container is being claimed or quarantined; enabling autostart also returns 409 Conflict until a network policy is in force and any hard access suspension is lifted. Environment-variable changes do not generally require a restart: after successful live synchronization, new incus exec processes see them immediately, and the dedicated containers env endpoints also update /etc/environment for new SSH/console logins; already-running processes must re-exec.

hoody containers update $CONTAINER_ID \
  --name renamed-container \
  --environment-vars NODE_ENV=staging

await client.api.containers.update(CONTAINER_ID, {
  name: 'renamed-container',
  environment_vars: { NODE_ENV: 'staging' }
});

curl -X PATCH "https://api.hoody.icu/api/v1/containers/{container_id}" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "renamed-container",
    "environment_vars": {"NODE_ENV": "staging"}
  }'

What You Can Update

Container metadata:

name - Rename container
color - Change UI color
comment - Update description

Configuration:

environment_vars - Add/modify/remove env variables
ssh_public_key - Change SSH access key
realm_ids - Update API realm membership (realm-restricted tokens cannot modify this)
autostart - Enable/disable auto-start
ai - Enable/disable AI features
ramdisk - Enable/disable ramdisk mount
ramdisk_scope - container is accepted (and is how a legacy project-scoped row narrows back); widening to project is currently unavailable and returns 400. Narrowing back to container is rejected while the container is running; pause or stop it first

What you CANNOT change:

container_image - OS is permanent (create new container instead)
hoody_kit - Service installation is permanent
dev_kit - Developer tooling choice is permanent (set at creation only)
server_id - Cannot move servers (use copy instead)

Update Examples

Example 1: Change Environment

# Switch from staging to production
PATCH /api/v1/containers/{id}
{
  "environment_vars": {
    "NODE_ENV": "production",
    "API_BASE_URL": "https://api.mycompany.com"
  }
}

Example 2: Move to Different Realm

# Isolate to production network
PATCH /api/v1/containers/{id}
{
  "realm_ids": ["64a2c4e9f3d5e2b6a8c7d8e1"]
}

Deleting Containers

Permanent deletion of a container and all its data.

The Deletion Process

DELETE Delete a container permanently

/api/v1/containers/{container_id}

Click "Run" to execute the request

What gets deleted:

Container filesystem and all data
Environment variables
Network configuration
Firewall rules
All service URLs become inaccessible
Snapshots are deleted with the container (cascade delete — copy the container first if you need to retain its state)
Existing copies keep running (they are independent containers, but can no longer be synced — the source link is broken)

Safe Deletion Workflow

# 1. Create final snapshot
hoody snapshots create --container $CONTAINER_ID --alias "before-deletion-2025-11-09"

# 2. Stop running container
hoody containers manage $CONTAINER_ID stop

# 3. Permanent deletion
hoody containers delete $CONTAINER_ID

# 4. Cleanup (optional) - delete proxy aliases
hoody proxy delete $ALIAS_ID

// 1. Create final snapshot
await client.api.containers.createSnapshot(CONTAINER_ID, { alias: 'before-deletion-2025-11-09' });

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

// 3. Permanent deletion
await client.api.containers.delete(CONTAINER_ID);

// 4. Cleanup (optional)
await client.api.proxyAliases.delete(ALIAS_ID);

# 1. Create final snapshot
curl -X POST "https://api.hoody.icu/api/v1/containers/{id}/snapshots" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alias": "before-deletion-2025-11-09"}'

# 2. Stop running container
curl -X POST "https://api.hoody.icu/api/v1/containers/{id}/stop" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# 3. Permanent deletion
curl -X DELETE "https://api.hoody.icu/api/v1/containers/{id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# 4. Cleanup (optional) - delete proxy aliases
curl -X DELETE "https://api.hoody.icu/api/v1/proxy/aliases/{alias_id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

Best practice: Keep snapshots of production containers for disaster recovery.

The Hoody Kit

When you set hoody_kit: true, your container gets the full Hoody Kit HTTP stack:

What Gets Installed

Interact & Visualize:

Terminal (hoody-terminal) - Web-based terminal
Display (hoody-display) - Full desktop environment
Browser (hoody-browser) - Chrome automation

Data & State:

Files (hoody-files) - Filesystem access
SQLite (hoody-sqlite) - Database + KV store

Automate & Orchestrate:

Exec (hoody-exec) - Scripts as HTTP APIs
cURL (hoody-curl) - HTTP request wrapper

Operate & Monitor:

Daemons (hoody-daemon) - Process management
Notifications (hoody-notifications) - Alerts
Code (hoody-code) - VS Code instances
Cron (hoody-cron) - Scheduled task runner
Pipe (hoody-pipe) - Data streaming between services
Agent (hoody-agent) - Collaborative WebOS interface

Installation time: Added to container creation (no extra wait).

See: The Hoody Kit for complete service documentation.

Container Lifecycle States

Containers progress through these states:

creating → running → (paused) → stopped → deleting
              ↓                    ↑
           (can pause)          (can restart)

State Descriptions

State	Description	Transitions Available
`creating`	Container being provisioned	→ `running` (automatic)
`running`	Container is active	→ `stopped`, `paused`
`paused`	Container suspended	→ `running` (resume)
`stopped`	Container is stopped	→ `running` (start)
`failed`	Creation or operation failed	→ `deleting` (cleanup)
`copying`	Being copied to another location	→ `running` (when complete)
`deleting`	Being permanently removed (async)	(record is removed on completion)

Get current state:

GET Get container status

/api/v1/containers/{container_id}

Click "Run" to execute the request

See: Managing Containers for state transitions.

Listing Your Containers

Find containers across all projects:

List All Containers

GET List all containers for your account

/api/v1/containers

Click "Run" to execute the request

List Project Containers

GET List containers in a specific project

/api/v1/projects/{project_id}/containers

Click "Run" to execute the request

Filtering & Pagination

GET Filter and paginate containers

/api/v1/containers

Click "Run" to execute the request

Include Runtime Information

Get live service status:

GET Get container with runtime information

/api/v1/containers/{container_id}

Click "Run" to execute the request

Response includes:

Active terminal sessions
Display connections
Running services (with PIDs)
Network services and ports
Command history

Use this to verify services are running before using their URLs.

Complete Workflow Example

From project creation to running container:

# 1. Create a project
hoody projects create --alias "client-acme" --color "#e74c3c"

# 2. Check your servers
hoody servers list

# 3. Create a container
hoody containers create --project $PROJECT_ID \
  --server-id $SERVER_ID \
  --name "acme-frontend" \
  --hoody-kit \
  --dev-kit

# 4. Verify it's running
hoody containers get $CONTAINER_ID

# 5. Container URLs are live:
# https://{project_id}-{container_id}-terminal-1.{server_name}.containers.hoody.icu
# https://{project_id}-{container_id}-display-1.{server_name}.containers.hoody.icu

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

// 1. Create a project
const project = await client.api.projects.create({
  alias: 'client-acme', color: '#e74c3c'
});

// 2. Get server ID from rentals
const rentals = await client.api.rentals.list();
const serverId = rentals.data[0].server_id;

// 3. Create a container
const container = await client.api.containers.create(project.data.id, {
  name: 'acme-frontend',
  server_id: serverId,
  hoody_kit: true,
  ssh_public_key: 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...'
});

// 4. Verify it's running
const status = await client.api.containers.get(container.data.id);
console.log(status.data.status); // 'running'

# 1. Create a project
curl -X POST "https://api.hoody.icu/api/v1/projects/" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alias": "client-acme", "color": "#e74c3c"}'

# 2. Check your servers
curl "https://api.hoody.icu/api/v1/rentals" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# 3. Create a container
curl -X POST "https://api.hoody.icu/api/v1/projects/{project_id}/containers" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "acme-frontend",
    "server_id": "{server_id}",
    "hoody_kit": true,
    "ssh_public_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA..."
  }'

# 4. Verify it's running
curl "https://api.hoody.icu/api/v1/containers/{container_id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# 5. Container URLs are live:
# https://{project_id}-{container_id}-terminal-1.{server_name}.containers.hoody.icu

Best Practices

1. Let Prespawn Do Its Work

Prespawn pools are maintained by the platform, not configured per account. Creates automatically claim a warm prespawn container whenever one matches, which is where sub-second availability comes from — faster auto-scaling, instant failover, better user experience. Pass bypass_prespawn: true only when you need a guaranteed fresh build.

2. Generate Unique SSH Keys Per Container

Never reuse SSH keys. Generate a new ed25519 key pair for each container to ensure proper routing via Hoody’s SSH Proxy.

ssh-keygen -t ed25519 -f ~/.ssh/container-{name} -N ""

3. Use realm_ids for AI Agent Isolation

When using AI agents, isolate containers in different realms to prevent accidents. An agent in realm A cannot discover or manage containers in realm B - complete API-level separation ensures safety.

4. Color-Code by Purpose

Use Qubes-style color coding: red for public-facing, green for internal services, blue for databases, yellow for development. Visual identification beats reading labels.

5. Snapshot Before Deletion

Always create a snapshot before permanently deleting important containers. The snapshot preserves all data for recovery if needed.

6. Set autostart Based on Priority

Critical services: autostart: true (ensures availability after host reboots). Development containers: autostart: false (saves resources).

7. Use debian/13 as Default

Unless you have specific requirements, stick with debian/13 for excellent stability, security, and package availability.

8. Leverage /ramdisk for Performance

ramdisk is enabled by default—use it for ultra-fast temporary storage (caches, build artifacts, temporary processing). Remember: empty ramdisk consumes zero RAM.

Useful Questions

Can I change the OS after creating a container?

No. The container_image is permanent. To use a different OS:

Snapshot your data
Create new container with desired image
Transfer data via storage shares or manual copy
Delete old container

How many containers can I create?

Optionally limited by the max_containers quota on your project (unset by default, so there’s no per-project cap unless you set one). Get the current quota via GET /api/v1/projects/{id}. Each server also enforces a per-server live-container limit (an explicit max_containers, or a free-tier default if none is set); exceeding it returns SERVER_CONTAINER_LIMIT. No platform-wide limit—create as many projects as needed.

What happens if container creation fails?

Status becomes failed. Check error via GET /api/v1/containers/{id}. Common causes:

Server out of capacity
Invalid image name
Resource quota exceeded
Network issues

Delete the failed container and try again.

Can I create containers without hoody_kit?

Yes! Set hoody_kit: false for plain Linux containers. Important limitations:

No Hoody Proxy - Container services won’t be accessible via HTTP
No Hoody Kit HTTP stack - No terminal, display, files, exec, etc.
SSH access only - But ONLY if you provide ssh_public_key (or inherit one from the project defaults)
No web access at all - Without hoody_kit AND without SSH key, container is completely inaccessible

Use when: You need minimal overhead, custom service installations, or are managing everything via SSH yourself.

Recommendation: Almost always use hoody_kit: true. The HTTP services are what make Hoody powerful.

Do I get charged for stopped containers?

Storage charges apply to stopped containers (they still occupy disk space). CPU/RAM charges stop when container is stopped. Minimize cost: delete unused containers or use minimal storage allocation.

Can I create containers on multiple servers simultaneously?

Yes. Each container creation is independent. Spawn 100 containers across 10 servers in parallel—all via standard HTTP requests. Common pattern for auto-scaling or testing.

What’s the fastest way to create a container?

Do nothing special. The platform keeps warm prespawn pools, and a matching container is claimed in milliseconds (sub-second) without you asking. When no prespawn matches — or when you set bypass_prespawn: true — creation takes 1-5 seconds.

Can I automate container creation with CI/CD?

Absolutely. Create auth token, store as GitHub Secret, use curl in workflows. Container creation is just an HTTP POST—works in any CI/CD system.

How do I know which services are running in my container?

Query with runtime=true parameter:

GET /api/v1/containers/{id}?runtime=true

Response shows active services with PIDs, ports, and connection status.

Troubleshooting

Container Stuck in “creating” Status

Problem: Container status remains “creating” for longer than expected

Typical creation time: 1-5 seconds (prespawn: sub-second)

If longer than 2 minutes:

Check server status:

curl "https://api.hoody.icu/api/v1/servers/{server_id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# Verify server is "ready", not "maintenance"

Check server capacity:
- Server may be at capacity
- Try different server_id
Wait and re-check:
- Complex images take longer
- First creation on server takes longer (image pull)
- Hoody Kit installation adds ~10-15 seconds
If stuck >5 minutes:
- Delete and recreate
- Or contact support with container_id

Cannot Update Container (400 Error)

Problem: Update request returns 400 Bad Request

Common causes:

Invalid values:
- Name must be unique in project
- Color must be valid HEX format
- SSH public key must be unique (can’t reuse across containers)
- realm_ids must be array of valid realm IDs
Immutable fields:
- Cannot change container_image
- Cannot change hoody_kit
- Cannot change server_id

Container Creation Fails Immediately

Problem: Response shows status: "failed" immediately

Check error details:

curl "https://api.hoody.icu/api/v1/containers/{failed_container_id}" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# Look for error message in response

Common issues:

Invalid image name:

# Wrong: "ubuntu:22.04" or "ubuntu-22.04"
# Correct: "ubuntu/24.04" or "debian/13"

Server quota exceeded:
- Server out of CPU/RAM
- Choose different server

Project quota:

# Check project limits
GET /api/v1/projects/{id}
# Look at: max_containers

Cannot Delete Container

Problem: Delete operation fails

Solutions:

Two things you do NOT need to do: stopping the container first is not a prerequisite, and proxy aliases never block a delete — aliases, status logs, SSH keys and storage shares are cascade-deleted with the container record.

If DELETE /api/v1/containers/{id} is refused, check:

Permissions:
- Verify you own the container
- Check you’re using the correct auth token, with containers.delete and a realm that covers the container
The container is not your default container:
- The project’s default container cannot be deleted
The container is not mid-claim:
- A container still being claimed from the prespawn pool is refused until the claim settles — retry shortly
The container is not flagged for admin review:
- A quarantined container cannot be deleted; contact support

Services Not Accessible After Creation

Problem: Container created but service URLs return errors

Debug steps:

Verify container is running:

GET /api/v1/containers/{id}
# Check: "status": "running"

Wait for services to start:
- Container may be running but services still initializing
- Wait 30-60 seconds after status: "running"

Check runtime information:

GET /api/v1/containers/{id}?runtime=true

# Verify services are listed in runtime_info

Verify hoody_kit was enabled:

GET /api/v1/containers/{id}
# Check: "hoody_kit": true

What’s Next

Your container is running:

Managing Containers → - Start, stop, pause, resume operations
Snapshots → - Backup and restore your container state
Copy & Sync → - Duplicate containers across projects/servers

Configure access and networking:

Hoody Proxy → - Make services accessible
Network Configuration → - Proxy/VPN routing
Firewall → - Security rules

Understanding gained:

Containers are created via HTTP POST
Hoody Kit provides the full HTTP service stack automatically
Container configuration can be updated (when stopped)
Deletion is permanent (snapshot first!)
Service URLs follow predictable pattern

Spawn containers like you spawn URLs.
Configure them via HTTP.
Delete them when you’re done.
This is the foundation of infinite computers.