I'm ssh'ing into an AWS EC2 instance and starting my API. I want the API to keep running and accepting requests.
So, is tmux a good way to do this? Or is there a better way? I was under the impression tmux and screen was more for really long tasks. Wasn't sure if they would be good for running an API indefinitely.
tmux and screen are for keeping one or more shell sessions alive even if your ssh connection to the destination system cuts out for any reason, and/or multiplexing several shell sessions over a single connection (think of it as similar to being able to open multiple terminal windows, but without a GUI interface).
Sure, you could use tmux to run your API service, but if your AWS EC2 instance is using systemd (as many modern Linux distributions do), the "right" way to do it would probably be to write a *.service file describing the commands needed to start & stop your service, and its requirements (i.e. what other services need to be running before your service can start successfully).
Then you can place the service file in the /etc/systemd/system/ directory, run systemctl daemon-reload and then you will be able to operate your service with systemctl start your-API.service and systemctl stop your-API.service. Just like a standard system service - because as far as systemd is concerned, it will be a system service.
Doing it that way allows you an easy way to specify resource limits for your API, to e.g. limit the possible harm in case the API is abused. And if you want to have your API service start automatically? systemctl enable your-API.service and you're done.
You can also specify in the .service file that you want your API service to be automatically restarted if it crashes on its own or gets killed. If you make your API service to periodically call sd_notify(3) with "WATCHDOG=1", you can even have systemd auto-restart your service if it seems to be hung.
There are also some security advantages: systemd will create a "control group" for each service it manages, and this control group is inherited by any child process created by the service. So even if your service "goes wild" and creates 10000 child processes (perhaps because someone on the internet is trying to abuse it), a simple systemd stop your-API.service (or systemd kill your-API.service if you want it stopped right now and don't care about doing a controlled shutdown of your service) will be sufficient to clean up all those processes: you won't have to think about pkill or pgrep expressions for manually finding the right processes and killing them.
If you wish, systemd will also be able to chroot your service (restrict it to see only a particular directory and its sub-directories). Or if you run the service on a user account dedicated for it (always a good practice whenever possible), you can prevent its processes (and any child processes they create) from being able to gain access to full system administrator powers, even if they might be able to become root by some exploit, by simply setting NoNewPrivileges=true in the *.service file of your service.
For more information and examples, see this question here on Unix&Linux.SE, or study the existing *.service files on your system and refer to man systemd.service and man systemd.exec to see what the various keywords mean.
