Why the gateway is the product

Most VPS PaaS tools stop at “your container is running.”

That is useful. It is also incomplete. The moment something feels wrong, you are back in SSH, grepping nginx logs, installing a sidecar, or wiring Datadog into an app that never asked for an APM agent. The platform shipped the build. The observability tax arrived separately.

Vercel did not win because git push was clever. They won because every request already crossed their edge. Latency, status codes, and route shape were side effects of routing — not a product integration the customer had to remember.

Boson makes the same bet on infrastructure you own.

On the customer VPS, the gateway owns 80 and 443. App containers do not publish host ports. Traffic enters through Caddy, so every request is already a structured record: route, status, duration, bytes. The agent sits next to that stream, folds it into small per-route buckets, and ships those buckets to the control plane. ClickHouse stores the aggregates. Raw lines stay local for live tailing.

That design has two consequences people underestimate.

First, ingest cost stops scaling with traffic. You are not streaming every request row to the cloud. You are shipping sketches and counters on a fixed cadence. Second, the blast radius of a compromised control plane is a closed WebSocket protocol — deploy, routes, heartbeats — not a root shell on every customer machine. The agent dials out. We never hold SSH.

So when we say “the gateway is the product,” we mean it literally. Deploy gets you onto the box. The gateway is how Boson stays useful after the container starts: request-level truth without asking the application to report on itself.

If your PaaS needs the app to instrument itself before you can see p95 on /checkout, it does not own the request path. It only owns the Dockerfile.