Local Containers
Local Container templates run spaces directly on the server’s machine using Docker, Podman, or Apple Containers — no orchestrator required. When a space is created and started, Knot provisions the template’s volumes and launches the container locally.
The full reference for writing one:
- Container Specification — every field of the job YAML with runtime-support notes
- Volume Specification — volume definitions and path resolution rules
- For a walkthrough of creating your first template, see the quick start
Runtime Selection
When creating a template, you can specify the container runtime:
- Local Container (default): Automatically selects an available runtime based on preference order
- Docker: Explicitly uses Docker
- Podman: Explicitly uses Podman
- Apple Container: Explicitly uses Apple Container (macOS only)
Automatic Runtime Selection
When set to Local Container, Knot will attempt to use container runtimes in the following default order:
- Docker
- Podman
- Apple Container
This order follows the server’s server.enabled_backends list (--enabled-backends), which probes container backends in the order listed:
[server]
enabled_backends = ["podman", "apple", "manual"]The above example prefers Podman, then Apple Container, and disables Docker for templates. Because the list is also a platform allowlist, include every backend templates may use — see Available Platforms.
Runtime Notes
Docker and Podman support all spec fields. Podman requires fully qualified image names (e.g., registry-1.docker.io/image:tag).
Apple Container does not support privileged, cap_add, cap_drop, devices, or add_host, has no registry authentication (auth), and prefixes image names without a domain with registry-1.docker.io.