Finding the cloud waste nobody's looking for
Most cloud waste isn’t a bad decision anyone made on purpose. It’s a disk nobody detached after a server was resized eight months ago, a load balancer pointed at a service that got decommissioned, a snapshot kept “just in case” that nobody’s thought about since. None of it shows up on a bill as a single obvious line — it’s spread thin enough that reading an invoice line by line almost never catches it.
What actually gets scanned
Railyard never marks up compute — every server is billed by the actual cloud provider, at their price. The Costs page uses the same cloud credentials already saved for creating servers, and scans DigitalOcean, Hetzner, Vultr, and AWS accounts directly: each account in turn, AWS region by region, with live progress while it runs. Billed amounts come from each provider’s own billing API where one exists (AWS Cost Explorer, DigitalOcean invoices, Vultr pending charges, credits and refunds included) — Hetzner has no billing API, so its figures come from Hetzner’s own live price list instead.
It doesn’t stop at servers Railyard created: disks, IP addresses, snapshots, machine images, NAT gateways, load balancers and databases — anything in the account, including resources the scan had nothing to do with provisioning.
What it actually finds
Grouped by how easy the fix is — easy fixes, medium, bigger changes, and things worth a second look — with each finding explaining why it’s flagged, what fixing it does to the running app, and how:
- Unattached disks, and disks sitting on servers that have been stopped for a long time
- Unused IP addresses, idle NAT gateways and load balancers with no actual traffic
- Old snapshots and machine images nobody’s used since
- Servers running idle, or running no apps, or running only stopped ones
- A server sized well above what its own 14-day average and peak CPU/memory actually need
- Previous-generation AWS instance types, and where ARM (Graviton) would cost less for the same work
- AWS disks and database storage that could move to
gp3
The part that matters more than the list: most of it is one click
Where a fix is safe to automate, the finding has an actual button — delete disk, release IP, delete snapshot, terminate, convert to gp3, stop, resize — each one asking for confirmation and stating the impact plainly first (“deletes the disk and its data — snapshot it first”). A resize snapshots the server automatically before touching it. The bigger changes, like moving a whole server to ARM, come with the actual steps instead of a one-click button, because that’s not a decision safe to fully automate.
Guardrails, not just a report
Set a monthly budget and notification rules fire at 50%, 80% and 100% of the month-end forecast — plus whenever spending spikes or new waste shows up. Tick Hard cap and Railyard enforces it rather than just alerting: at 100% of budget, every non-production app goes to sleep and new servers stop being creatable until spending is back under the line or the budget’s raised. That’s the difference between a cost dashboard and something that actually prevents the bill from running away over a long weekend nobody’s watching it.
What it’s honest about not knowing
Savings figures use each provider’s public list price for the region — a negotiated enterprise discount isn’t visible to the scan. Per-environment cost breakdowns on the canvas are each service’s share of its server’s price, worked out from memory usage — a real estimate, stated as one, not presented as an exact bill.
Full reference, including the exact AWS IAM policy needed: Costs and savings.