I have a new project I have been working on, a long lived network server. Build went from in emacs compile, using go, basically only noticeable time is the tests; added a few more components CLIs and a proxy server, so did the Makefile thing, works fine, very fast, still use M-x compile for active coding.

I just spent three days making it dockerized and the builds are often 5 minutes, due to go build getting all the deps at the go mod tidy stage which is after the copy source tree into docker step and hence not cached at all. Deployment will be on docker so whatever.

After a day of writing go, I feel happy and smart and content. After a day of getting docker files to works I feel pleased but a little like I have eaten too much candy.

"CI/CD" tends to be associated with "building/deploying the software from a fresh environment". e.g. Aim to reduce mistakes of "I forgot to check these important files into the code repository".

Some CI/CD services like GitHub Actions or TravisCI will take a configuration file which declares the CI/CD steps to run. These services will run the build on some machine; but the point of "self hosting is good" is that you'll be able to run the CI/CD build with a more powerful host, and complete the CI/CD build quicker compared to the 'managed' cloud builders.

Even locally,I’m will have my active dev directory, and a just git directory where I git clean -d -f -x ; git pull ; make periodically to protect against such distressingly common errors.

Doesn’t address local tools dependencies, but those tend to be less (tho golangci-lint is like ten minutes of downloads for the over 100 deps (and due to or terrifically slow MITMed network proxies) I finally just made all the build tooling a published base image for the actual builds).

In Azure DevOps at least, 'self hosting' means running the CI/CD on your own private server which could be a VM, bare metal, even a container. This method has some advantages like being able to fully customize your tooling, it could be less expensive, faster, etc. All depends on your use case.