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: HTTP carries nearly all traffic, 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 HTTPS for its API and its URL-addressed Kit services, so there is one protocol to secure and monitor; optional direct SSH to a container is the deliberate exception. 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: applies alongside the project document; both are evaluated together, and the container default takes precedence when present
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: which instances each group can reach
Files: access on or off per group
HTTP: which ports each group can reach

Rules grant access per service and per instance or port; a grant is full access to that instance or port, with no read-only variant.

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

TLS everywhere

Every URL-addressed service and the API are HTTPS; native SSH access uses the SSH protocol with its own authentication
Wildcard certificates (*.{serverName}.containers.hoody.com) keep your URLs out of Certificate Transparency logs
Modern protocols: HTTP/1.1 and HTTP/2 always, HTTP/3 over QUIC where the server supports it

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. A compromised service is contained at the container boundary, which the host kernel enforces; reaching the host takes a kernel or runtime vulnerability. A process inside a container can be confined further with an optional program sandbox: run it as a daemon program with a sandbox block to restrict its filesystem writes, TCP ports and resources. It needs a non-root account, and a container does not apply one by itself.

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 inside the container, apart from shared storage, credentials and network access you granted

Isolation technologies:

Hardened container runtime: lightweight system containers on the Hoody kernel, with optional full VM instances
Linux namespaces: kernel-enforced boundaries
Hardened kernel: custom-built
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: blocks that become identical again after containers diverge stop costing extra space
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 application-level encryption over it, encrypting files before you upload them, 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 see which files changed and narrow the window. Restoring puts the disk back, stopping and restarting a container that was running, so expect a short interruption rather than none, and run from a second container if you need to stay up 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:

Per-container rules: ingress and egress rules for each container
Port-level granularity: rules can target individual ports
Protocol filtering: TCP, UDP, and ICMPv4 (icmp4) controls
Default-allow stance: everything passes until you add rules, and each rule can allow, reject, or drop the traffic it matches

You can also add iptables, nftables, or ufw inside containers for defense in depth. A tool that flushes nftables inside the container also removes the per-program sandbox ingress rules, and running programs keep listening unfiltered until the rules are reinstalled; see Program Sandbox. 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)
Usage counters your proxy reports: request counts and response byte totals, per container and per Kit service

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
What runs inside a container, beyond the usage counters listed above
Terminal commands executed
Files accessed or modified
Database queries and data
AI agent prompts or responses
HTTP logs from your services
Internal container communications

Your usage counters break down per container and per Kit service, by day and by month. They never carry request paths, payloads, or responses.

Hoody does not observe what you run inside a container, and you remain responsible for complying with the Acceptable Use Policy.

The architecture:

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

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: MiniMax, Qwen, DeepSeek, Llama, Mistral, Grok, and the rest of the gateway catalog. OpenAI, Anthropic, and Google models are not in that catalog; to use them, set the vendor’s own API key inside your container and call the vendor directly
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 limits a compromised container’s direct access to other containers’ files and processes; shared storage, credentials and permitted network access remain reachable, and replacing the container does not undo effects there
Snapshots allow immediate rollback to known-good states
Realms scope Hoody API access; they do not stop compromised code from using shared storage, credentials or permitted network connections
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 the filesystem state preserved in a snapshot, with logs kept separately for what a disk image cannot show

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