The docs don't make it clear, can it do "zero downtime" deployments? Meaning it first creates the new pod, waits for it to be healthy using the defined health checks and then removes the old one? Somehow integrating this with service/ingress/whatever so network traffic only goes to the healthy one?

I can't speak on it's capabilities, but I feel like I have to ask: for what conceivable reason would you even want that extra error potential with migrations etc?

It means you're forced to make everything always compatible between versions etc.

For a deployment that isn't even making money and is running on a single node droplet with basically no performance... Why?

> I can't speak on it's capabilities, but I feel like I have to ask: for what conceivable reason would you even want that extra error potential with migrations etc?

It's the default behavior of a kubernetes deployment which we're comparing things to.

> It means you're forced to make everything always compatible between versions etc.

For stateless services, not at all. The outside world just keeps talking to the previous version while the new version is starting up. For stateful services, it depends. Often there are software changes without changes to the schema.

> For a deployment that isn't even making money

I don't like looking at 504 gateway errors

> and is running on a single node droplet with basically no performance

I'm running this stuff on a server in my home, it has plenty of performance. Still don't want to waste it on kubernetes overhead, though. But even for a droplet, running the same application 2x isn't usually a big ask.

Zero downtime doesn't mean redundancy here. It means that no request gets lost or interrupted due to a container upgrade.

The new container spins up while the old container is still answering requests and only when the new container is running and all requests to the old container are done, then the old container gets discarded.

You can use firecracker !