When you host a server software (or plural) on a server computer, it is often not enough to host it and forget it. Server administration is a big responsibility.
Here are some habits to follow to make it easier on yourself.
Unix User Management
In Unix, each user can be part of multiple groups. Each file is owned by a user and a group. The owning user has some permissions over the file, and so do all members of the owning group. These permissions may not be the same. There are also permissions defined for other users.
Each of the three entities may be permitted to or barred from reading, writing, and executing the file.
This may be represented as a string of the form "rwxrwxrwx". Each of the "rwx"s refers to permission to Read, Write, and eXecute the file, with each triplet representing the permissions held by owner, group, and others respectively. Ungranted permissions are denoted by a hyphen. Most files are owned by the user that created the file, and the group with the same name as the user. The owner and the group are allowed to read and write to the file, while others are only allowed to read it, thus making the permissions "rw-rw-r--".
Permissions can also be represented by three digits, with each digit representing which permissions are had by the owner, group, and others respectively. Read permissions are equivalent to 4, Write permissions to 2, and eXecute permissions to 1. Adding them up gives the digit for that class. The above example would be represented as "664".
Unix Services
In Unix, a service is software that runs in the background, without user interaction. It can be configured to start running automatically. You would want to set this up individually for each of your server software.
"Robot" Users
I recommend creating a dedicated user account for every server software you run. If any of the servers has a vulnerability that allows an attacker to execute arbitrary code, strict permission management will ensure that the effects don't spread to other files.
Instructions on how to do so are here.
Scripting
You will be running bash commands to install, run, and upgrade the server software. Collect them into bash scripts to make it possible to run each process with a single command. Having a run.sh, in particular, also makes it easy to autostart your application through the aforementioned robot user.
Source Code Management
Even if you are not developing the server software yourself, I recommend using a Source Code Management (SCM) tool (the overwhelmingly popular choice being git) just to store your install.sh, run.sh, and upgrade.sh scripts. That way, you can store your code in a hub for SCM (like GitHub) and reuse it.
If you are developing the server software yourself, and not using an SCM tool, it better be because you're new to software development. Using an SCM tool helps you know which version of your software is ready for the public (called production), which is the version in its final stages of testing (called staging or release candidates), and which are the versions which are being currently modified to fix bugs or add features (called development).
Having a staging environment is invaluable for avoiding a mistake like CrowdStrike did, ensuring the update from the previous production version to the next planned production version can be done smoothly.
Logs
Logs are a useful tool for an administrator. Whenever software crashes, it outputs some error message. Usually you would see this in the terminal. For background services, you will need to redirect the output to a log file. This way you can go through the logs when you encounter an issue and trace it back.
If you are a developer, implementing extensive logging in just about every function will help you greatly.