Binions terminates TLS at a single edge — the built-in Traefik proxy — and runs everything behind it over plain, loopback-only HTTP. That keeps the encryption story simple: one place provides certificates and speaks HTTPS to the outside world, while the daemons that do the actual work never need certificates of their own. This page explains the model; the exact edge configuration (hostnames, how certificates are supplied and renewed) lives on the Configuration → TLS page.
One TLS boundary. Anything you publish is encrypted at the Traefik edge. Inside the host, traffic stays on
localhostand never crosses the network, so there is nothing to encrypt between daemons.
All web traffic you expose — the HTTP and realtime endpoints your playbooks publish — arrives at the Traefik reverse proxy. Traefik is the only public-facing component, and it is where HTTPS begins and ends:
ws/wss), server-sent events (SSE), gRPC, and gRPC-Web, so a single TLS boundary covers all of them.Binions is single-host by design: the 13 daemons run on one machine and communicate over localhost only — there is no daemon-to-daemon traffic across your network. Because that internal traffic never crosses an untrusted link, encrypting it would add cost and key-management overhead without adding security. The trust boundary is the host itself, protected by its operating-system isolation and firewall; TLS is applied where it matters — at the public edge.
Good to know. This means you provision certificates in exactly one place. There are no per-daemon certificates to issue, rotate, or keep in sync.
The certificate and private-key material used by the edge is stored under /etc/binions, in the TLS secrets subdirectory, and is owned by the Traefik service user. As with every other secret on the platform, it is a file protected by Unix ownership and permissions rather than anything inline in a config file.
# TLS material for the edge lives here, owned by the Traefik service user
ls -l /etc/binions/secrets/Treat it like any private key. Restrict who can read the host and its backups. The daily backup captures the config and secrets, so the backup storage deserves the same protection as the certificate files themselves.
You do not wire up Traefik by hand for each automation. The traefiklinker daemon is responsible for registering and updating routes on the edge: when a playbook publishes an endpoint, traefiklinker programs the corresponding route into Traefik, across HTTP, HTTPS, WebSocket (ws/wss), SSE, gRPC, and gRPC-Web. The result is that adding or changing a published service updates the edge automatically, while the TLS termination behaviour stays consistent for every route.
This page describes the model — one TLS edge, loopback-only internals, certificate material under /etc/binions. The concrete settings — which hostnames the edge answers for, and exactly how certificates are provided and renewed — are part of the edge configuration. See Configuration → TLS for those specifics, and treat the public Traefik edge as you would any internet-facing web service: place it behind your own firewall and keep your certificates current.