Dora NodaOn February 11, 2026, Railway's own anti-fraud system attacked Railway's own customers. A new abuse-detection ruleset, rolled out to the live fleet at 14:33 UTC, matched legitimate workloads as hostile and started sending them SIGTERM signals — including production Postgres and MySQL databases. Roughly 3% of the fleet went dark. The dashboard kept showing the terminated workloads as active.
Engineers noticed abnormal shutdowns at 14:47, reverted at 14:56, and finished automated recovery at 18:31 UTC. Four hours, start to finish, caused not by attackers but by the machinery built to stop them. Railway published the whole thing in a public incident report, which is unusually honest — and unusually useful, because every multi-tenant platform eventually builds the same machine.
This post is the field guide for that moment. Below is the screening ladder a self-hosted platform can copy — seven rungs from invite-only to behavior-based suspension, each with what it stops and what it costs in legitimate-user conversion — plus the one metric that decides whether your abuse system is an asset or your own February 11.
Why every PaaS ends up here: the abuse economics
Free compute is a standing invitation to mine cryptocurrency, and attackers RSVP at scale. Sysdig's PURPLEURCHIN investigation found a single freejacking operation running across 30 GitHub accounts, 2,000 Heroku accounts, and 900 Buddy accounts — thousands of free tiers stitched into one mining network with almost no human effort. Sysdig estimated each free account costs the provider $15 per month on GitHub, $7–10 on Heroku and Buddy. Multiply that by thousands of accounts and the "free tier" becomes a direct subsidy to miners.
The industry response has been a slow retreat from frictionless signup. Heroku killed its free dynos, free Postgres, and free Redis on November 28, 2022, with general manager Bob Wise blaming the "extraordinary amount of effort" spent managing fraud and abuse. Railway removed its free tier in 2023 in favor of a $5 credit, then in June 2025 had to throttle Trial and Hobby deployments after an onrush of signups — while insisting it has no plans to remove the trial tiers. Fly.io states it plainly — staff confirm credit cards are an abuse-prevention mechanism, which is why the platform won't take crypto payments.
So the pressure is real, the precedents are public, and the direction is one-way: every platform that survives adds friction at signup. The question is never whether to verify tenants. It is how much verification each layer buys, what it costs in real users who bounce, and how to avoid the failure mode where the enforcement layer becomes the outage.
The screening ladder: seven rungs, with prices attached
Here is the core deliverable — the ladder, ordered from strictest to loosest, with both columns filled. Start at the top when you are small and have no fraud team. Descend a rung only when abuse pressure, not growth impatience, forces you to.
| Rung | What it stops | What it costs in conversion |
|---|---|---|
| 1. Invite-only / waitlist | Everything automated: miners, spam farms, card testers. Humans don't scale for attackers either | Slowest growth; every signup waits on you. Fine under ~100 tenants |
| 2. Manual approval | Same as above, but async. Catches what automation can't: the "real-looking" throwaway project that mines at 03:00 | Hours of your week; approval latency kills impulse signups |
| 3. Email + domain reputation | Disposable-email miners, bulk-account scripts (block temp-mail domains, require verified addresses, rate-limit per domain) | Near-zero for real users; blocks some legitimate privacy-conscious users on aliased mail |
| 4. Card verification (even $0 auth) | Almost all mining and spam at scale. Stolen-card testing still happens, but each attempt now has a paper trail. Fly.io's explicit policy; Railway's "attach card to verify" | The single biggest conversion cliff: students, hobbyists, and developers without international cards bounce |
| 5. Prepaid credits + hard spend caps | Runaway bills from compromised accounts and "oops" loops; converts unlimited-abuse into bounded-abuse. Railway's prepaid plans and Trial credit model live here | Users must pre-pay before real usage; support load from "why did my app stop" when caps hit |
| 6. Runtime behavior detection | The miners who passed signup: sustained 100% CPU with no ingress traffic, known miner process fingerprints, outbound spam patterns, phishing-kit file signatures | Zero signup friction — but this is the rung that SIGTERMs paying customers when it misfires |
| 7. Suspension with a fast appeal path | Limits blast radius after a wrong call at rung 6: pause, notify with reason, restore in minutes on appeal | Every false positive is a trust withdrawal; slow appeals convert it into churn |
Two rows deserve emphasis because the title promises both. Miners are a compute problem: they show up as flat-line CPU with no user traffic, and rungs 4 through 6 are aimed squarely at them. Spam — phishing pages, SEO doorway farms, outbound email abuse — is a content problem: it looks like a perfectly normal low-CPU web app, so compute fingerprinting never sees it. Spam is caught at rungs 2–3 (manual review, domain reputation) and at rung 6 only if you also fingerprint content: outbound mail volume, newly registered domains serving login forms, page-title matches against known phish kits. If your behavior detection only watches CPU graphs, you have a miner detector, not an abuse system. Name both workloads in the ruleset, or one of them walks past it.
Notice the shape of the table: rungs 1–5 trade growth for safety, while rungs 6–7 trade correctness for safety. That distinction matters because the two failure modes need different fixes. Too-strict signup costs you users you never meet — invisible, deniable, easy to ignore. Wrong-at-runtime costs you users who page you — visible, undeniable, and, as Railway learned, capable of taking down databases that did nothing wrong.
The metric that matters: false-positive rate, not catch rate
Every abuse system reports its catch rate: how many bad accounts it stopped. That number always looks good and tells you almost nothing. The number that decides whether the system is an asset or a liability is the false-positive rate — what share of enforcement actions hit legitimate tenants — because the costs are asymmetric. A missed miner costs you $7–15 in compute. A wrongfully terminated production database costs you a customer, a status-page entry, and a story retold every time someone evaluates your platform.
Railway's incident is the canonical demonstration. Their ruleset passed extensive staging tests and a production dry run with correct abuse identification — and still misfired the moment it went live fleet-wide, because staging never contains the full weirdness of real customer workloads. To their credit, Railway's remediation list is the template every smaller platform should steal:
- False-positive testing against a broader range of common workloads before rollout — not just known-abuse samples, but Postgres, MySQL, background workers, the boring stuff that must never match.
- Longer observation windows for enforcement changes — dry-run longer than feels necessary, because novel abuse patterns and novel legitimate patterns look identical on day one.
- Staged rollout by tier — new rules hit free tiers first and paying tenants last, so a misfire burns credit, not contracts.
- Safeguards for known-legitimate process types — an explicit allowlist (database engines, health-check endpoints) that enforcement can never match, no matter what the heuristic says.
Add two operational rules of your own on top. First, enforcement actions must be visible and truthful in your own dashboard: Railway's console showed terminated workloads as active, which meant customers debugged their apps while the platform had already killed them. If your abuse system can pause a workload, pausing must be a first-class, accurately displayed state — not a silent SIGTERM behind a green status dot. Second, measure appeal outcomes as a metric, not as support tickets: every overturned suspension is a labeled false positive. Track the overturn rate per rule, and auto-disable any rule whose overturn rate crosses your threshold. That feedback loop is the difference between a system that learns and one that re-offends.
Monday morning: the starter config with no fraud team
If you run a self-hosted multi-tenant platform and have no dedicated trust-and-safety staff, here is the concrete starting position. Three defaults, each reversible:
- Card verification plus a hard spend cap for every new tenant. This single combination — rung 4 plus rung 5 — eliminates the economics of both mining (capped compute per stolen identity) and runaway bills (capped spend per compromised account). Accept the conversion hit explicitly; it is cheaper than one incident.
- Behavior detection in log-only mode for 30 days before it can touch anything. New rules observe and alert but never enforce. Promote a rule to enforcing only after its logged matches have been human-reviewed against real tenants — Railway's dry run was the right idea with too short a window.
- Suspend, never delete — and notify with the reason and a one-click appeal. Deletion destroys the evidence the tenant needs to prove innocence and the evidence you need to fix the rule. A paused workload with "flagged for sustained 100% CPU with zero ingress at 03:12 UTC — appeal here" is recoverable. A deleted one is a postmortem.
Then loosen deliberately: drop to manual approval only when the waitlist queue, not your ambition, says so; move paying tenants into later enforcement tiers; publish your acceptable-use policy so enforcement never feels arbitrary. Strict-to-loose is a ratchet you control. Loose-to-strict after an abuse wave is a panic — and panics are what ship overly broad heuristics on a Friday afternoon.
The asset test
Zoom out and the pattern repeats at every layer of the stack. In May 2026, Google Cloud suspended Railway's own corporate account without warning, taking down the control plane Railway's edge proxies depend on — enforcement false positives happen to platforms, not just to their tenants. Nobody in this chain gets to opt out of verification; the only choice is whether your layer's version is measured, staged, and appealable, or a blunt instrument waiting for its February 11.
So here is the one-line audit for any abuse system, yours included: can you quote its false-positive rate, and would you survive publishing it? If the answer to both is yes, the system is an asset. If you only know the catch rate, you are flying the half of the dashboard that always looks green — right up until your own automation becomes the incident.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources
- Railway, Incident Report: February 11, 2026 — timeline, impact (~3% of fleet, SIGTERM to legitimate workloads including databases, inaccurate dashboard status), and remediation commitments.
- Sysdig Threat Research via Dark Reading/TechTarget/TechRadar — PURPLEURCHIN freejacking: 30 GitHub, 2,000 Heroku, and 900 Buddy accounts; ~$15/month per GitHub free account, $7–10 for Heroku/Buddy.
- TechCrunch, Heroku announces plans to eliminate free plans, blaming 'fraud and abuse' — November 28, 2022 end of free dynos/Postgres/Redis.
- The Register, Railway pauses lowest tiers after onrush of GCP customers — Trial/Hobby throttling, $5 trial credit, $1/month recurring credit.
- Railway, Updates on Plan Changes — attach-card-to-verify, prepaid plans, starter-plan execution limits.
- Fly.io community forum (staff response, August 2025) — credit cards as abuse prevention; no crypto payments for that reason.
- The Register, Google Cloud suspended major customer Railway.com without cause — May 2026 upstream enforcement outage.
