Security Principles

Traditional security defends a thousand entry points across a million configurations, with an endless stream of patches and vulnerabilities to keep up with. Hoody’s approach is different: all traffic is HTTP, all workloads run in containers, and every container starts isolated. Security is built in by default, which reduces friction while enabling the future described in The 100x Foundation, where humans orchestrate AI at scale. The attack surface collapses from thousands of vectors to one: your browser.

One protocol

Traditional computing runs SSH, RDP, VNC, FTP, custom protocols, and binary APIs side by side. Every protocol is an attack vector with its own security model. Hoody uses HTTP for everything, so there is one protocol to secure and monitor. When everything speaks HTTP, the security model reduces to securing web traffic, an area refined over 30 years.

Why HTTP works for Hoody

We chose HTTP not because it is universally superior, but because it fits this specific architecture. Hoody is built around containers that need to be reachable from anywhere: phones, tablets, browsers, AI agents, IoT devices. HTTP is the one protocol that works everywhere without special clients or configuration.

The practical benefits for this use case:

Universal compatibility: every device speaks HTTP, with no client to install
Single protocol to secure: one protocol instead of SSH, RDP, VNC, FTP, and a set of custom protocols
Browser sandboxing: access via browser inherits decades of sandboxing improvements
Observable by default: HTTP traffic is easier to log, monitor, and audit than binary protocols
Works through firewalls: corporate networks that block everything else still allow HTTPS
Native embeddability: containers become iframe-able without special wrappers

The approach has tradeoffs. Binary protocols can be more efficient, native applications can access hardware directly, and custom protocols can implement specialized security models. For Hoody’s goal of making containers accessible from any device, by humans and AI alike, HTTP is the right balance of security, compatibility, and simplicity.

Cryptographic URL security

Every container gets a URL like this:

https://projectId-890abcdef12345678901cdef-display-1.node-us.containers.hoody.com

The math: a container ID is 24 hex characters, which is 2^96 possible combinations. Even if an attacker discovers your projectId:

at 1 billion attempts per second, guessing the container ID takes 2.5 × 10^12 years
with all global computing power, it still takes billions of years

This is what makes “open by default” workable: the URL itself is the secret. When you need more, layer on additional authentication.

Security components

Hoody’s security is not a sequential stack of layers. It is a set of complementary mechanisms that work in combination.

Unguessable URLs

Container IDs are 24 hex characters, a 2^96 keyspace
Enumeration is impossible: there is no way to scan for containers
Revocation is immediate: delete the container and the URL dies

Permissions

Access control runs at several levels, from the Hoody API down to individual services.

Hoody API access:

Auth tokens support IP whitelisting, expiration, and enable/disable
Tokens scope to specific realms

Container proxy permissions:

Project-level: applies to all containers in the project
Container-level: overrides project settings for specific containers
Authentication groups: JWT, password, IP-based, bearer tokens
Program-specific permissions per group (terminal, files, display, etc.)
Default policy: allow or deny

Service-level granularity:

Terminal: execute vs read-only
Files: read vs write vs delete
Database: query vs modify
Display: view vs control

See Proxy Permissions, Container Proxy Permissions, and API Tokens for complete configuration.

TLS everywhere

Every connection is HTTPS, without exception
Wildcard certificates (*.containers.hoody.com) keep your URLs out of Certificate Transparency logs
Modern protocols: HTTP/1.1, HTTP/2 and HTTP/3

Container isolation

The entire Hoody Kit (terminal, files, display, exec, database, browser, agent, and the rest) runs inside containers, never on the bare metal host. This architectural decision prevents compromised services from affecting the host system.

In practice:

Only minimal system services run on the bare metal, so the host stays clean
A compromised container does not take the host with it
Recovery is simple: delete the container and spawn a fresh replacement
Malware stays isolated to the container

Isolation technologies:

Hardened LXC: lightweight virtualization on the Hoody kernel, with optional full VM instances
Linux namespaces: kernel-enforced boundaries
Hardened kernel: custom-built (currently 7.1.5-hoody)
Seccomp filters: syscall restrictions
No shared kernel memory: containers cannot read each other’s RAM

Beyond the core isolation technologies, several optimizations keep large container counts cheap on your own hardware:

BTRFS copy-on-write: a container cloned from the same base image is born sharing its disk blocks, and only diverging blocks cost new space
BTRFS deduplication: a periodic pass reclaims blocks that became identical again after containers diverged
Shared kernel and page cache: one hundred containers running the same base Debian image do not cost 100x the resources

This allows spawning hundreds of containers without proportional resource consumption.

One optimization is deliberately absent: KSM (Kernel Samepage Merging), memory deduplication across containers, is not enabled on Hoody hosts. Merging identical memory pages between tenants is a documented side-channel primitive (it is why VMware disabled transparent page sharing by default), and Hoody does not trade isolation for RAM savings. The RAM density above comes from the shared page cache of a shared kernel, not from merging your pages with anyone else’s.

Dedicated infrastructure

You run your own container engine on dedicated servers you control. Unlike traditional cloud providers, where multiple customers share physical infrastructure, a Hoody server you rent or own runs your containers on your own bare metal. There is no shared hypervisor and no other customer’s containers on the machine.

Security benefits on dedicated servers:

Cross-tenant side-channel attacks (the Spectre and Meltdown class) are eliminated: no other customer shares your CPU
No hypervisor escape vulnerabilities
No shared kernel risks between customers
Container breaches stay within your isolated infrastructure

Performance benefits on dedicated servers:

No “noisy neighbor” problems: your containers never compete with strangers’ workloads
Predictable performance: no random slowdowns from other tenants
100% resource utilization: every CPU cycle and memory byte is yours

The free tier does not carry these four security benefits. A free server is a capped slice of a shared physical host that also carries other tenants’ slices, so the hardware, the CPU cache, and the kernel are shared with people you cannot audit. That shared condition is exactly what every bullet above depends on being absent. Container isolation, the proxy permission layer, firewalls, and snapshots all still apply; hardware exclusivity does not. Details and the full comparison: Security & Permissions, Layer 3 and Servers: The Free Tier.

Disk encryption

Always on, every machine: LUKS full-disk encryption is provisioned when a Hoody server is installed and managed by the orchestrator from then on. Free slice or rented metal, there is no toggle, because there is nothing for you to set up
The key is never on the machine it unlocks: the orchestrator supplies it out of band at boot, so reboots recover unattended and a removed drive stays ciphertext
Theft and seizure become hardware loss: someone who walks off with the chassis holds encrypted blocks, not your data
Not a defence against a live host: an unlocked volume is plaintext to host-level access; layer a crypt-wrapped backend or application-level encryption over it when data must stay opaque while the server runs

Snapshots

Snapshots give you recovery and forensics in one mechanism: restore a pre-compromise snapshot in seconds, preserve the compromised state for analysis, and compare snapshots to find the moment of the breach. There is no downtime; production runs from the clean snapshot while you investigate.

Realms

Realms segregate the Hoody API, not container networks:

https://{realmId}.api.hoody.com

The purpose:

AI agents in one realm cannot discover containers in another
Auth tokens scope to specific realms
Production, staging, and development are completely separated at the API level
Teams and clients get multi-tenant isolation

Container firewalls

Firewall rules are enforced at the host level, where containers cannot tamper with them:

Ingress and egress rules per container
Port-level granularity
Protocol filtering: TCP, UDP, and ICMP controls
Default-allow stance: rules drop what you name

You can also add iptables, nftables, or ufw inside containers for defense in depth. See Container Firewalls for complete configuration.

Controlled egress

Containers have no dedicated public IPv4:

Each container has a private IPv4, masqueraded behind the host’s address
Egress to public IPv4 is open until you configure an exit
Configure an exit to force a single, controllable egress path

Exit options are set at the host level, where containers cannot tamper with them:

SOCKS5/HTTP/HTTPS proxies as exit nodes
Commercial VPN endpoints: point a container at any provider’s internet-reachable SOCKS5/HTTPS proxy endpoint with no in-container configuration (native WireGuard routing is planned for a future update)
Block mode to prevent all outgoing traffic
Custom DNS servers (up to 4)

This suits location rerouting, since there is nothing to manage inside the container. See Container Network Configuration for setup.

Observability

When everything is HTTP, everything can be observed. Using hoody-exec, you can intercept and analyze the HTTP traffic entering your containers:

Scan inputs for malicious payloads
Create complete audit trails
Rate limit to prevent abuse
Validate against policies
Detect threats in real time

Use hoody-exec to build observability pipelines that intercept and analyze traffic across services.

Gateway containers (jumphost)

A gateway container fills the role a VPN usually would, in a form that fits HTTP-native infrastructure. Traditional VPNs are complex to configure, require specific clients on every device, and create a single point of failure. A gateway container gives you the same network access model through plain HTTP, with no special software and no configuration files; a device only needs the URL.

Your Device (Browser Only)  →  Gateway Container  →  Working Containers

A gateway container is just another Hoody container, but you use it exclusively as your entry point. It runs whatever MITM tooling you install and holds whatever permissions you grant it, and it acts as your controlled proxy into the rest of your infrastructure.

From this gateway, you can:

Reach your other containers through their container URLs
Route requests through different exit nodes
Apply organization-wide security policies
Log and audit every action across your fleet
Give temporary access to outsiders without exposing your real infrastructure

Compared with a traditional VPN:

No client installation: works from any browser on any device, including a phone, a tablet, a borrowed laptop, or an internet café
Fast provisioning: a gateway container spins up in moments rather than hours of VPN configuration
Per-user isolation: each contractor or team gets its own gateway container with specific permissions
Disposable: if you suspect compromise, delete the gateway, spawn a new one, and update the URL
Auditability: every action is an HTTP request with complete logging, not opaque VPN tunnel traffic
Works everywhere: corporate firewalls that block VPN protocols allow HTTPS
Multiplayer by default: share the gateway URL with your team and everyone sees the same environment
MITM control: inspect, modify, or block any request flowing through your infrastructure

The result is the network isolation model of a VPN, made HTTP-native, browser-accessible, and more flexible. There are no OpenVPN configs or WireGuard keys to distribute and no per-machine setup to drift out of sync. A URL grants secure network access over plain HTTP.

What Hoody can and cannot see

The line between what Hoody can and cannot observe is architectural. Through the Hoody API (api.hoody.com or {realmId}.api.hoody.com), Hoody can see:

Container lifecycle events (creation, deletion, snapshots)
Project and realm configurations
Storage share mounts and network setup
Billing and authentication activity
API request metadata (timestamps, IP addresses, endpoints called)

See the Privacy Policy for complete details on data handling.

Because the Hoody proxy runs on your server, on your bare metal host, Hoody is not aware of:

What you host on containers (websites, tools, applications)
The content of what you serve, beyond what the request line shows
Container activity and operations
Terminal commands executed
Files accessed or modified
Database queries and data
AI agent prompts or responses
HTTP logs from your services
Internal container communications

While Hoody does not observe your container activity, you remain responsible for complying with the Acceptable Use Policy.

The architecture:

Hoody API (api.hoody.com)
├─ Sees: Container management, billing, configuration
└─ Cannot see: Container traffic, content, activity

Your Bare Metal Server(s)
└─ Hoody Proxy (Your Infrastructure)
    ├─ Routes: All container traffic
    ├─ Enforces: Network policies, firewalls
    └─ Data locality: No central Hoody proxy tier in the path

Your Containers
└─ No central Hoody data plane in the path

AI privacy and control

You are free to use any AI setup you want. Install your own agents, use any provider (OpenAI, Anthropic, local models), or connect directly to AI services; it is your infrastructure.

We recommend Hoody AI for what its gateway gives you:

Proxy on your server: it runs on the host, not inside containers
Your choice of models: Claude Opus 4.1, Sonnet 4.5, GPT-4o, Gemini 2.5 Pro Exp, Llama, Qwen, or any provider
Local routing: requests pass through your hardware before reaching external providers
Full request interception: point any AI client at one of your own hoody-exec scripts instead of the gateway, and every prompt and response passes through your JavaScript in plaintext, to log, transform, cache, or reroute (how)
Local audit trails: the gateway records per-request metadata (route, key, status, latency) on your server; prompt and response bodies are captured only by an interception script you deploy

This keeps full control and observability on your side while staying compatible with any AI service.

Realistic security posture

Supply chain risk

Compromised dependencies remain an industry-wide problem. NPM packages, system libraries, Docker images: the software supply chain has countless potential points of failure, and that affects every platform, not just Hoody.

Hoody’s focus is infrastructure isolation and rapid recovery, not solving supply chain security. When a dependency is compromised:

Container isolation keeps a compromised container to itself, so the compromise does not spread
Snapshots allow immediate rollback to known-good states
Realms prevent cross-contamination between projects
HTTP observability helps detect unusual behavior faster

Hoody does not claim to prevent supply chain attacks. That is a broader ecosystem problem, requiring solutions at the package manager, build tool, and distribution levels, beyond any single platform’s scope.

The future described in The 100x Foundation depends on trusting AI-generated code and third-party packages. Hoody provides the isolation and recovery mechanisms that make that trust viable: fast, clean recovery rather than prevention.

What Hoody improves

Attack surface: from thousands of protocol endpoints to a single HTTP entry point
Recovery: from hours or days of patching to seconds restoring a snapshot
Auditing: from scattered logs to unified HTTP logging
Forensics: from lost evidence to full state preservation

What remains complex

Application security still requires careful coding
Authentication still needs proper implementation
Network policies still need configuration
Security patches and updates still need to be applied
Human factors remain the weakest link

Summary

Hoody’s security model provides:

Simpler security through protocol unification
Faster recovery through snapshot restoration
Better visibility through HTTP observability
Reduced surface through a single HTTPS entry point
Complete forensics through state preservation
AI privacy through self-hosted infrastructure and MITM capability

When everything is containerized, HTTP-native, and snapshot-able, security becomes more manageable, not magical. The difference from traditional security is not perfection but simplification: one entry point, protected by an unguessable 96-bit identifier and fully observable, instead of thousands of separately secured services.

Next: Getting Started