Redirect any path with a .redirects file
You renamed a page. You reorganized your blog. You moved your docs from /manual to /docs. The moment you push, every link pointing at the old URLs starts returning 404s, and every spot where Google cached your old structure slowly rots.
Today we’re shipping redirects. Drop a .redirects file anywhere in your site, one rule per line, and the rules go live on your next fyra push. Same philosophy as .auth: your site is configured by files that travel with your site.
Sources match exactly, one path per line. No globs, no wildcards, no regex. If you need a whole section moved, list the paths; the deploy fails loudly if you typo one, which beats a silent pattern that matches too much.
- Each line is
source target status, with the status optional.301(permanent) is the default;302,307, and308are available when semantics matter. - Sources are site-absolute paths like
/old-blog-post, matched exactly. - Targets can be site-absolute (
/blog/new-post) or full URLs (https://...), so you can redirect off-site. - Query strings are preserved:
/download?v=2redirected to an external target carries?v=2along. - Rules are enforced at the CDN edge, before requests reach your origin server. An origin-level fallback exists for requests that somehow skip the edge, so both layers agree.
Your .redirects file gets parsed on every deploy, and anything suspicious fails the push with the exact file and line:
- A malformed line, an invalid status, or a target that is neither a path nor an
http(s)URL fails withfile:line. - Two rules with the same source fail the push. The first would silently shadow the second, so we refuse instead of picking a winner.
- The combined cap is 100 rules across
.redirectsand.authfiles. - Near-miss filenames fail with a rename hint. If you push a file called
_redirectsor.redirect, nothing would consume it, so the deploy stops and tells you:
Redirects are available on every paid plan. On the free Campfire plan, a push carrying a .redirects file is rejected before anything uploads, with redirects not available on your plan.
The free beta for password protection from the July announcement has ended with this release: .auth now also requires a paid plan. The gate is state-based: any push whose file set still contains a gated dotfile is rejected before upload, so if you’re on Campfire with .auth files in your tree, remove them or upgrade before your next push.
This release also changes how .auth is enforced. Your .auth files still work exactly the same way: username:password per line, closest file wins, bcrypt-hashed on deploy. The difference is where the login prompt happens. Basic auth now runs at the CDN edge alongside redirects, so unauthenticated requests get turned away before they reach your origin.
That makes .auth and .redirects one system now: files in your tree, compiled into edge rules on every push, ordered and validated together.
Both features are server-side. No CLI upgrade needed; add the file and push.