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.

Static and elastic

Everything on this page describes a static runtime: a Docker host somebody built and keeps, which costs the same whether it runs twenty instances or none. That is what a runtime has always been, and what all of them are unless somebody says otherwise.

An elastic runtime is the other kind. Instead of a daemon you point it at, it holds a cloud account, and Fadebox creates one virtual machine per instance — deploying makes the machine, stopping switches it off and keeps its disk, deleting destroys it. Cost follows the instance down to the price of a stopped disk, and each instance gets a host nobody else is on.

Which kind a runtime is, is fixed when it is created. An elastic runtime has no Docker host and no ingress settings of its own; almost everything else on this page — who may deploy where, the instance cap, the daemon's log store — reads the same for both. See Elastic runtimes, which also says how much of it is built.

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

An elastic runtime shows no bars at all. The reading comes from a runtime's own daemon and an elastic runtime has none — its hosts come and go with the instances on them, and there is no honest single figure for CPU, memory or disk across a fleet that is elastic by construction. What such a runtime reports at its own level is how many of its machines answered the last reading, and how many were ready and would not, so a partial picture reads as partial rather than as a quiet fleet. The per-container figures are all there, read off each machine; only the disk pass does not visit them, so images and volumes on a machine read as a dash.

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.

What of the disk is reclaimable — the image layers nothing here wants any more — is on the same runtime's Images panel, along with the per-runtime image retention setting that removes them on a timer.

Across the fleet

The dashboard draws the same readings for every runtime you can see: CPU and memory as bands per runtime, stacked, and a bar per daemon of what it is storing — images, volumes, containers. The plot is scaled to the data rather than to capacity, because a fleet normally runs at a fraction of what its hosts could take and an axis topped at capacity draws every reading as a flat line along the bottom; how full the host is sits exactly in the figure above it (2.85 of 24 · 12%), and the capacity line comes into frame once usage is near it. A fourth runtime and beyond fold into one Other band.

The charts are the open page's memory. Fadebox stores no usage history: the card keeps what it has watched since you opened it, one point per sweep, and a reload starts the window over — which is what live honestly means here. For history that outlives a page — dashboards, alert rules, a week-over-week comparison — switch on the Prometheus exporter, which is where a time series belongs.

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, the export and the capture a stop takes 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.