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 Auth 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

All 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
Blast radius contained: Compromised container can’t escape to host
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.0.0-rc5-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:

KSM (Kernel Samepage Merging)—shares identical memory pages across containers to optimize RAM usage
BTRFS deduplication—eliminates duplicate data blocks for storage efficiency

This allows spawning hundreds of containers without proportional resource consumption.

Dedicated Infrastructure

You run your own container engine on dedicated servers you control.

Unlike traditional cloud providers where multiple customers share physical infrastructure, Hoody containers run on your bare metal—no hypervisor sharing, no neighbor containers from other customers.

Security benefits:

Side-channel attacks (Spectre, Meltdown) eliminated
No hypervisor escape vulnerabilities
No shared kernel risks between customers
Container breaches stay within your isolated infrastructure

Performance benefits:

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

Disk Encryption (LUKS)

AES-256 encryption at rest
Encrypted swap and temporary files
Sub-partition remote unlock—requires authorized remote mechanism

Snapshots: Time-Travel Security

Instant recovery and forensics: Restore pre-compromise snapshot (30 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-deny stance

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

See Container Firewalls for complete configuration.

Controlled IPv4 Routing

No direct IPv4 by default:

Containers have no IPv4 address by default
All external traffic routes through Hoody Proxy
Forces observable, controllable network access

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

SOCKS5/HTTP/HTTPS proxies as exit nodes
WireGuard VPN integration
Commercial VPN providers (Mullvad, iVPN, AirVPN, etc.) - zero in-container configuration
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 all traffic:

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 with elevated permissions and MITM capabilities, acting as your secure proxy into the rest of your infrastructure.

From this gateway, you can:

Access all other containers via their internal network
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 30 seconds, 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—60 seconds total
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 (in a container on your bare metal):

❌ What you host on containers (websites, tools, applications)
❌ Container traffic content
❌ 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 we cannot see 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 Container (Your Infrastructure)
    ├─ Routes: All container traffic
    ├─ Enforces: Network policies, firewalls
    └─ Zero-knowledge: Traffic never reaches Hoody infrastructure

Your Containers
└─ Complete privacy for all operations

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—self-hosted in a container
Your choice of models—Claude Opus 4.1, Sonnet 4.5, GPT-5, Gemini 2.5 Pro, Llama, Qwen, or any provider
Requests route through your hardware—before reaching external providers
Complete MITM capability—any container can intercept/inspect prompts or responses
Local audit trails—all AI interactions logged on your server

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 limits the blast radius—one compromised container 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 containment, 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 browser-only access
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 →