Runtimes

A runtime is a place containers run: one Docker daemon, reachable over a Unix socket or tcp://. Instances are deployed onto a runtime, and one installation can manage several — a laptop, a shared dev box, a machine per region.

Runtimes are managed by a global admin under Settings → Runtimes.

The local runtime

A runtime named local pointing at unix:///var/run/docker.sock is seeded on first start, so the single-host case works with no configuration. It is shared with every project.

It cannot be deleted — it is what a deploy that names no runtime resolves to — but it counts towards your licensed runtime limit only while it is enabled. Disabling it is therefore how a single-runtime installation makes room for a remote daemon.

Because the app container mounts the Docker socket, anyone who can deploy on the local runtime is effectively root on that host. That is inherent to orchestrating Docker without a broker, and it is why template authoring and runtime management are admin-gated.

Remote daemons

A remote daemon is not itself a paid feature: Free can run one, as long as it is the installation's one runtime — disable the seeded local first, then add it. Keeping local and a remote runtime in service at the same time is where the limit bites, and that needs Team; see Licensing.

A remote runtime is a tcp://host:2376 URI plus mutual-TLS material: a CA certificate, a client certificate and a client key, all PEM. The three are meaningful only together. The client key is write-only — the API accepts it and never returns it.

Use Test connection after saving; it does a real round trip to the daemon and reports what it found rather than only whether the socket opened.

Remote runtimes walks through the whole setup — securing the daemon with TLS, registering it, and putting the ingress on the remote host.

caution

Never expose a Docker daemon on tcp:// without TLS client authentication. An unauthenticated daemon port is a root shell on that host for anyone who can reach it.

Who may deploy where

Setting	Effect
Enabled	A disabled runtime accepts no new deploys.
Shared	Usable by every project. This is the default and what local is seeded with.
Restricted	Usable only by the projects you list — for a host that belongs to one team, or one that must not run other people's images.

Ingress

A runtime carries the ingress settings for the instances that run on it, because that is what routes traffic to the right host:

• Ingress domain — the wildcard domain instance URLs are built under, e.g. envs.example.com. Its wildcard DNS record points at the runtime's Docker host, not at the Fadebox server, because the ingress proxy runs there. Per runtime, so local and eu-prod can have different ones. A runtime with no ingress domain simply has no instance URLs; publishing host ports still works.
• HTTPS — whether URLs are https, and which Traefik entrypoint routers are pinned to.
• Ingress port — the port the ingress proxy binds on the host. Empty means the scheme default (80, or 443 with HTTPS); a non-default port appears in every generated instance URL.
• Public port — for a reverse proxy in front of the ingress: the port URLs advertise when it differs from the one the proxy binds. See custom ports and reverse proxies.
• Require fadebox sign-in — gate every instance URL on the runtime behind a Fadebox session.
• ACME settings — email, DNS provider and credentials for wildcard certificates via DNS-01. The credentials are write-only like the client key.

Fadebox can install and manage the ingress stack (Traefik plus a Docker socket proxy) on each runtime from the UI — install, upgrade and remove, with live status. See Ingress and instance URLs.

Container logs

Everything a container writes to its output stays in the daemon's log store on the runtime host until the container is removed, and Docker's default json-file driver never rotates it. Fadebox reads those logs — the instance tail and export, docker logs on the ingress stack — but does not manage them: a chatty service that runs for weeks fills the disk with its own history.

Cap it on the daemon rather than per container, so the ingress stack, every instance and every template test run get the same ceiling. In /etc/docker/daemon.json on each runtime host:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "5" }
}

That is five files of ten megabytes, about 50 MB per container, oldest lines dropped first. The setting applies to containers created after the daemon restarts (sudo systemctl restart docker): instances at their next deploy, the ingress stack at its next Reinstall / Upgrade. Containers already running keep their unbounded store until then.

The cap is also how far back the tail and the export can reach — they read what the daemon still holds — so size it for the history you want to be able to download, not only for the disk.