Security & Permissions

Traditional infrastructure secures a dozen protocols, each with its own authentication model, encryption scheme, and vulnerability surface: SSH keys scattered across machines, VPN configs shared over Slack, database passwords in environment variables. Every protocol is another entry point to secure.

Hoody collapses this surface to one protocol (HTTPS with HTTP/2 and HTTP/3), one gateway (the proxy), and one enforcement point. Instead of securing 18 different services, you secure one proxy; instead of managing 6 different authentication mechanisms, you configure one permission layer. Certificate issuance and renewal need no configuration from you, and every URL is served over HTTPS.

Security is structural here rather than added afterwards: workloads run on a machine allocated to you, and isolation applies to every process and container.

---

Layer 1: Cryptographic URL unguessability

The first layer of security is not a password or a token. Every container ID is 24 hexadecimal characters: 96 bits of entropy, the same keyspace as a strong encryption key.

https://67e89abc123def456789abcd-890abcdef12345678901cdef-terminal-1.node-us.containers.hoody.com
                                └──────────┬──────────┘
                                   24 hex chars = 2^96

The numbers:

• 2^96 is 79,228,162,514,264,337,593,543,950,336 possible container IDs
• At 1 billion guesses per second, enumeration takes 2.5 × 10^12 years
• The universe is 1.38 × 10^10 years old, so a full scan would run for about 180 times its age

Container URLs cannot be scanned, enumerated, or guessed. There is no directory listing and no discovery endpoint; if you do not know the URL, you cannot reach the resource.

This is what makes “open by default” workable: the URL is the secret. Sharing the URL grants access, and withholding it denies access. The security model starts at the URL, before any authentication layer runs.

Note

Wildcard TLS certificates (*.{serverName}.containers.hoody.com) mean your specific container URLs never appear in Certificate Transparency logs. No one can discover your container addresses by scanning public certificate databases.

---

Layer 2: Container isolation

Each container’s boundary is enforced by the kernel, not by convention or configuration.

Filesystem isolation

Each container has its own root filesystem, with no shared volumes by default. Container A cannot read container B’s /etc/passwd, cannot write to container B’s /home, and cannot even know container B exists on the same server.

Network isolation

Each container has its own network namespace and routing table. Each gets its own Linux bridge on a dedicated /30 subnet, so containers never share a bridge and there is no shared internal segment to eavesdrop on. A container has a private IPv4 there, masqueraded behind the host’s public address; it does not have a dedicated public IPv4. Containers reach each other the same way any two machines on the internet do.

Process isolation

PID namespaces mean each container sees only its own processes. A compromised container cannot enumerate, signal, or attach to processes in any other container.

Enforcement mechanisms

Technology	What it does
Linux namespaces	Isolate PIDs, network, mounts, users, IPC
seccomp	Syscall filtering with additional targeted restrictions, layered on the container runtime’s default profile
Hardened kernel	A custom hardened Hoody kernel, patched and locked down to reduce attack surface
Hardened LXC	Container runtime on the Hoody kernel, with optional dedicated VM instances for full kernel isolation
No shared kernel memory	Containers cannot read each other’s RAM

A compromised container does not spread to your other containers: delete it, restore a clean snapshot, and move on. No isolation boundary is absolute (kernel and runtime vulnerabilities exist), but the unit of compromise stays small.

---

Layer 3: Bare metal ownership

Most cloud platforms run your workloads on shared hardware: your containers share a hypervisor with strangers’ containers, and your memory shares physical DIMMs with unknown processes. Spectre, Meltdown, and their variants demonstrated that CPU-level side-channel attacks can leak data across hypervisor boundaries.

On a rented or owned Hoody server, containers run on a physical machine allocated to you alone. There is no shared hypervisor and no other customer’s workload on the hardware.

The security implications of a dedicated machine:

• No cross-tenant side channels. Nobody else’s workload shares your CPU cache or memory bus, which removes the entire class of attacks that depends on a neighbouring tenant.
• No hypervisor escape risk. There is no shared hypervisor to escape from; your containers run on bare Linux. (If you opt in to running your own VMs, that hypervisor is yours, on your own machine, not a boundary shared with other tenants.)
• Physical control. You control the server and its network configuration, and nobody else rents the host.
• Performance predictability. All CPU cycles, memory, and disk IOPS are yours, so strangers’ workloads cannot slow yours down.

The free tier is not this

Every guarantee above describes a machine that is yours. A free server is not a machine; it is a slice of one. Free-tier servers are capped slices carved out of a shared physical host that also carries other people’s slices. Everything in Layers 1, 2, and 4 through 8 still applies to your containers. This layer does not.

	Free slice (shared host)	Rented or owned machine
Hardware	Shared with other tenants	Yours alone
Kernel	One kernel, shared with strangers	One kernel, shared only with yourself
CPU cache / memory bus	Shared; the Spectre/Meltdown class of cross-tenant side channel is not ruled out	Not shared with anyone
Disk blocks	Deduplicated host-wide, so identical blocks may be physically shared across tenants	Deduplicated only among your own containers
Noisy neighbors	Possible	None

Before you put secrets on a free server

The free tier exists so you can try the whole platform for real, not as a cheaper version of the dedicated product. Because the hardware and the kernel are shared with people you cannot audit, treat a free slice as untrusted for anything you would not run next to a stranger’s workload: production secrets, customer data, private keys, regulated data.

Hoody does not enable KSM (Kernel Samepage Merging) on any host, free or dedicated, because merging memory pages between tenants is a known side-channel primitive. That closes one side channel, not the whole class: a shared kernel and a shared CPU are still a shared trust boundary.

For the same reason, a free slice blocks the kernel interface used for low-level performance profiling. Profilers built on the kernel’s hardware performance counters, such as perf, cannot collect measurements inside a free-tier container, because on a shared kernel those counters can expose timing and address information across tenants. On a rented or owned machine the kernel is yours, so Hoody adds no such restriction and these profilers run under the machine’s normal Linux permissions.

If any of that matters to you, rent a machine. It is the single upgrade that turns this layer back on.

The cost of renting a machine

A dedicated Hoody server is a flat monthly cost with no usage meter and no per-container billing. One machine holds hundreds of containers, so development, staging, and production can all live on it. The same machine can host anything else you want to self-host, on hardware nobody else touches.

CLI

# List your servers: physical machines rented to you alone
hoody servers list

# Each server runs its own proxy and its own containers,
# with no infrastructure shared with other customers

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.com', token: process.env.HOODY_TOKEN });

// List the servers you rent
const servers = await client.api.serverRental.list();

// Each rental lists your hardware (server name, region, specs), your containers, your proxy
// No hypervisor or kernel is shared with another tenant

HTTP

# Your servers
curl "https://api.hoody.com/api/v1/servers" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# Each rental in the response includes:
# - server.name (your proxy node, e.g. node-us-nyc-1)
# - server.region / server.specs (CPU, RAM, disks, network)
# - rental_start / rental_end / status

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Lists the physical servers rented to you, including region, hardware specs, and rental status.

Copy

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/servers&method=GET&bearer_token=TOKEN&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

---

Layer 4: Permission system

When URL unguessability is not enough and you need explicit authentication, the proxy provides a multi-layered permission system.

Authentication methods

Method	Mechanism	Use case
Password	HTTP Basic Auth	Quick protection for internal tools, demos
JWT	Token with claims validation	API consumers, AI agents, service-to-service
IP whitelist	Allow by IP address or CIDR range	Office networks, known servers, CI/CD runners
Bearer token	Custom token in Authorization header	Machine-to-machine, webhook endpoints

Two levels of scope

Project-level permissions apply to every container in the project:

Project "production" → deny all by default
  └─ Group "devops": IP 203.0.113.0/24 → allow terminal, files, display
  └─ Group "monitoring": Bearer token → allow http (read-only)

Container-level permissions override project settings for specific containers:

Container "public-api" → override project permissions
  └─ Group "world": IP 0.0.0.0/0 → allow http only
  └─ Group "operators": JWT → allow everything

Service-level granularity

Permissions are not all-or-nothing. Each authentication group gets fine-grained access per service:

CLI

# Build permissions with the granular commands (each PATCHes one field).
# Read the current file_version first, then pass it as --if-match file:vN
# (a write is rejected 428 without it, 412 if stale). Re-read after each
# write, since every mutation bumps the version.
V=$(hoody containers proxy permissions get -c $CONTAINER_ID -o json | jq -r '.file_version')

# Create the 'office' IP auth group (only this public range may reach the proxy).
# Use the public egress CIDR your clients actually come from; a private range
# like 10.0.0.0/8 can never match an internet visitor's source address.
hoody containers proxy groups ip set -c $CONTAINER_ID \
  --group-name office --range 203.0.113.0/24 --if-match "file:v$V"

# Grant that group per-service access (re-read file_version between writes)
V=$(hoody containers proxy permissions get -c $CONTAINER_ID -o json | jq -r '.file_version')
hoody containers proxy groups permissions set -c $CONTAINER_ID \
  --group-name office --program terminal --access true --if-match "file:v$V"

V=$(hoody containers proxy permissions get -c $CONTAINER_ID -o json | jq -r '.file_version')
hoody containers proxy groups permissions set -c $CONTAINER_ID \
  --group-name office --program files --access true --if-match "file:v$V"

# Everything else stays denied
V=$(hoody containers proxy permissions get -c $CONTAINER_ID -o json | jq -r '.file_version')
hoody containers proxy default --default deny -c $CONTAINER_ID --if-match "file:v$V"

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.com', token: process.env.HOODY_TOKEN });

// Granular permissions per service
// Read the current `file:v<N>` ETag from proxyPermissionsContainer.get() first
await client.api.proxyPermissionsContainer.replace(containerId, {
  project: PROJECT_ID,
  container: containerId,
  groups: {
    humans: { type: 'password', username: 'ops', password: 'secure-pass', salt: 'unique-salt' },
    agents: { type: 'token', header: 'X-Agent-Token', value: 'agent-secret-token' }
  },
  permissions: {
    humans: { terminal: true, files: true, display: false, sqlite: false },
    agents: { terminal: true, files: true, exec: true, sqlite: true, browser: true }
  },
  default: 'deny'
}, { ifMatch });

HTTP

# Production lockdown: only HTTP traffic from known IPs
# If-Match comes from GET .../proxy/permissions (file_version): 428 if absent, 412 if stale
curl -X PUT "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/proxy/permissions" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -H "If-Match: file:v2" \
  -d '{
    "project": "'"$PROJECT_ID"'",
    "container": "'"$CONTAINER_ID"'",
    "groups": {
      "office_egress": {
        "type": "ip",
        "range": "203.0.113.0/24"
      },
      "operators": {
        "type": "jwt",
        "secret": "your-jwt-secret",
        "algorithm": "HS256",
        "sources": ["header:Authorization"]
      }
    },
    "permissions": {
      "office_egress": {
        "http": [8080]
      },
      "operators": {
        "terminal": true,
        "files": true,
        "display": true,
        "sqlite": true,
        "exec": true
      }
    },
    "default": "deny"
  }'

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Replaces the container’s whole permissions document with a production lockdown: HTTP open only to the office CIDR, everything else gated behind a JWT-authenticated operators group. Fetch the current document first and put its ETag in place of file:v2, or the write is rejected.

Copy

https://PROJECT_ID-CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/proxy/permissions&method=PUT&bearer_token=TOKEN&header=If-Match:%20file:v2&json={"project":"PROJECT_ID","container":"CONTAINER_ID","groups":{"office_egress":{"type":"ip","range":"203.0.113.0/24"},"operators":{"type":"jwt","secret":"your-jwt-secret","algorithm":"HS256","sources":["header:Authorization"]}},"permissions":{"office_egress":{"http":[8080]},"operators":{"terminal":true,"files":true,"display":true,"sqlite":true,"exec":true}},"default":"deny"}&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

---

Layer 5: Container firewalls

Beyond the proxy permission layer, each container has host-level firewall rules that control network traffic at the packet level.

The rules are configured on the host, not inside the container, so a compromised container cannot modify its own firewall. This is iptables on the bare metal, scoped to the container’s network namespace, not iptables inside a container.

Rule type	What it controls
Ingress	Which IPs/ports can reach the container
Egress	Which IPs/ports the container can reach
Protocol	TCP, UDP, ICMP filtering
Default stance	Default-allow: your rules drop what you name, everything else passes. Add explicit rules to restrict

You can also install iptables, nftables, or ufw inside the container for defense in depth: two independent layers of network control.

---

Layer 6: Controlled network exit

By default a container has no dedicated public IPv4: its outbound traffic is masqueraded behind the host’s address, and egress to public IPv4 is permitted. Private and special-use ranges, common SMTP ports (25, 26, 366, and 2525), and tunnelling protocols 4, 41, 47, and 132 are blocked at the host. Configure a network exit when you need every outbound connection to take a specific path.

When a container needs internet access, you configure the exit path at the host level, where the container cannot tamper with it:

• 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)

Once an exit is configured, direct egress to the internet is removed and the container cannot get around it: the exit path is enforced on the host, outside the container’s reach, so a compromised container cannot add its own route or fall back to a direct connection. Platform services (DNS, the package mirror, the AI gateway) stay reachable on their own paths. Until you configure an exit, treat container egress as open.

---

Layer 7: Disk encryption

Every Hoody machine runs LUKS full-disk encryption on its bare metal. There is nothing to enable and no way to opt out: the platform provisions encryption when the server is installed, and the orchestrator manages it from there, on free-tier hosts and rented machines alike.

The property that matters is where the key lives: not on the machine it unlocks. The orchestrator holds the key and supplies it out of band at boot, so a reboot comes back up unattended while a drive that leaves the rack does not. A stolen disk or a seized chassis holds ciphertext, and the key that decrypts it stayed behind. That makes theft and physical seizure a hardware loss rather than a data breach.

What it does not do is protect a running host. Once the volume is unlocked, the filesystem is plaintext to anything with host-level access, which includes the platform services that serve your containers, and includes Hoody’s own administration of the machine. Layer 7 answers the powered-off threat, not the live one. For data that must stay opaque even while the server runs, encrypt above the disk: a crypt-wrapped storage backend or application-level encryption, where the key is yours and never reaches the host in the clear.

---

Layer 8: Realms

Realms provide API-level isolation. Each realm sees only its own containers:

https://507f1f77bcf86cd7994390aa.api.hoody.com  →  sees only Realm A's containers
https://507f1f77bcf86cd7994390bb.api.hoody.com  →  sees only Realm B's containers

Auth tokens scope to specific realms, and AI agents in one realm cannot discover, enumerate, or access containers in another realm. This is multi-tenant isolation at the API level rather than network segmentation.

---

Aliases and public exposure

Proxy aliases put a clean, brandable domain in front of a cryptographic URL. They are also the point where your security model changes.

The cryptographic URL is the secret (Layer 1): the container ID inside it carries 96 bits of entropy and is never meant to be shared verbatim. An alias hides that ID behind a memorable name, which is its job. Hiding the ID is not the same as hiding the surface behind it.

Two failure modes follow you across the alias:

1. Metadata leakage. Some programs embed the underlying container ID, internal paths, hostnames, or environment details into HTML, response headers, error pages, or websocket handshakes. The alias hides nothing if the response body says container_id: 890abcdef….
2. Surface exposure. The alias still routes to a specific program. Some programs are user-written code, whose security is your responsibility. Others are privileged control planes where the surface itself is the dangerous action: terminal is a shell, files is a filesystem, sqlite is a database, agent orchestrates everything else.

Programs safe to publish

These programs expose HTTP-shaped surfaces that you control. Aliasing them for public sharing, business cards, embedded docs, or customer-facing URLs is the intended use case:

Program	Why it is safe to publish
http	Your web server / API. The auth and authorization are your application logic: you decide what is exposed.
exec (hoody-exec)	Scripts you wrote with explicit handlers and routes. Behaves like any HTTP framework.
pipe (hoody-pipe)	A streaming HTTP relay (POST/PUT to send, GET to receive; each path is one-directional, no on-disk state) with permission gating at the proxy. The wire protocol is the only surface.
tunnel (hoody-tunnel)	HTTP and TCP forwarding of a local service through the proxy. Auth runs at the proxy boundary.

These four are the public diffusion set: they expose plain transport, nothing more, and rely on you to decide what the application returns. Combine them with proxy permissions and you have a clean URL backed by real authentication.

Programs for internal use only

Every other Hoody Kit program is an operator surface. Aliasing them is fine for internal use behind IP whitelists or strong auth, but never publish those aliases the way you would publish an API URL:

Program	Why publishing the alias is dangerous
terminal	The alias becomes a published shell endpoint. One credential away from arbitrary command execution.
files	Filesystem browser. Listings, downloads, and uploads against the container’s root. Path leakage is the default behavior.
sqlite	Live database UI and SQL API. Schema, secrets, and writes, all over HTTP.
display	Remote desktop with keyboard, mouse, and screenshots. Hijacking it hijacks the running session.
code	Full editor with filesystem access. Extensions can execute code. Reads keys and configs.
browser	Headless Chrome with JavaScript evaluation. Cookies, automation, and credential interception live here.
agent	The AI agent orchestrates every other service in the container. Compromising the alias compromises everything below it.
cron, daemons	Scheduled jobs and process control. Inject a job, gain persistent execution.
curl	HTTP request wrapper. Aliased and exposed, it becomes an open SSRF gateway with your IP and your secrets.
ssh	SSH over the proxy. Same risk class as terminal.

For these, prefer the cryptographic URL: the 2^96 keyspace is your authentication of last resort, and rotating the URL only requires deleting the program and re-creating it.

Caution

An alias does not replace permissions. If you must alias a privileged program (e.g. an internal operations terminal at ops-shell.node-us.containers.hoody.com), treat the alias name as public information and configure proxy permissions accordingly: IP whitelist, JWT or password, default-deny. Set expires_at so forgotten aliases do not outlive their need.

Guardrails for a published alias

For the safe set (http, exec, pipe, tunnel), publishing the alias is the goal. A few guardrails make it more durable:

• Use unique, non-generic names. acme-billing-api is not enumerable; api, app, prod are. Generic names also collide globally per server.
• Restrict to an explicit base path. target_path: "/api/v1" with allow_path_override: false exposes only your public routes, even if other handlers exist in the same container.
• Apply permissions to the underlying container. Permissions follow the container, not the URL: both the alias and the cryptographic URL inherit them. There is no way to lock down only the alias.
• Watch Certificate Transparency for custom domains. Default container subdomains are covered by a wildcard cert and never appear in CT logs. The moment you CNAME api.mycompany.com to your alias, that hostname does show up in public CT logs. This is fine for intentional production exposure; just know that custom-domain hostnames are publicly enumerable in a way that *.{serverName}.containers.hoody.com URLs are not.
• Delete aliases before deleting containers. Orphaned aliases keep responding (with errors), and stale alias names are an attractive target if reassigned later.

Which address to publish

The container ID is a secret; the alias is a label. Publish the label only for programs whose surface you would also publish. For everything else, the cryptographic URL is the right address.

---

Security for AI-generated code

AI generates code you cannot fully review. When a human writes code, you can read it. When an LLM generates 10,000 lines in response to a prompt, you cannot meaningfully review every line, every import, or every network call.

That is a consequence of scale, not a failure of discipline. AI-generated code will have bugs and vulnerabilities, and it will make network calls you did not anticipate.

Hoody’s security model is designed for this:

• Containment. Container isolation keeps a rogue AI-generated process inside its container: it cannot read other containers’ filesystems or signal their processes. Reaching the host takes a kernel or runtime vulnerability, the same caveat every isolation boundary carries.

• Snapshots. Snapshot before an AI makes changes. If it breaks something, restoring takes seconds instead of hours of debugging or a git bisect.

• Network control. You decide where AI-written code can reach. Configure an exit path and host-level firewall rules, and a container running AI-generated code hits a boundary it cannot modify. Configure nothing and its egress is open, so set the exit before you run code you have not read.

• HTTP observability. Every HTTP call into your container’s services passes the edge proxy: log it, inspect it, rate-limit it, or intercept it with hoody-exec hooks. What those logs contain and how long they are kept is covered in Auditing & Data Collection. Outbound calls your code makes are not proxied by the edge; configure a network exit to control their path, and add logging at that exit if you need outbound observability.

Caution

Security is never absolute. Container isolation mitigates lateral movement but does not prevent application-level vulnerabilities within a container. Supply chain attacks (compromised npm packages, malicious Docker images) remain an industry-wide challenge. Hoody provides containment and rapid recovery, not prevention of all possible attacks.

---

The layer stack

From bottom to top, each layer narrows the attack surface:

┌─────────────────────────┐
│   Application Security  │  Your responsibility (input validation, auth logic)
├─────────────────────────┤
│   Proxy Permissions     │  JWT, password, IP, token per service
├─────────────────────────┤
│   Container Firewall    │  Host-level ingress/egress rules
├─────────────────────────┤
│   Network Control       │  No dedicated public IPv4, optional controlled exit
├─────────────────────────┤
│   Container Isolation   │  Namespaces, seccomp, hardened kernel
├─────────────────────────┤
│   Bare Metal Ownership  │  Your hardware, no shared hypervisor (dedicated servers only)
├─────────────────────────┤
│   Disk Encryption       │  LUKS on every host, keys held off the machine
├─────────────────────────┤
│   Realm Isolation       │  API-level multi-tenancy
├─────────────────────────┤
│   URL Unguessability    │  2^96 keyspace, no enumeration
└─────────────────────────┘

The layers fail separately (compromising one does not hand an attacker the rest), though they are not fully independent: containers on a host share a kernel. URL unguessability provides passive security even with no permissions configured. Container isolation contains breaches even if the application is compromised. On a dedicated machine, bare metal ownership eliminates entire classes of attacks even if a container is fully taken over. On a free slice that layer is absent, and the stack is one layer shorter.

---

Practical security postures

Development

Permissions: None configured
URL security: Cryptographic (2^96)
Firewall: Default allow
Network: Direct NAT by default

Who can access: Only people who have the URL

This posture suits development, experimentation, and internal tools. The URL is the password.

Staging

Permissions: IP whitelist for office/VPN
URL security: Cryptographic + IP check
Firewall: Allow from known IPs
Network: Proxied exit

This adds a second factor: even with the URL, you must be on the right network.

Production

Permissions: JWT for API, password for operators, IP for infra
URL security: Cryptographic + auth required
Firewall: Default deny, explicit allow
Network: No dedicated public IPv4, controlled exit
Snapshots: Hourly automated

Every layer described above is active, and snapshots run hourly.

CLI

# The CLI proxy state command can only enable the proxy (--enable-proxy sends enable_proxy:true).
# To disable the proxy use the SDK or HTTP tab; there is no --no-enable-proxy flag.

# Re-enable when investigation is complete
hoody containers proxy state --container $CONTAINER_ID --if-match file:v<N> --enable-proxy

SDK

import { HoodyClient } from 'hoody-sdk';

const client = new HoodyClient({ baseURL: 'https://api.hoody.com', token: process.env.HOODY_TOKEN });

// Disable proxy: kill switch; new requests then return 403, and no rule can re-open it
// Set it at container level: a container's own `true` overrides a disabled project
// Pass the current `file:v<N>` ETag from a prior GET (required: 428 if absent, 412 if stale)
let { data } = await client.api.proxyPermissionsContainer.get(containerId);
let ifMatch = data.etag ?? `file:v${data.file_version}`;
await client.api.proxyPermissionsContainer.updateState(containerId, { enable_proxy: false }, { ifMatch });
// Container keeps running; only proxy reachability is cut

// Re-enable when investigation is complete; every write bumps file_version, so re-read it
({ data } = await client.api.proxyPermissionsContainer.get(containerId));
ifMatch = data.etag ?? `file:v${data.file_version}`;
await client.api.proxyPermissionsContainer.updateState(containerId, { enable_proxy: true }, { ifMatch });

HTTP

# Disable proxy (kill switch; new requests then return 403)
curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/proxy/permissions/state" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -H "If-Match: file:v<N>" \
  -d '{"enable_proxy": false}'

# The container stays alive, but the proxy now answers 403 instead of forwarding
# Re-enable when investigation is complete
curl -X PATCH "https://api.hoody.com/api/v1/containers/$CONTAINER_ID/proxy/permissions/state" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  -H "If-Match: file:v<N>" \
  -d '{"enable_proxy": true}'

URL

?

One request, one link

cURL runs inside your container and can wrap any HTTP request into a single GET URL. The call stops being something you need a client for and becomes something you can paste into a browser, send in a chat, bookmark, schedule with cron, or drop into a no-code tool.

Nothing is installed on the machine that opens it. The link does carry whatever credentials the call needs, so treat it as you would treat those credentials.

Slashes, colons and braces pass through as they are. The one character you must encode is an & inside a value, which happens when the wrapped URL carries its own query string. Left raw it ends the value early, and the rest is read as cURL's own parameters, so you get a 200 on a request you did not make.

How the wrapping works Chaining calls into one link Turning a link into a shortcut

Disables the proxy for this container, so its service URLs answer 403 instead of forwarding, then re-enables it. Route both links through a different running container’s curl-1 — disabling CONTAINER_ID’s proxy also 403s its own curl service, which would sever the link that undoes it. Replace file:v<N> in each link with the ETag from a prior GET of the permissions document, or the write is rejected.

Copy

# Disable
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/proxy/permissions/state&method=PATCH&bearer_token=TOKEN&header=If-Match:%20file:v<N>&json={"enable_proxy":false}&response=transparent

# Re-enable
https://PROJECT_ID-OTHER_CONTAINER_ID-curl-1.SERVER.containers.hoody.com/api/v1/curl/request?url=https://api.hoody.com/api/v1/containers/CONTAINER_ID/proxy/permissions/state&method=PATCH&bearer_token=TOKEN&header=If-Match:%20file:v<N>&json={"enable_proxy":true}&response=transparent

The link carries a credential and executes with it, so it is as sensitive as the credential itself — and it passes through the cURL service's request log on the way, not just the target's. Share it only where you would share the secret, and prefer a delegated token with minimal permissions and an expiry: see API tokens.

---

The defaults are open because they are already cryptographically secure. Every additional layer is there when you need it.

---

Next: Snapshots, point-in-time restore as a security tool.