Do you know Docker already? If not, that's a reason not to use it. There are clear advantages in having a production system that's expressed in terms of a text

Do you know Docker already? If not, that's a reason not to use it. There are clear advantages in having a production system that's expressed in terms of a text file that you can read instead of a bunch of stuff that's accumulated over time which you forgot. Especially if you're a solo maintainer of a system, because you're not a full-time SRE, you're not going to invest into making the system clearly documented and you have lots of other demands on your time, and that will bite you one day (e.g., do you have a plan for how you're going to test an upgrade to a new version of your OS or a new release of a language?). But there are plenty of ways to do that other than Docker. Principled usage of Ansible or even a hand-made shell script will work. If you're on a VM, you get 80% of the benefit of a container - you can spin up a new VM and try to provision onto it and switch over and see what happens. Or, as another commenter mentioned, if you hire a second engineer and need to get them set up on a test environment of their own, they can run the Ansible playbook or shell script on their VM. If Docker is the tool you understand for how to get replicable environments where everything is documented, use it. If it's not, use something else. But you should pick some tool.