Set it up once. Snapshot an image (called an AMI on AWS, but applies on all cloud services). Use the image to make new identical instances.

You can also script the process with (for example) Terraform.

Nearly every company I've ever worked for could get away with only using:

- packer for images

- terraform for prod infra

- vagrant for local dev

- pssh for ci/cd and config management

And in some cases I would say they'd be far more efficient with this setup.

Heroku or alternatives

create - terraform, install / manage - cfengine / ansible / chef

A single ansible yaml

All the responses you got so far suggest exactly what this "Ask HN" actually wants to avoid: Terraform, AMI, Packer, Ansible, Chef ..., the list goes on

Here is my suggestion for keeping it simple, by solely relying on skills you will need anyways: git and shell scripting.

- Write a shell script that executes all those commands you would run manually to set up your system.

- Put up a git repository in the `/` directory, `.gitignore` everything by default, and explicitly git-notignore all those configuration files and user files/maintenance scripts which are relevant for your environment. Use githooks to also track/restore file permissions and ownerships of these tracked files.

Either the snapshot route to have a base image you can then run a single script to install the app. Or use something like Ansible to have reproducible configuration.

Honestly I use bash for this. I keep a local repo of .deb/.tar.gz files and scp them onto a machine which makes them reproducible. I use uvt-kvm for VMs, config files to cover basic settings, and that's basically it. I run a fairly decent sized test lab with multiple servers that have to be reproducible, quick to edit, and install fairly complex toolchains.

You launch the instance with "aws" CLI, passing it a user-data script (cloud config) that does all the things you describe with simple shell scripts. You install the app by copying it from an S3 location (build output), which is also defined in the script.

If you later want to port this into terraform, you can.

There is already many answers to your question and not to be rude, but I think it perfectly shows part of the problem OP is talking about.

Every single answer goes straight to name dropping various specific techs/tools and I don’t doubt it really is the most simple way for each poster. But I think a much better answer, would be a bunch of questions that dig into what kind of problem you are trying to solve, what are the circumstances, skillset, limitations, budget, is it 1 tiny private app for fun or a couple of apps your team or even company depends on etc.

Because it depends on the specifics in _your_ situation and jumping straight to _a_ solution, without understanding _your_ problem, is imho part of the over-complexity-problem in our industry.