Overview

Internet Exposure is one page that answers one question: “how do I put this workload on the internet?” Point a single wildcard DNS record at one of your nodes, and any Docker container, LXC container, or plain IP:port in your cluster can be given a public HTTPS URL like myapp.apps.example.com in a couple of clicks — the fly.io-style “deploy a proof-of-concept, get a URL, tear it down” workflow, on your own hardware.

Everything is opt-in per workload. Nothing is public until you expose it, and un-exposing removes the route immediately.

One DNS record. One ingress. Any workload.

  • One wildcard record — *.apps.example.com → ingress node. No per-workload DNS ever again.
  • Cluster-level — exposure entries replicate across the cluster and survive the workload moving between nodes.
  • Self-healing routes — a reconciler refreshes the upstream address when a container restarts or its IP changes, and re-publishes the route to the ingress automatically.

Setup (once)

  1. Open Storage & Network → Internet Exposure.
  2. Set your zone — e.g. apps.example.com — and create the matching wildcard DNS record (*.apps.example.com) pointing at your chosen ingress node’s public IP.
  3. Pick the ingress node — the node that terminates public traffic. It needs the WolfRouter HTTP proxy runtime (nginx or WolfProxy); the page warns you if it isn’t running.
  4. Choose the TLS certificate for the zone — the cert picker lists the certificates found on the ingress node (with domain, source and expiry) and fills in the paths for you; a wildcard Let’s Encrypt cert from the Certificates page is the natural fit. Manual paths work too.

Exposing a workload

  1. Pick a Docker or LXC container from the cluster-wide dropdown — or enter a manual IP and port for anything else (a VM, a bare-metal service, an appliance).
  2. Choose the subdomain (myapp → myapp.apps.example.com) and the backend port.
  3. If the backend itself speaks HTTPS, set Backend speaks → HTTPS — the ingress still terminates public TLS and proxies onward over HTTPS.
  4. Expose. The URL is live as soon as the ingress reloads — typically a second or two.

The exposed list shows every public URL, its target workload, and lets you un-expose with one click.

Cross-node workloads

When the workload runs on a different node than the ingress, its container-bridge IP isn’t reachable from the ingress — so WolfStack routes to the hosting node’s address via the container’s published host port. Publish a port (-p / ports mapping) on containers you want to expose cross-node, or use a manual IP; if neither is available, the expose call tells you exactly that instead of creating a route that can’t work.

How it works under the hood

  • Each exposure is an automatically-managed WolfRouter HTTP proxy entry — the same battle-tested nginx/WolfProxy render, reload and TLS pipeline that powers WolfRouter’s L7 proxying. No parallel proxy stack to maintain.
  • WolfRouter config is cluster-replicated, so exposure entries propagate to every node and render on whichever node is the ingress — that’s what makes exposure survive workload moves and node changes.
  • A background reconciler re-resolves each exposed workload’s upstream address every 30 seconds and re-publishes the route when it changes (container restarted with a new IP, moved to another node, …).

Current scope

  • HTTP/HTTPS host-based routing (websites, APIs, dashboards). Raw TCP/UDP services need a port mapping instead.
  • One ingress node per zone (one wildcard record). Ingress HA (VIP / round-robin) is on the roadmap.

Security notes

  • Default private: workloads are only reachable publicly after an explicit expose.
  • Public TLS terminates on the ingress with the certificate you chose; renewals follow the normal Certificates flow.
  • Un-exposing removes the proxy entry and reloads the ingress immediately — including cleaning up the last entry (no orphaned configs).
Esc