10 months ago
Problem
I find myself needing to make frequent changes to services that rely on each other, and this leads to unnecessary downtime.
Context
For example, I have a web app that pulls from a Postgres database. Whenever I need to make a migration to the database schema, I also need to update the web app codebase.
Because the database and web app are separate instances, I cannot ensure that the changes apply at the same time. This means my web app will experience downtime as the new changes rebuild and redeploy to my Railway service.
Even though my database migrations often take only a few seconds, the downtime can take at least 10 minutes and sometimes much longer when Railway is experiencing delayed placements.
Solution
Allow users to mark new deployments as "Staged" such that instead of replacing the current active deployment they deploy to a separate instance in the background until manually promoted to the "Active" state. Once the user makes the necessary changes to the external service, they can instantly hot swap in the new deployment that was staged.
This would reduce the required downtime my web app experiences by over 90% because I can have the new deployment ready to go and not beholden to the Railway deployment queue.
0 Threads mention this feature
1 Replies
10 months ago
Brought to you by this 1 line commit that is still deploying and has caused my app to experience over 30min of downtime on a migration that took me 5 seconds... 🫠
https://github.com/nouns-esports/nouns-gg/commit/550a33a8b9e798d3df2323f035936acc4b8ea2f9
