@dom96 True. I run docker-compose for consistency and separation mostly.
**consistency** It almost guarantees that the instance on my local laptop will be truly replicated on any instance I run on the cloud. My nginx configs always includes `*.localtest.me` support. Basically, I can test the website by: * running the app in the source directory (127.0.0.1:5000) * running the server in a docker-compose instance on my laptop with all the bells-and-whistles surrounding it, just like on the cloud. (thedomain.com.localtest.me) * running the server in production on the cloud. (thedomain.com) I also use `docker-compose` 's virtual environment variable support to avoid storing passwords and credentials in repos. Mostly. I'm not always consistent about that :). **separation** I typically run a couple dozen low-traffic websites on a docker-compose instance. I don't want the websites messing with each other. Actually, with Nim, I suspect I can run much more than that. Nim-compiled websites are really fast and have a tiny footprint. In fact, right now, one of my Nim-based websites is really messing up due to some obscure db-related bug. But the other 6 Nim sites on that same instance are running smooth and unaffected. **downside** The biggest downside, IMO, is the learning curve. If you are not comfortable with Docker, that is a non-trivial amount to learn. It has a lot of conceptual curve balls. It's like git. Only easy once you already understand it. A catch-22. But in general you are right. Anything than can run nginx and a compiled unix program can host a nim-based website. In fact, one would be hard-pressed to find systems that _can 't_ run a nim website. I've put them up on linode also, where I don't use Docker. (but could, but I use linode for experiments usually.)
