Replies: 1 comment
-
It's not necessarily out of scope, just another thing that brings complexity. You can theoretically create a "scratch" environment, deploy to that and then just atomically swap it out, but it quickly gets hairy to manage for multiple workers (and multiple application runtimes). Won't mind seeing a pull request, but the cycles required for testing it just aren't there (I, personally, am just doing fixes and minor enhancements for specific runtimes at this point, since it doesn't bother me to have a little downtime when deploying--if I needed zero-downtime deployments, I'd just have 2 piku instances and a load balancer in front). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi. I'm curious to know if you've ever thought about implementing zero-downtime deployments, or is it out of the scope of this project?
Currently, there is a small downtime after stopping the existing app and spawning a new one on deploys.
In theory, archiving zero downtime requires spawning a new directory to install new dependencies and keeping the old directory with old processes running until the new processes are ready to take over.
Beta Was this translation helpful? Give feedback.
All reactions