The Simplicity of Single-File Golang Deployments

Re:The Simplicity of Single-File Golang Deployments by Edd314159 on Wednesday March 22, 2023 @10:19AM (#35261409)

I guess this is a problem inherent not just in a single-file go app, but in any deployment where the whole stack is contained within a single process.

The post says the process starts up quick enough that the process being temporarily unavailable isn't noticeable - but what if the process _doesn't come back_? It's also impossible to do blue/green deployments this way.

It's clearly not a solution suitable to large-scale deployments. The simplicity has its trade-offs.

[ Parent | on HN ]

Re:The Simplicity of Single-File Golang Deployments by InitialBP on Wednesday March 22, 2023 @03:58PM (#35266339)

If you want to do deployments with single-file apps or other "whole stack in a single process" type of deployments there are other options to do it with zero-downtime.

One good option would be to spin up a second server/instance/container, run binary on new system, ensure it's good, once comfortable then swap DNS entry to the new system.

[ Parent | on HN ]