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.
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