For a decade, the deal was simple: ship every log, metric, and trace to a vendor, pay per gigabyte, and get a dashboard in return. That deal worked when most systems were monoliths producing a predictable, modest stream of data.
It doesn't work anymore, and the reason isn't pricing. It's volume.
The workload changed, the pricing model didn't
Kubernetes clusters, ephemeral pods, serverless functions, and agentic AI workflows generate telemetry at a scale monoliths never approached. Every pod restart is a log entry. Every microservice hop is a trace. Every LLM call adds token counts, latency, and outcome data that can't be sampled down without losing the signal entirely. Once you sample an AI request, you no longer know what the model actually did.
Observability vendors responded the way SaaS vendors usually do: not by rearchitecting the platform, but by adding more dashboards, more SKUs, and higher tiers. The bill grows faster than the insight.
What BYOC actually means
Bring Your Own Cloud (BYOC) describes an architecture where the data plane, meaning the actual compute that stores and processes your logs, metrics, and traces, runs inside your own cloud account or VPC, while the vendor manages the control plane: upgrades, configuration, orchestration. Your data doesn't leave your environment; the vendor's software runs on top of infrastructure you own.
Worth noting: some BYOC vendors argue the term gets applied loosely, to private connectivity options or dedicated instances that still route data through a shared, vendor-owned pipeline behind the scenes. That's a fair distinction to watch for, though it's also a claim made by vendors competing on exactly this point, so it's worth verifying against a specific platform's architecture documentation rather than taking any single vendor's framing at face value.
Under this model:
- Zero trust becomes structural, not aspirational. Data never leaves your environment, so a whole category of compliance questions disappears before it's asked.
- Costs track actual usage. You pay for the compute and storage you run, not for an ingestion quota set by someone else's pricing page.
- You own the relationship. When the platform runs inside your infrastructure, you're not a tenant negotiating for your own data back. You're the owner deciding what stays and what gets deleted.
- AI observability lives where the AI does. As inference and agent workloads move into private VPCs for latency and compliance reasons, the monitoring for those workloads needs to move there too.
This isn't a niche trend anymore
The same pattern is playing out across adjacent categories: managed databases deployed inside customer VPCs, AI sandboxes that keep code execution inside the customer's own cloud account, platform-as-a-service tools that deploy CI/CD and GPU workloads directly into AWS, GCP, or bare metal instead of a shared vendor cluster. Observability is simply the latest domain to make the same move, for the same reason: as infrastructure gets more distributed, the tools that watch it need to be distributed too.
What this looks like in practice
You don't need an enterprise BYOC contract to get the benefits. A self-hosted observability stack, Prometheus for metrics, Grafana for dashboards, Loki for logs, running as a Docker Compose stack on infrastructure you control, gives you the same core properties: your telemetry never leaves your environment, your cost scales with your actual usage, and you're not waiting on a vendor's roadmap to support a metric you care about.
The tradeoff historically was operational burden. Someone has to write the compose file, wire up the networks and volumes, manage the reverse proxy, keep the images patched. That's exactly the layer try.direct removes.
You don't have to start with the full metrics-and-logs stack, either. If your team is still relying on a SaaS status page or an external uptime checker, a self-hosted uptime monitor like Uptime Kuma is a reasonable first move: it tells you whether your services are actually up, without sending that data to a third party. It's not a replacement for Prometheus or Grafana, and it won't give you metrics or log correlation, but it's a real, working piece of self-hosted observability you can have running in minutes, before deciding how much further to take the migration.
How the pieces map to what you're replacing
It helps to think in terms of what each self-hosted component replaces, rather than as a generic "monitoring stack":
- Prometheus replaces the metrics-ingestion layer of tools like Datadog or New Relic. It scrapes and stores time-series data (CPU, memory, request rates, custom application metrics) at whatever retention you configure, not whatever retention your pricing tier allows.
- Grafana replaces the dashboard layer. It reads from Prometheus (and from Loki, and from most common databases) and gives you the same kind of visual drill-down, without a per-seat license.
- Loki replaces centralized log aggregation. It's built to index metadata rather than full text, which keeps storage costs down even at high log volume, a meaningful difference once Kubernetes or agentic workloads start generating thousands of log lines a minute.
- Alertmanager (bundled with Prometheus) replaces the alerting and on-call routing layer, feeding into whatever notification channel your team already uses.
None of this requires Kubernetes. A single Docker Compose file describing these four services, with the right volumes and a shared network, is enough for most small and mid-sized teams.
A practical migration path
Moving off a SaaS observability platform doesn't have to happen in one step:
- Start with metrics. Point Prometheus at your existing services alongside your current SaaS tool, running both in parallel for two to four weeks. This gives you a baseline without any risk of losing visibility.
- Move dashboards next. Rebuild your most-used SaaS dashboards in Grafana once the underlying metrics are flowing. This is usually the fastest part; most teams only actively use a handful of dashboards.
- Migrate logs last. Log pipelines tend to have the most downstream dependencies (existing search queries, saved filters, alert rules), so give this stage the most buffer time.
- Cut over alerting once confidence is established. Only redirect on-call alerting to the self-hosted stack after it's been running in parallel long enough to trust it under real incident conditions.
The point of running both in parallel isn't caution for its own sake. It's that observability is the one system you don't want to be debugging blind during a migration.
FAQ
What is BYOC in simple terms? BYOC (Bring Your Own Cloud) means the vendor's software runs inside your own cloud account or VPC instead of theirs. Your data stays in your environment; the vendor manages the software layer on top of it.
Is BYOC the same as self-hosting? Not quite. Self-hosting means you deploy and operate everything yourself. BYOC means a vendor manages the platform, but the compute and data live in your infrastructure. Both keep data under your control; they differ in who carries the operational load.
Why is AI workload observability different from traditional monitoring? AI workloads produce telemetry, like token usage, latency, and output quality, that represents the actual outcome of the system, not a proxy for it. Sampling this data the way you might sample a web server's access logs means losing information you can't recover.
Do I need Kubernetes to benefit from self-hosted observability? No. Docker Compose stacks benefit just as much. The core issue, vendor lock-in on your own telemetry, applies regardless of orchestration layer.
Start with a real first step ➞ deploy Uptime Kuma in one click on try.direct