TLS

HSTS on Railway sounds simple: add a header, force HTTPS, done. In practice, the right place to set it depends on how you deploy, whether you use Railway’s edge, and how much control you actually have over redirects and custom domains. If you run production apps on Railway, HSTS is usually worth enabling. But it’s one of those headers that can absolutely hurt you if you switch it on carelessly, especially with preload or a long max-age before your subdomains are ready. ...

If you serve HTTPS and you’re not using HSTS, you still have a weak first step. That sounds harsh, but it’s true. A site can have a perfectly valid TLS setup and still be vulnerable to downgrade tricks that push users onto plain HTTP before HTTPS ever gets a chance. HSTS fixes that by telling browsers: “for this site, never use HTTP again.” That one rule shuts down a whole class of annoying and very real attacks. ...

HSTS on Heroku looks simple right up until you ship it wrong and lock users into a bad HTTPS setup. I’ve seen this happen a few times: someone enables SSL on Heroku, adds a redirect to HTTPS, throws in Strict-Transport-Security, and calls it done. Then a week later they realize staging is broken, a custom domain is misconfigured, or preload was enabled before every subdomain was actually ready. Heroku makes TLS termination easy. That does not mean HSTS is automatic, or safe by default. ...

A few years ago, I helped clean up a messy HTTPS rollout for a mid-sized SaaS app. On paper, the setup looked fine: valid TLS cert, HTTPS redirect, load balancer in front, and a decent-looking security checklist in the wiki. In production, it was shaky. Users could still hit http:// directly. Some static assets loaded from old subdomains with mismatched certificates. One internal team wanted to turn on HSTS preload immediately because they’d read that “preload means maximum security.” That would have been a great way to lock broken TLS behavior into every browser. ...

I’ve seen this pattern more than once: a team moves fast, sets up HTTPS, gets the padlock in the browser, and assumes transport security is done. Then somebody runs a header scan and finds the obvious gap: no HSTS. That was the situation with a small Bun-powered app I helped review. The site served authenticated pages over HTTPS, redirected HTTP to HTTPS, and generally looked fine at a glance. But the first request was still vulnerable. A user typing example.com or following an old http:// bookmark could be intercepted before the redirect ever helped. ...