Skip to content
Hoody Documentation
Download Page (.md)

Zero-Knowledge Workflows

Section titled “Zero-Knowledge Workflows”

Every cloud provider makes the same promise: “Your data is secure.” Then they read your data to train AI models, hand it to governments without telling you, or suffer breaches that expose millions of records. The promise is structurally impossible to keep because their architecture requires them to have access to your data in order to serve it.

Hoody’s architecture is different. Not because we are more trustworthy — because the system does not require trust.

You rent bare metal servers. Physical machines. Not virtual instances on shared hardware. Not containers on someone else’s hypervisor. Actual hardware where you control the disk, the memory, the network, and the encryption keys. Your containers run on hardware you control. We cannot read your data because we do not have access to the hardware it lives on.

This is not a privacy feature. It is the architecture.

What Zero-Knowledge Means in Hoody

Section titled “What Zero-Knowledge Means in Hoody”

Zero-knowledge means the platform operator (Hoody) cannot access your data even if compelled to do so. Here is how:

LayerTraditional CloudHoody
HardwareShared with other tenantsDedicated bare metal you control
HypervisorProvider-controlledNone — containers run on your hardware
Disk encryptionProvider holds the keysYou hold the keys
NetworkProvider can inspect trafficEncrypted within your server
BackupsProvider can read snapshotsSnapshots live on your disk
AI trainingYour data may be usedYour data never leaves your hardware

The fundamental difference: in traditional cloud, the provider is in the trust chain. In Hoody, the provider is not. Your server is a physical machine. Your containers are processes on that machine. Your data is bytes on that disk. Hoody manages the orchestration layer — container creation, proxy routing, service coordination — but your actual data stays on hardware you control.

Encrypted Filesystems

Section titled “Encrypted Filesystems”

hoody-files supports encrypted storage through the crypt backend. Files are encrypted before they hit the disk and decrypted on read. The encryption key never leaves your container.

Terminal window
# Configure encrypted storage backend
hoody files backends connect crypt \
  --remote "/secure-data" \
  --password "$ENCRYPTION_KEY"


# Write a file to encrypted storage
hoody files put secrets/api-keys.json \
  --backend "encrypted-vault"


# Read it back -- transparently decrypted
hoody files get secrets/api-keys.json \
  --backend "encrypted-vault"

What happens on disk: The file secrets/api-keys.json is stored as encrypted bytes. If someone physically extracts the disk, they get ciphertext. If someone gains shell access without the encryption key, they get ciphertext. The file is only readable through the hoody-files service with the correct key.

Vault Secrets Management

Section titled “Vault Secrets Management”

For secrets that need to be available to applications without storing them in plaintext files, use hoody-sqlite’s KV store as a secrets vault:

Terminal window
# Store secrets in the KV store (--db is required; --create-db-if-missing on first use)
hoody kv set "vault:stripe_key" --db /hoody/databases/app.db --create-db-if-missing \
  --body '"sk_live_abc123..."'


hoody kv set "vault:database_url" --db /hoody/databases/app.db \
  --body '"postgres://user:pass@host:5432/db"'


hoody kv set "vault:jwt_secret" --db /hoody/databases/app.db \
  --body '"your-256-bit-secret"'


# Retrieve secrets programmatically
hoody kv get "vault:stripe_key" --db /hoody/databases/app.db

The KV store lives in SQLite, which lives on your bare metal disk. Secrets never traverse infrastructure you do not control. Combine with the crypt backend for defense in depth — encrypted filesystem holding an encrypted database holding your secrets.

Container Isolation as the Security Boundary

Section titled “Container Isolation as the Security Boundary”

Each container is a complete, isolated Linux environment. The isolation is not just logical — it is enforced at the operating system level:

┌──────────────────────────────────────────────────┐
│                 YOUR BARE METAL SERVER            │
│                                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌──────────┐ │
│  │ Container A  │  │ Container B  │  │ Cont. C  │ │
│  │             │  │             │  │          │ │
│  │ Own files   │  │ Own files   │  │ Own files│ │
│  │ Own network │  │ Own network │  │ Own net  │ │
│  │ Own procs   │  │ Own procs   │  │ Own procs│ │
│  │ Own users   │  │ Own users   │  │ Own users│ │
│  │             │  │             │  │          │ │
│  │ CANNOT SEE  │  │ CANNOT SEE  │  │ CANNOT   │ │
│  │ B or C      │  │ A or C      │  │ SEE A, B │ │
│  └─────────────┘  └─────────────┘  └──────────┘ │
│                                                  │
│  Shared: CPU, RAM, Disk (but isolated views)     │
└──────────────────────────────────────────────────┘

What container isolation means in practice:

  • Container A cannot read Container B’s files, even though they share the same physical disk
  • A process in Container A cannot see or kill processes in Container B
  • Network traffic is isolated — containers cannot sniff each other’s traffic
  • A compromised container cannot escape to the host or other containers
  • An AI agent running in Container A has full root access inside A and zero access outside A

This is why container isolation is the correct security primitive for the AI era. When you give an AI agent root access to a container, the blast radius is exactly one container. Not your server. Not your other projects. Not your data.

Privacy Patterns

Section titled “Privacy Patterns”

Pattern 1: Realm-Restricted Tokens for Tenant Isolation

Section titled “Pattern 1: Realm-Restricted Tokens for Tenant Isolation”

When building multi-tenant applications, use realms to create isolated API scopes:

Terminal window
# NOTE: There is no hoody realms create CLI command.
# Realms are configured through the Hoody dashboard.
# List existing realms:
hoody realms list


# Create containers within each realm
hoody containers create --project $PROJECT_ID \
  --server-id $SERVER_ID \
  --name "acme-app" \
  --hoody-kit


hoody containers create --project $PROJECT_ID \
  --server-id $SERVER_ID \
  --name "globex-app" \
  --hoody-kit

Realm-scoped API tokens can only access containers within their realm. A token for tenant-acme-corp cannot see, list, or access any container in tenant-globex-inc. The isolation is enforced at the API level.

Pattern 2: Encrypt Data at Rest

Section titled “Pattern 2: Encrypt Data at Rest”

Layer encryption for sensitive data:

// Layer 1: hoody-files crypt backend encrypts the filesystem
// Layer 2: Application-level encryption for specific fields


// @mode serverless
const SQLITE = "https://PROJECT-CONTAINER-sqlite-1.SERVER.containers.hoody.icu";


// Store with application-level encryption
const crypto = require('crypto');
const key = Buffer.from(process.env.ENCRYPTION_KEY, 'hex');
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);


const sensitiveData = JSON.stringify({ ssn: '123-45-6789', salary: 150000 });
let encrypted = cipher.update(sensitiveData, 'utf8', 'hex');
encrypted += cipher.final('hex');


await fetch(SQLITE + "/api/v1/sqlite/db?db=/hoody/databases/app.db", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    transaction: [{ query: "INSERT INTO employee_records (name, encrypted_data, iv) VALUES (?, ?, ?)", values: ["Alice Chen", encrypted, iv.toString('hex')] }]
  })
});

Two layers: the filesystem is encrypted by the crypt backend, and sensitive fields are encrypted again at the application level. Even if someone bypasses the filesystem encryption, the data inside is still ciphertext.

Pattern 3: Control Network Egress with Firewall

Section titled “Pattern 3: Control Network Egress with Firewall”

Prevent containers from sending data to unauthorized destinations:

Terminal window
# Lock down outbound traffic
hoody firewall reset -c $CONTAINER_ID


# Resolve the hostnames you want to allow to IPv4/CIDR first — the firewall
# API only accepts numeric destinations (host `dig +short api.stripe.com`).
STRIPE_CIDR=$(dig +short api.stripe.com | awk '{print $1"/32"; exit}')
GITHUB_CIDR=$(dig +short api.github.com  | awk '{print $1"/32"; exit}')


hoody firewall egress create -c $CONTAINER_ID \
  --action allow --protocol tcp --destination-port 443 \
  --destination "$STRIPE_CIDR" --description "Allow Stripe API"


hoody firewall egress create -c $CONTAINER_ID \
  --action allow --protocol tcp --destination-port 443 \
  --destination "$GITHUB_CIDR" --description "Allow GitHub API"

With egress deny-all, the container cannot phone home, cannot exfiltrate data, cannot communicate with any server you have not explicitly approved. This is essential when running untrusted code or AI agents that might attempt to send data externally.

Compliance and Data Sovereignty

Section titled “Compliance and Data Sovereignty”

Physical servers mean physical locations. This is the simplest compliance argument there is:

Data residency: Your server is in Frankfurt. Your data is in Frankfurt. Not “primarily” in Frankfurt. Not “replicated from” Frankfurt. Physically, magnetically, on a disk in Frankfurt.

GDPR: European personal data lives on European hardware. Period. No transatlantic transfer to worry about, no data processing agreements with cloud sub-processors, no “our servers might be anywhere” hedging.

HIPAA: Protected health information on dedicated hardware with encrypted filesystems, firewall-controlled network access, and container isolation between patient datasets.

SOC 2: Audit trail through HTTP request logs. Access control through proxy permissions. Encryption through crypt backend. Isolation through containers. Every compliance requirement maps to an HTTP-observable, configurable control.

┌────────────────────────────────────────────────┐
│  YOUR SERVER: Frankfurt, Germany               │
│  Physical address: DataCenter GmbH, Room 4B    │
│                                                │
│  Container: patient-records                    │
│  ├── Encrypted filesystem (crypt backend)      │
│  ├── Firewall: egress deny-all                 │
│  ├── Proxy: IP whitelist (clinic IPs only)     │
│  ├── Realm: healthcare-prod                    │
│  └── Snapshots: daily, 90-day retention        │
│                                                │
│  Data location: This building. This rack.      │
│  Data access: Clinic IPs only.                 │
│  Data encryption: AES-256, keys on-server.     │
│  Data retention: 90-day snapshot history.       │
│  Audit trail: Every HTTP request logged.        │
└────────────────────────────────────────────────┘

Try expressing that compliance posture with a shared cloud VM. You cannot. The architecture prevents it.

The AI Safety Angle

Section titled “The AI Safety Angle”

Here is the argument that makes zero-knowledge workflows urgent rather than merely prudent:

AI agents running in your infrastructure can see everything. When you give an AI agent access to a container — terminal, files, database, browser — it has the same access as a developer. It can read credentials, query databases, browse the filesystem.

On shared infrastructure, a compromised or misbehaving AI agent could:

  • Exfiltrate data through network requests
  • Access other tenants’ resources through hypervisor vulnerabilities
  • Persist malicious code that survives container restarts
  • Send your data to the AI provider’s training pipeline

On Hoody’s bare metal + container architecture:

  • Container isolation prevents the agent from escaping its sandbox
  • Firewall rules prevent unauthorized network communication
  • Snapshots let you roll back any changes the agent made
  • Bare metal means no hypervisor attack surface
  • Encrypted filesystems mean even disk-level access yields ciphertext
Terminal window
# The AI safety workflow:


# 1. Create an isolated container for the experiment and capture its ID
EXPERIMENT_ID=$(hoody containers create --project $PROJECT_ID \
  --server-id $SERVER_ID \
  --name "ai-experiment" \
  --hoody-kit | jq -r '.data.id')


# 2. Lock down network
hoody firewall reset -c $EXPERIMENT_ID


# 3. Snapshot clean state
hoody snapshots create --container $EXPERIMENT_ID \
  --alias "clean-slate"


# 4. Let the AI agent run via the prompt endpoint
curl -X POST "https://$PROJECT_ID-$EXPERIMENT_ID-workspaces-1.$SERVER.containers.hoody.icu/api/v1/agent/prompt/sync" \
  -H "Content-Type: application/json" \
  -d '{"parts": [{"type": "text", "text": "Analyze this dataset and build a classification model"}], "autoApprove": true}'


# 5. Inspect results
# 6. Restore clean state if needed
hoody snapshots restore -c $EXPERIMENT_ID --name "clean-slate"

The AI agent has full autonomy inside an air-gapped container. It can read data, write code, run experiments — but it cannot exfiltrate anything because the firewall blocks all outbound traffic. When the experiment is done, inspect the results. If anything looks wrong, restore the clean snapshot. The data never left your hardware.

Defense in Depth

Section titled “Defense in Depth”

The strongest security posture layers multiple controls:

Layer 1: Bare Metal        → No shared hardware, no hypervisor attack surface
Layer 2: Container          → Process isolation, filesystem isolation
Layer 3: Firewall           → Network egress control, deny-all default
Layer 4: Proxy Permissions  → Authentication before HTTP reaches the container
Layer 5: Encrypted FS       → Data encrypted at rest (crypt backend)
Layer 6: Application        → Field-level encryption, input validation
Layer 7: Snapshots          → Rollback capability, audit via diff
Layer 8: Realms             → API-level tenant isolation

Each layer is independently configurable through HTTP. Each layer can be audited through HTTP. Each layer is a security boundary that an attacker must breach independently. Compromise one layer and the others still hold.

This is not defense in depth as a marketing term. It is eight distinct, HTTP-configurable security boundaries between an attacker and your data.

What’s Next

Section titled “What’s Next”