Security Principles

Traditional security is a house of cards. A thousand entry points. A million configurations. Endless patches, endless vulnerabilities, endless complexity.

Hoody’s approach: Everything flows through HTTP. Everything lives in containers. Everything starts isolated. Security is built-in by default—reducing friction while enabling the 100x future where humans orchestrate AI at scale.

The result? Your attack surface collapses from thousands of vectors to one: your browser.

One Protocol, Focused Security

Traditional Computing: SSH, RDP, VNC, FTP, custom protocols, binary APIs. Every protocol is an attack vector requiring separate security models.

Hoody: HTTP for everything. One protocol to secure, monitor, and control.

When everything speaks HTTP, your entire security model simplifies to securing web traffic—something we’ve been perfecting for 30 years.

Why HTTP Works for Hoody

We chose HTTP not because it’s universally superior, but because it fits our specific architecture perfectly.

Hoody is built around containers that need to be accessible 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 our use case:

Universal compatibility: Every device speaks HTTP—no client installation needed
Single protocol to secure: Instead of securing SSH + RDP + VNC + FTP + custom protocols, we focus on one
Browser sandboxing: When accessed via browser, you inherit 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 still allow HTTPS
Native embeddability: Containers become iframe-able without special wrappers

The tradeoffs we accept:

This approach isn’t perfect. Binary protocols can be more efficient. Native applications can access hardware directly. Custom protocols can implement specialized security models.

But for Hoody’s goal—making containers accessible from any device, by humans and AI alike—HTTP provides 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.icu

The Math: Container ID = 24 hex characters = 2^96 possible combinations

Even if an attacker discovers your projectId:

At 1 billion attempts/second: 2.5 × 10^12 years to guess
Using all global computing power: Still billions of years

This enables “open by default”—the URL itself is the secret. When you need more, layer on additional auth.

Security Components

Hoody’s security isn’t layered sequentially—it’s a combination of complementary mechanisms working together:

Unguessable URLs

24 hex character container IDs = 2^96 keyspace
No enumeration possible—can’t scan for containers
Instant revocation—delete container, URL dies

Permissions

Multi-layered access control from API to service level:

Hoody API Access:

Auth tokens with IP whitelisting, expiration, enable/disable
Scope tokens to specific realms

Container Proxy Permissions:

Project-level (applies to all containers in 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 HTTPS—no exceptions
Wildcard certificates (*.containers.hoody.icu)—your URLs never appear in Certificate Transparency logs
Modern protocols—HTTP/1.1, HTTP/2 and HTTP/3

Container Isolation

Hoody Kit services run inside containers, never on the host.

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

Why this matters:

Host stays pristine: Only minimal system services run on bare metal
Compromise stays local: a compromised container does not take the host with it
Easy recovery: Delete container, spawn fresh replacement
No host contamination: 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 can’t read each other’s RAM

Efficient Scaling (On Your Own Hardware):

Beyond the core isolation technologies, Hoody employs advanced optimizations to enable massive scale:

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.

What Hoody deliberately does not do: memory deduplication across containers — KSM, Kernel Samepage Merging — 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 bare metal—no hypervisor sharing, no neighbor containers from other customers.

Security benefits (dedicated servers):

Cross-tenant side-channel attacks (Spectre, Meltdown class) 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 (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 — which is exactly the condition 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: Time-Travel Security

Instant recovery and forensics: Restore pre-compromise snapshot in seconds, preserve compromised state for analysis, compare snapshots to find breach moment. Zero downtime—production runs from clean snapshot while you investigate.

Realms: API-Level Isolation

Realms segregate the Hoody API, not container networks:

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

Purpose:

AI agents in one realm can’t discover containers in another
Auth tokens scope to specific realms
Production/staging/development completely separated at API level
Multi-tenant isolation for teams/clients

Container Firewalls

Host-level network control (not tamperable by containers):

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

Additional layers: Users can add iptables, nftables, or ufw inside containers for defense-in-depth.

See Container Firewalls for complete configuration.

Controlled Egress

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

Host-Level Exit Options (not tamperable by containers):

SOCKS5/HTTP/HTTPS proxies as exit nodes
Commercial VPN endpoints—point a container at any provider’s internet-reachable SOCKS5/HTTPS proxy endpoint with zero 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)

Ideal for location rerouting with zero container management overhead.

See Container Network Configuration for setup.

Observability

When everything is HTTP, everything becomes observable.

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
Real-time threat detection

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

Gateway Containers (Jumphost)

Think of it as a poor man’s VPN—but more appropriate for HTTP-native infrastructure.

Traditional VPN solutions are complex to configure, require specific clients on every device, and create a single point of failure. Gateway containers give you the same network access model but through pure HTTP—no special software, no configuration files, just a URL.

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

How it works:

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, acting as your secure 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

Why this beats traditional VPNs:

Zero client installation: Works from any browser on any device—phone, tablet, borrowed laptop, internet café
Instant provisioning: Spin up a gateway container in moments, not hours of VPN configuration
Per-user isolation: Each contractor/team gets their own gateway container with specific permissions
Disposable security: Suspect compromise? Delete gateway, spawn new one, update URL—done in moments
Better 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 gateway URL with team, everyone sees same environment
MITM superpowers: Inspect, modify, or block any request flowing through your infrastructure

It’s the network isolation model of VPNs, but HTTP-native, browser-accessible, and infinitely more flexible. No OpenVPN configs. No WireGuard keys. No “it works on my machine but not yours.” Just a URL that grants secure network access through pure HTTP.

What Hoody Knows (And Doesn’t Know)

Technical transparency about data visibility:

What Hoody IS Aware Of:

Through the Hoody API (api.hoody.icu or {realmId}.api.hoody.icu), we 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 our Privacy Policy for complete details on data handling.

What Hoody is NOT Aware Of:

Because the Hoody Proxy runs on YOUR server (on your bare metal host):

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 our Acceptable Use Policy.

The Architecture:

Hoody API (api.hoody.icu)
├─ 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 & Control

You’re 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’s your infrastructure.

Why we recommend Hoody AI:

When using our AI gateway:

Proxy on YOUR server—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
Requests route 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 gives you complete control and observability while maintaining compatibility with any AI service.

Realistic Security Posture

The Dependency Problem

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

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

Container isolation keeps a compromised container to itself—it doesn’t spread
Snapshots enable instant rollback to known-good states
Realms prevent cross-contamination between projects
HTTP observability helps detect unusual behavior faster

But we don’t claim to prevent supply chain attacks. That’s a broader ecosystem problem requiring solutions at the package manager, build tool, and distribution levels—beyond any single platform’s scope.

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

What Hoody Improves

Attack Surface: Thousands of protocols → Single HTTP entry point
Recovery: Hours/days to patch → Seconds to restore from snapshot
Auditing: Scattered logs → Unified HTTP logging
Forensics: Lost evidence → Perfect state preservation

What Remains Complex

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

Key Principles

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.

Traditional security: Thousands of doors, each with different locks
Hoody security: One door, cryptographically sealed, fully observable
The difference: Not perfection, but radical simplification.

Next: Getting Started →