Runtime & security

Security defaults

The enclave applies hardened defaults to every container, so the attested config honestly reflects what runs. These differ from stock Docker, so a container that relied on Docker’s permissive defaults may need adjustment.

Behavior	Default	How to change it
All capabilities dropped	Containers start with zero Linux capabilities.	Add what you need with `cap_add`; only `IPC_LOCK`, `NET_BIND_SERVICE`, and `SYS_NICE` are allowed. There is no `cap_drop`.
No new privileges	`no-new-privileges:true` is always set, blocking setuid-based privilege escalation.	Cannot be disabled or configured with `security_opt`; that field is rejected.
No host namespaces or devices	Containers get their own IPC and PID namespaces.	`ipc` accepts `private` or `none` only; `pid`, `devices`, and `privileged` are rejected. GPUs are exposed through `runtime: nvidia` and `gpus`.
Read-only root filesystem	`read_only: true`.	Set `read_only: false`, or mount writable scratch space with `tmpfs` / `volumes`.
Process limit	`pids_limit: 65536`, a backstop against fork bombs.	Set an explicit `pids_limit` (`-1` for unlimited).
Attested config mount	`/tinfoil` is mounted read-only, exposing the verified config and attestation so clients can audit what’s running.	Not configurable.

If your app needs writable scratch space, add a tmpfs mount or set read_only: false. List required capabilities (for example IPC_LOCK for pinned memory or NET_BIND_SERVICE to listen below port 1024) under cap_add.A container with cvm_admin: true is exempt from these defaults: it runs privileged, as root, with a writable root filesystem. See Direct admin SSH.

The read-only /tinfoil mount contains:

Path	Contents
`/tinfoil/config.yml`	The verified `tinfoil-config.yml` this enclave booted with
`/tinfoil/attestation.json`	The enclave’s attestation document
`/tinfoil/attestation.sock`	Unix socket for fresh attestation requests, when `attestation: true`
`/tinfoil/container-status.json`	Runtime status of the launched containers
`/tinfoil/mpk/mpk-<root_hash>`	Model weights shared with every container, when no container lists them in `models`
`/tinfoil/models/<name>`	Model weights listed in this container’s `models`

Healthchecks

Add a healthcheck so the enclave checks that your app is ready before marking the deployment Running. Without one in the config, the container is considered ready as soon as Docker starts the process (a HEALTHCHECK in the Dockerfile is not enough). That can be too early for apps that load model weights or warm caches before serving requests.

containers:
  - name: "inference"
    image: "vllm/vllm-openai:v0.14.1@sha256:..."
    command: ["--port", "8001"]
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:8001/health"]
      interval: 30s
      timeout: 5s
      start_period: 30m

Field	Type	Description
`test`	list	Command to run inside the container. Prefix with `CMD` to exec directly, or `CMD-SHELL` to run through a shell. Exit code 0 = pass, non-zero = fail.
`interval`	duration	How often to run the check (e.g. `30s`). Docker default: 30s.
`timeout`	duration	How long a single check can take before it’s counted as a failure (e.g. `5s`). Docker default: 30s.
`retries`	integer	Consecutive failures after `start_period` before the container is marked unhealthy. Docker default: 3.
`start_period`	duration	Grace period after container start during which failures don’t count toward `retries` (e.g. `30m`). Docker default: 0s.

How it’s used during boot. The enclave’s boot process polls Docker’s health state every 5 seconds once the container starts and waits until Docker reports the container Healthy before finishing boot. If Docker reports Unhealthy (i.e. retries consecutive failures after start_period has elapsed), the deployment fails and the last healthcheck output is surfaced as the error detail. The test command runs inside the container, so whatever you invoke (curl, wget, a language runtime) has to be available in the image. For an inference server like vLLM that already exposes /health, a curl -sf http://localhost:<port>/health check is idiomatic.

If your container takes 15 minutes to load model weights, set start_period to at least 20 minutes. Otherwise, healthcheck failures during startup can exhaust retries and fail the deployment before the app is ready.

See also. The fields above follow Docker Compose semantics; the Compose healthcheck reference covers exit codes and CMD-SHELL vs CMD. Only the five fields above are accepted. disable: true is rejected, and test: ["NONE"] must not be used: it turns off health reporting, so boot waits forever.

Restart policy

By default, Docker does not restart a container when its process exits. For long-running servers, set restart so Docker restarts the process after a crash.

containers:
  - name: "inference"
    image: "vllm/vllm-openai:v0.14.1@sha256:..."
    restart: always

Value	Behavior
`no`	Don’t restart. This is the default when `restart` is omitted.
`always`	Restart the container regardless of exit status.
`on-failure`	Restart only if the process exits with a non-zero status.
`unless-stopped`	Like `always`, but don’t restart if the container was stopped explicitly.

Interaction with healthchecks. The restart policy fires when the container process exits. It has no effect when Docker marks the container Unhealthy (the process keeps running; only its health state changes). During boot, the enclave fails the deployment on Unhealthy regardless of restart. Once the container has been declared Healthy, restart governs what happens if the process later dies. See also. This field follows Docker Compose semantics, documented in the Compose restart reference.

Getting Started

Model catalog

Tinfoil SDKs

Tinfoil Chat

Local Proxy

Tinfoil Containers

Guides

Verification & Attestation

Tutorials

Admin API

Resources

Security defaults

Healthchecks

Restart policy

​Security defaults

​Healthchecks

​Restart policy

Security defaults

Healthchecks

Restart policy