Run dozens of containers on one server without giving up isolation.
KSM memory sharing packs density into bare metal. Firecracker + LXC enforce per-container isolation. URL unguessability, realm segregation, and host-level firewall layer on top — every one can fail, and the others still stop the blast.
KSM · LXC + Firecracker · AES-256 · URL 2^192 keyspace · defense in depth
Shared pages, separate memory.
Kernel Samepage Merging collapses identical memory pages across containers into single physical copies. A base Debian image, a Node runtime, a Postgres install — all the bytes that every container on the server shares end up counted once in RAM.
Identical pages deduplicated
RAM pages with identical content (common libraries, base OS, shared runtimes) get merged. 30 Node containers on one server consume far less memory than 30× one container.
Isolation preserved
Containers cannot read each other's RAM. KSM is a storage optimization — merged pages become copy-on-write. Any write forks a private copy instantly.
No container-side work
KSM is kernel-level. Applications don't need to know about it. The container sees normal Linux memory; the host sees physical deduplication.
Load-dependent benefit
Benefit scales with how much containers share. Similar stacks = huge dedup. Wildly different apps = less dedup, but baseline OS pages still merge.
LXC + Firecracker. Kernel namespaces + micro-VMs.
Hoody uses a dual-layer isolation model. LXC provides lightweight Linux container isolation via namespaces. Firecracker adds hardware-assisted micro-VM boundaries where stronger separation matters. The host kernel is hardened (Linux 7.0.2-hoody base) with seccomp syscall filtering on top.
LXC namespaces
Process, network, mount, user, PID, IPC — each container has its own view of the kernel. Standard Linux mechanism, battle-tested at scale.
Firecracker micro-VMs
Hardware-virtualized boundaries. AWS Lambda's isolation technology. Applied where a container needs an even harder wall than namespaces alone.
Hardened kernel
Linux 7.0.2-hoody base with security hardening. Seccomp filters restrict which syscalls a container can make.
Bare-metal baseline
Containers run on user-owned hardware. No shared hypervisor with other tenants. No noisy-neighbor side channels from the cloud provider above you.
AES-256 everywhere data touches disk.
Filesystem encryption, encrypted swap, encrypted tempfiles. Remote unlock via sub-partition. The disk is ciphertext; the decryption happens in RAM on boot.
Filesystem AES-256
Every byte written to disk is encrypted. Lose the drive, lose nothing readable.
Encrypted swap + temp
Swap pages and tempfiles never hit disk in cleartext. Kernel memory dumps are encrypted too.
Sub-partition remote unlock
Boot flow supports remote decryption over SSH into the initramfs. No disk keys physically stored with the data.
2^192 combinations. Brute force isn't the attack.
Project IDs are 24 hex characters. Container IDs are 24 hex characters. A valid URL requires both. The keyspace is 2^192 — at one trillion guesses per second, enumeration takes longer than the age of the universe. Unguessability is a starting default, not the only layer.
Pair keyspace
2^192
To enumerate at 1T/s
longer than universe age
Additional layers available
JWT · Password · IP · Token
Open-by-URL is the starting mode. Lock down any URL with JWT, HTTP Basic, IP CIDR, or bearer token via /platform/proxy — no application code required.
Six independent layers. Any one failure leaves five more.
Security is a stack, not a gate. Each layer is independently effective; together they make a single failure survivable.
URL unguessability
2^192 keyspace on project+container combos. The URL itself is the first secret.
Container isolation
LXC namespaces + Firecracker micro-VMs. Kernel-level separation.
Host-level firewall
Ingress + egress rules enforced at the host, not inside the container. Tamper-proof.
Proxy permissions
JWT / Password / IP / Token auth groups layered on top of URLs.
Realm segregation
API-level tenant isolation. Tokens scoped to specific realms.
Disk encryption
AES-256 at rest. Encrypted swap. Remote-unlocked boot.
Everything is an inspectable HTTP request.
Unified audit trails. Every action against a container is a proxy log entry. Any service can be MITM'd via hoody-exec or hoody-curl to add AI safety checks, logging, or rate limits without modifying the service.
Unified audit logs
Proxy logs cover every service. Query, export (NDJSON), stats aggregation — all via /platform/proxy log API.
MITM by design
Insert middleware between any service and its clients. Used for AI safety gates, compliance logging, rate limiting — no service changes required.
Platform fork
Every user can MITM the Hoody API itself to customize platform behavior — without forking the codebase.
Suspect a breach? Delete the container.
Every container URL dies the moment the container is deleted. No DNS propagation. No cache invalidation. No stale tokens to rotate. The URL was the surface; deleting the container removes the surface entirely.
DELETE /api/v1/containers/ID
One API call. Authenticated with your JWT or control-plane token.
URL stops routing
Proxy removes the routing entry. The hostname returns 404 immediately — not 60 seconds later.
Respawn in minutes
Create a new container with a new ID. New URL. Old URL is dead forever. No residual credentials to rotate.
Density and isolation are not tradeoffs here.
Bare metal. Hardened kernel. Encrypted disk. Six-layer defense. Every property is already true on your first container.
See also — /platform/proxy for URL permissions and auth groups, /platform/control-plane for realm/token management, /methods/access-network for firewall + egress.