One proxy, atomically reconfigured

Every app and service sits behind a single Sproobo-owned Caddy container. Route changes are validated before they're live, certificates renew themselves, and nothing about getting a domain working requires you to touch the box directly.

The shared proxy

A server gets one ingress container that owns :80 and :443. Route changes go through Caddy's admin API as an atomic config load, and caddy validate gates every change. A bad route can't leave the box half-broken. The last-known-good config is retained, so a failed reload falls back to what was already working rather than an empty proxy.

Caddy reaches your app or service by its container DNS name over the internal network, not a host port. See the internal network below.

Apex + www together by default

Give an app example.com and Sproobo configures both example.com and www.example.com together. This isn't a checkbox: a validator rejects any route where an apex domain lacks its www counterpart or vice versa. Both names populate the Caddy site address and the certificate's SAN set, and a canonical 301 redirects the non-preferred host to the one you picked. Both stay served and certificate-covered so the redirect itself never breaks. Subdomains, wildcard children, and apps deliberately served without www instead declare a single explicit host.

Four ways to get a certificate

TLS mode is a per-app setting (dashboard Settings tab, or buildSpec.tlsMode under the hood). Pick the one that matches how the server is reachable:

HTTP upgrades to HTTPS, automatically

Outside of the external-termination case above, every host gets Caddy's automatic HTTPS behavior platform-wide: plain HTTP requests get a redirect to HTTPS by default, with no per-app opt-in required. Switching an app to external mode is the one deliberate way to turn that off for a given host, since in that mode Sproobo isn't the one terminating TLS in the first place.

Alias domains: old names that redirect

Beyond the domains it serves, an app can carry alias domains: extra hostnames that don't serve anything themselves but 301-redirect every request to the app's canonical host, path and query preserved. Old brands, defensive registrations, and alternate TLDs land on the real site instead of a parked page. DNS on its own can't do this, because a redirect is an HTTP response rather than a record, so it has to come from the proxy on your server.

Each alias is its own group, under the same shape rule as the app's own domains: a single host, or an apex together with its www counterpart. Half-pairs stay rejected, and www.oldbrand.com redirects straight to the canonical host with no intermediate hop. Every alias host gets its own automatic HTTP-01 certificate, independent of the app's TLS mode, so an app on delegated DNS-01 or riding a wildcard cert still picks up ordinary certificates for its aliases. Up to ten alias groups per app, and an alias can't take a hostname another app on the same server already claims.

Aliases are not available in external termination mode: your own load balancer owns TLS for those hosts, so Sproobo isn't in a position to issue a certificate for them.

DNS is checked but never blocking. Point an alias's A/AAAA records at the same address as the canonical host; if they don't match yet, the alias still saves and the dashboard shows a warning chip against that row rather than refusing the change. A mis-pointed alias fails only its own certificate, since issuance is per hostname, and retries on its own. Your main domain is never affected.

Add them in the dashboard's Domains & TLS card, or from the CLI with sproobo apps set-domains --alias. Like any domain or TLS change, aliases are staged: the redirect route and the certificates go live on the app's next deploy, so redeploy right after saving.

The internal network: sproobo-int

Every app and service container attaches to one internal Docker network, sproobo-int. The proxy reaches an app's upstream, and an app reaches a bound service, purely by container DNS name on that network, no host ports are published for any of it. The only container published to 0.0.0.0 on the box is the proxy container itself, on :80/:443; everything else is unreachable from outside the box even if the host firewall were wide open.

The firewall that doesn't lie

The host-level firewall is ufw on Debian-family servers and firewalld on RHEL-family, but the part that actually enforces a rule against a Docker-published port is the DOCKER-USER iptables/nftables chain, since Docker's own NAT rules run ahead of the host firewall and would otherwise bypass it silently. Sproobo reconciles declared rules into DOCKER-USER as well, so a deny is actually effective rather than a rule that looks right in ufw status while the port stays reachable underneath.

The dashboard's firewall page reflects this directly: it merges what you've declared against what the agent's latest fact snapshot actually observed on the host, and surfaces any observed rule with no declared counterpart as drift, a rule the box picked up outside Sproobo.

Next

• Read the full trust-boundary and firewall lockout-prevention model on Security model.
• See where TLS mode fits into creating and configuring an app on Apps & deploys.
• Walk the full enroll-to-deploy flow on Getting started.