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, 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: with local off and one remote runtime on, every new instance lands on the remote one without anyone naming it — see which runtime an instance gets.

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. The instances already on it stay, say so on their card, and can be moved to another runtime once stopped.
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.
• HTTPS certificate — how the managed ingress stack certifies HTTPS: a Let's Encrypt wildcard, which needs the ACME settings below, or Traefik's own self-signed default certificate for an internal host, which every browser warns about. Only read while HTTPS is on. See TLS.
• 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 Ingress action on the runtimes list — install, update and remove, with live status and whether the running stack still matches the saved settings. See Ingress and instance URLs.

What a runtime is costing

A runtime is a host with finite CPU, memory and disk, and the instance cap is a count rather than a capacity: twenty idle instances and twenty JVMs given four gigabytes each are the same number. The runtimes list therefore shows what each daemon is actually spending — two bars, CPU and memory, used of the host's own capacity, with when it was last looked at on hover.

Fadebox reads this from each daemon on a timer and keeps it in memory; nothing about it is stored, and no page waits on Docker to render. Two consequences worth knowing:

• A dash is not zero. A runtime nobody has looked at yet, and one whose daemon was unreachable at the last look, both read as no figure rather than as an idle host. CPU is an average between two readings, so a container that has only just appeared shows a dash for one interval.
• The figures are as of the last sweep, once a minute by default, and disk once a quarter hour — docker stats run at the same moment will not agree to the digit. Tune or switch off either pass in configuration.

The bars sum the instances on the runtime. Fadebox's own managed ingress stack runs there too and is measured, but is not counted into what your previews are using.

Per container, the same figures appear on an instance's status and on a template test run. fadebox runtime list prints CPU and MEMORY columns beside each runtime, and GET /api/runtimes/{name}/usage returns the whole reading, its container rows narrowed to the projects you can see.

There is no history. These are current readings, not a time series: fadebox shows what a host costs now, and keeps no record to plot.

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 Update or Reinstall. 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.