I appreciate this blogpost. I'm the one at Railway responsible for this decision, so I wanted to share some context from our side.
First off, sorry you got nailed by this. I genuinely empathize because _we_ got nailed too - the Railway.com frontend is hosted on Railway, and we had references to these vuln versions buried in old packages that weren't used in live code. We couldn't deploy for a bit until we sorted it out. It sucked.
That said, I believe this was the right call for a few reasons:
1. We have to think about our entire userbase. Our DX makes deploying easy, which attracts a lot of non-technical folks such as PMs, vibe cobers, newbies, etc. A significant chunk of them would either have no idea this was happening, no idea what an RCE even is, or no clue how to fix it.
2. We're trying to break the "I'll fix it later cycle" because that mindset is how security debt piles up. Yes, it's a heavy-handed approach. It shifts the action item left in the SDLC by blocking vuln deploys outright. We _could_ just alert people, and we did, but we've learned the hard way that people don't read emails. This was the only intervention that actually worked. Other platforms like Vercel also took the same approach.
3. This disproportionately impacted users who weren't using Next.js. We had to scramble when attackers leveraging this exploit started causing degradation across <10% of our fleet [0].
Your feedback on container and resource isolation is valid; there's stuff we could do better, and we're working on it. As a platform, it's a hard dance between "you got pwn'd for ignoring shit" and "why didn't you protect us from this?"
We made this call to protect the majority, and I recognize it's not going to make everyone happy. Despite this, I would still have made the call. I wished the majority of our userbase knew better than us, but the reality is they don't. My only regret is not making this call earlier when we were first notified. The sad thing here is people like you who _do_ know better than us doesn't have an escape hatch out of this - and I would argue that this isn't an escape hatch we should be providing.
(And for the record, we aren't actively killing live running workloads on vuln versions unless our scanner picks up that they're compromised using heuristics we've developed for known cryptominers, etc.)
I've been here. Taking a vacation never helped, because I'd be stressed during the vacation thinking about "work" in an active manner.
What really helped me was fully disconnecting and shifting my mindset to think about work passively: I don't forbid myself from thinking about my work, but I do not action on it. Instead, I keep a physical scratchpad and write ideas and thoughts down continuously. This helps me refactor my perspective and shift it from "active building" to "passive expansion".
I've come to realize burnout is a function of expectation mismatch, and I think of it from thermodynamics perspective. Burnout operates like a pressure differential system where the gap between internal expectations and external reality creates unsustainable energy expenditure. In a closed system, energy imbalance leads to heat loss or system failure. Similarly, when your mental model of "what should be happening" constantly fights against "what is happening," you're burning cognitive energy just to maintain equilibrium.
The passive approach allows me to transform that pressure into potential energy. Instead of forcing immediate resolution (active building), you're allowing ideas to exist in a low-energy state (passive expansion). This mirrors how heat dissipates naturally rather than through forced cooling - it becomes a capacitor, storing energy for later use rather than demanding immediate conversion.
So the answer, for me, is "disconnect from doing while staying connected to thinking". This helps me recover much more efficiently, while keeping myself sharp and free of expectations of doing anything.
"I've come to realize burnout is a function of expectation mismatch"
This. No amount of break will solve the issue until you adjust your expectations, especially from yourself. I have been burnt out as a founder and taking time off made it worse because I still have a business to run and you cant just switch off as a founder. Can work for employees but not for founders. Only way is to stop expecting too much from you but still jeep the balance of keep moving forward.
Really hard to do. I struggle every day but I cannot quit doing it because i cannot do anything else (EDIT: I mean other than being a founder).
Sorry I should have been more clear. I meant that I cannot do anything else other than being a founder and run my own thing. With that, comes the burnout that cannot be solved by taking time off because you cannot just switch off like a regular employee can. So you have to solve the burnout differently.
From Jennifer Senior's excellent 2006 article about burnout titled "Can’t Get No Satisfaction" [1]:
Farber had burned out once before. Back in the late sixties and early seventies, he taught public school in East Harlem. He’d wanted to help people, do the world some good. Yet for four years he’d struggled to stop his students from fighting with one another, and in spite of his best efforts he couldn’t even teach all of them to read. His classroom became a perverse experiment in physics, with energy never conserved (input always exceeded output), and he, a teacher in perpetual motion, always craving rest. Eventually, he began to pull away from his students—depersonalization, as the literature now calls it—justifying his seeming insensitivity by telling himself he wasn’t making a difference anyway. It was only when Farber went to graduate school at Yale that he learned that this syndrome had a name: Burnout. “The concept offered a perfect understanding of what teachers were feeling,” he recalls. “It wasn’t in fact that they were racist and mercenary and noncaring but that their level of caring couldn’t be sustained in the absence of results.”
[...]
To me, the most beguiling data to emerge from burnout research are the profiles of the people who experience it most acutely. In her early work, for instance, Maslach found that younger people burn out more often than older people, a finding that turns up again and again both here and abroad. (In fact, that study from the University of Michigan explicitly said that younger surgeons burn out more quickly than older ones.) This conclusion may seem counterintuitive, because we associate burning out somehow with midlife disillusionment. But not if we think of burnout as the gap between expectations and rewards. Older workers, as it turns out, have more perspective and more experience; it’s the young idealists who go flying into a profession, plumped full of high hopes, and run full-speed into a wall. Maslach also found that married people burn out less often than single people, as long as their marriages are good, because they don’t depend as much on their jobs for fulfillment. And childless people, though unburdened by the daily strains of parenting, tend to burn out far more than people with kids. (This, too, has been found across cultures; in the Netherlands, a recent survey by the Bureau of Statistics showed that twice as many working women without children showed symptoms of burnout as did working women with underage children.) It’s much easier to disproportionately invest emotional and physical capital in the office if you have nowhere else to put it. And the office seldom loves you back.
I reject the entire premise of AI. Having a non-sentient algorith with no understanding of objective reality read or edit for me is counter productive. What it read, I did not read. What it researched, I did not research. What it edited, I did not edit. If we do nothing, we learn nothing and accomplish nothing.
If we go too long without doing things we lose the ability to do them. It degrades our skills, and cognition. From this perspective AI is antithetical to life, and in fact harms life.
I can read my own damn emails thank you very much.
I highly recommend Fastmail [0] for this purpose. I have been with them for 5 years, and they're rock solid. I have ~10 domains on it, they support wildcards (send/recv at anything@you.com), the composer has sane defaults for multiple domains (e.g. replies are sent from the address it was mailed to) that can be overridden when you need, and you can easily create masked emails using your own domain.
$50/yr for all that is a steal. They don't charge you per-domain or have any funky tiered pricing for the stuff that matters.
Disclaimer: I am not related to them, just a happy customer :-)
How are you "training" them? It's important to drill down into what they're struggling with before you throw resources at them.
I've found that code reviews are the best way to mentor and transfer knowledge. And it goes both ways: you review their code, they review your code. When I'm explicitly training someone, I get them to review my code and I occasionally throw in some minor curveballs that I expect them to pick up on in the first few rounds (e.g. obviously incorrect conditionals, some convoluted loop, leaky interfaces, etc.) If they stamp the PR without picking up on those items, I highlight it using a "do you think this is correct/is there a better way for us to do this" line of questioning. 5-10 or so PRs later, they become the first to spot those issues :-)
Thanks for sharing how you code reviews with your juniors! You're definitely more patient than me in that respect. I'll try that out.
Our training program mostly revolves around teaching them the fundamentals, where I give them some specs & resources, and once they code that, I give a code review:
- They learned how to build some CLIs programs, where they make small clones of cat, find, grep, and cut.
- They learned how to build some basic data structures such as linked lists and some sorting algorithms.
- They learned some OOP by creating a CLI employee management system
- Also some Network Programming by replicating the core features of the rack gem, and building their own web framework from scratch
- They then take their hand-rolled frameworks, and they build the web version of the employee management system and ship it to heroku
- Other projects also include some common tasks in the company, such as creating their own authentication system.
- Lastly, they build their own design system using BEM CSS (a designer hands them a figma file, and they follow our internal CSS template / variables)
All of the above projects include code reviews, and the hope is that they learn how to become independent programmers & be able to contribute to any code, whether internal or open source. The goal is mastery of fundamentals.
I am not sure if I am too demanding -- our sprint is about 1.5 months long (0.5 months are for QA), but the expectation of that sprint is to ship one or a few features (e.g. a share button for a CRM for example).
You'd probably branch off a previous feature branch, introduce the bugs then do a mock PR that doesn't get merged, maybe even against a copy of the dev branch in case of accidents.
`requests` is just a HTTP library. Classifying it as a "scraping library" is confusing; it's part of the web scraping toolkit, but it's not a "scraping library".
ORMs come to mind. There's typically a lot of reflection and dynamic instantiation magic baked into its classes, which you really have to hack around typing to make it work nicely (or even at all).
First off, sorry you got nailed by this. I genuinely empathize because _we_ got nailed too - the Railway.com frontend is hosted on Railway, and we had references to these vuln versions buried in old packages that weren't used in live code. We couldn't deploy for a bit until we sorted it out. It sucked.
That said, I believe this was the right call for a few reasons:
1. We have to think about our entire userbase. Our DX makes deploying easy, which attracts a lot of non-technical folks such as PMs, vibe cobers, newbies, etc. A significant chunk of them would either have no idea this was happening, no idea what an RCE even is, or no clue how to fix it.
2. We're trying to break the "I'll fix it later cycle" because that mindset is how security debt piles up. Yes, it's a heavy-handed approach. It shifts the action item left in the SDLC by blocking vuln deploys outright. We _could_ just alert people, and we did, but we've learned the hard way that people don't read emails. This was the only intervention that actually worked. Other platforms like Vercel also took the same approach.
3. This disproportionately impacted users who weren't using Next.js. We had to scramble when attackers leveraging this exploit started causing degradation across <10% of our fleet [0].
Your feedback on container and resource isolation is valid; there's stuff we could do better, and we're working on it. As a platform, it's a hard dance between "you got pwn'd for ignoring shit" and "why didn't you protect us from this?"
We made this call to protect the majority, and I recognize it's not going to make everyone happy. Despite this, I would still have made the call. I wished the majority of our userbase knew better than us, but the reality is they don't. My only regret is not making this call earlier when we were first notified. The sad thing here is people like you who _do_ know better than us doesn't have an escape hatch out of this - and I would argue that this isn't an escape hatch we should be providing.
(And for the record, we aren't actively killing live running workloads on vuln versions unless our scanner picks up that they're compromised using heuristics we've developed for known cryptominers, etc.)
[0] https://blog.railway.com/p/incident-report-december-16-2025
edit: typos and minor phrasing tweaks