A WAF and rate limiting without a separate edge vendor

A lot of what a dedicated edge/WAF vendor sells is genuinely just a reverse proxy doing its job properly: check the request before it reaches the app, not after. Railyard runs one web proxy in front of every server’s apps already — these are the rules that run there, most of them configurable from the app’s own Settings → Networking tab, no separate vendor relationship required.

What’s live today, no caveats

• Password and IP rules. Put a password on a staging or admin tool in one field; allow or deny specific addresses or CIDR ranges, with everyone else getting a clean 403.
• Redirects and rewrites — up to 100 rules, checked in order, first match wins. 301/302/307/308 or a same-app rewrite that keeps the query string. Off during maintenance mode, so a redirect rule never masks a real outage.
• Response headers and CORS, up to 50 rules. Set a header, or remove one your app sent with -Name. CORS preflights are answered by the proxy itself and never reach the app at all — which also means a password-protected app correctly answers preflights with 401 instead of leaking a CORS response first.
• Your own SSL certificate. Paste a PEM cert and key; Railyard verifies the key matches, the cert is valid now, and it actually covers one of the app’s addresses — before saving, not after something breaks. Stored encrypted, never returned by the API, and deliberately kept out of railyard.yml so a private key never ends up in git.
• Error and maintenance pages, served with the real status code (502/503/504) instead of a generic blank failure.

What’s real but still rolling out — stated honestly

Three features exist and are fully configurable today, but need Railyard’s own edge proxy image on a server, which is still being rolled out fleet-wide. Until a given server has it, the rule is saved but not applied, and both the settings card and the deploy log say so plainly — nothing pretends to be active when it isn’t:

• Web Application Firewall — every request checked against the OWASP Core Rule Set (SQL injection, XSS, the other standard CRS categories) before reaching the app. Three modes: off, detect (logged, never blocks — the right first step to see what it would have stopped before turning enforcement on), and block (enforced, returns 403).
• Rate limiting — requests per minute per client IP, settable for the whole app and per path (/login 10, /api/* 120). Over the limit gets 429 with Retry-After. One real limit worth knowing: counters live in each server’s own memory, so an app spread across several servers gets the limit per server, not a global total — and behind Cloudflare or another proxy, every visitor currently looks like that proxy’s IP.
• Country blocking — two-letter country allow/block lists, UNK for addresses with no known country, checked before rate limits, redirects, or the app itself. Private and internal addresses always get through regardless.

Why the honesty matters here specifically

A WAF that’s silently not enforcing is worse than no WAF, because it creates false confidence — the one thing this category of feature can’t afford to get wrong. Saying plainly “saved but not applied yet” in the product itself, not just in a changelog, is the actual safeguard against that, and it’s worth saying here too rather than implying everything above is uniformly live.

Full reference: Edge rules.