Product

Charon: why we built a cloud janitor inside a Linux integrity tool

9 May 2026 · ~7 min read · Jamie, Founder, Blackglass

Charon is the cloud-resource hygiene add-on that ships inside the Blackglass console. It scans your DigitalOcean, AWS, and GCP accounts for idle VMs, orphaned volumes, old snapshots, and similar costly junk — and lets you request cleanups through the same approval workflow we use for Linux drift events. People ask, reasonably: why is a cloud waste tool inside a Linux integrity tool?Here’s the thinking.

Both questions live in the same job

The person who runs the Linux fleet is, in 90% of small-to-mid teams, also the person who answers for the cloud bill. They’re the SRE, the platform engineer, the IT director — usually a one- or two-person function in a 30 – 200 person company. Configuration drift and unloved cloud resources are not the same problem, but they sit on the same desk.

Both have the same shape: silent accumulation of state nobody intended. A drift event is a server slowly diverging from the configuration you approved. Cloud waste is a cloud account slowly diverging from the resource list you intended to pay for. Same operator, same calmer-than-the-category alerting model, same evidence-export pattern.

Why we didn’t build it as a separate product

The obvious commercial answer would have been to spin Charon out as its own SKU with its own dashboard. We considered that and rejected it because:

• It’d duplicate work for the operator. Two dashboards, two auth flows, two sets of webhooks. Nobody wants that for a tool they’ll touch twice a week.
• The data flows naturally between them.A host that disappears from your fleet should ideally raise “was the cloud volume attached to it cleaned up?” — that’s a Charon question with a Blackglass trigger. Single product, single data graph.
• It strengthens the upgrade story for Lab. The free tier gets one read-only Charon-linked cloud account. That’s deliberate — the public /tools/cloud-waste-estimator can convert into the real product without an immediate paywall, and Lab users see the dashboard view of their actual cloud resources as proof-of-value.
• The competitive landscape supports it. Standalone cloud-cost tools (Vantage, CloudHealth, ProsperOps) are excellent at allocation and rightsizing — neither of which Charon does. We’re explicitly the janitor: find waste, request cleanup, move on. The bundle is the moat.

What Charon is — and isn’t — careful about

The hardest design constraint was: never delete the wrong thing. Cloud waste tools that auto-delete inevitably nuke a developer’s test environment that they’d forgotten was important, and once is enough to lose all trust. So Charon is built around explicit human approval, with several safety patterns:

• Read-only by default. Initial setup grants inventory-read scope only. Live cleanup requires a separate, distinct credential and an explicit per-account opt-in.
• Tag-based protect lists. Resources tagged protect:true, env:prod, or anything in your custom protect-tag list are excluded at scan time, not at delete time. Suppression is the wrong layer.
• Idle-score thresholds.Findings below your configured score don’t even surface in the dashboard. The default is conservative enough that “Charon shows me a finding” should already feel meaningful.
• Cleanup is request-based, not auto. Even with a cleanup credential linked, Charon proposes; the operator approves. The audit log records both the proposal and the approval, with both timestamps.
• Webhook envelope is versioned. Outbound scan webhooks carry an explicit schema version so consumers can pin to a known payload shape. We versioned this on day one because cloud-cost integrations break in expensive ways.

Why “rough self-reported counts” in the public estimator

The public /tools/cloud-waste-estimator deliberately doesn’t ask for cloud credentials. You enter rough counts (“maybe 20 idle droplets, ~5 TB of orphaned volumes”), pick a per-provider band (low / medium / high cost assumption), and get a monthly waste range. No telemetry, no credentials, no sign-up.

That’s the right shape for the top of the funnel because the prospect we want to reach — the on-call SRE who suspects waste but doesn’t have buy-in to evaluate another tool yet — won’t paste a cloud credential into a marketing landing page from a vendor they don’t know. The estimator gives them a defensible “we’re wasting between $X and $Y per month” number to bring to their boss in 90 seconds. The conversion happens later, after the boss has signed off on a 14-day trial.

This is the same reason /tools/cloud-inventory-diff runs entirely client-side via FileReader — paste two JSON exports, see what changed, nothing leaves the browser. Trust posture matters more than feature parity for a free-tools surface.

What Charon costs — and why

Charon is a $99/month add-on across all paid tiers. Pricing rationale:

• The cleanups Charon surfaces typically save 10× – 100× the add-on cost in the first month. We don’t want pricing to be the reason a customer doesn’t take the win.
• $99 reads as “clearly an add-on, not a platform”. We don’t want customers comparing Charon to Vantage at hundreds of dollars per month — they’re different products solving different problems.
• A flat add-on (rather than a per-cloud-account meter) keeps the pricing page readable and means our incentives line up with the customer’s. We don’t want to benefit when you link a 10th cloud account; you do.

How it sits in the broader product story

Blackglass is fundamentally a tool that watches Linux servers for configuration drift and exports auditor-grade evidence. Charon is the recognition that the same operator has a second, related problem we can solve well in a fraction of the engineering surface — and that bundling them gives both products a stronger reason to exist than either would have alone.

If you want to see Charon in the dashboard, the live demo workspace has a populated Janitor view. Or open the public /tools/cloud-waste-estimator to see the same model on a no-credentials-required pass.