I am no security expert. But having a web app hosted on your server requires some basic security knowledge.
To get the record straight, I think security is one of the most difficult domains. Staying up-to-date in this domain is not a good-to-have skill. It's a necessary skill that can make or break things.
Nevertheless, following some simple best practices can get you to a reasonable level of security. I am not saying that your server will be unhackable if you follow these practices - I don't think there's such a thing as "unhackable" anyway. It's just for making the life of bad actors difficult, so hopefully, they won't bother with you when they are looking for an easy target.
Storing in your version control system any confidential key or secret required to authenticate your web app to an API is a no-go. If you read this and rushing to delete your keys from Git, don't forget that Git has a version history (that's the purpose of version control systems :). So deleting it is not enough, you need to delete it from history as well (or delete the history in general).
Even if the repository is private, storing sensitive data in Git is a bad idea. In general, these sensitive data should be kept on a need-to-know basis and most probably the source code is accessible by quite a few people that don't need to know these. Also, third-party plugins you might integrate for source code automation might get access to these sensitive data accidentally.
I can think of multiple other disastrous scenarios that (might not be obvious but) lead to sensitive data/keys be exposed from storing them in Git. So where should you place these keys? Some quick ideas are separate files that you can exclude in
.gitignore or environment variables. There's a big discussion on where to store them (just do a quick Google search), but pretty much everyone agrees that Git is not the right place.
Usually, the code we write is just a small fraction of the code that runs. All the libraries we are using must be kept up-to-date at all times possible. New versions (usually) fix bugs and sometimes critical security bugs. Keep including that old library in your web app just because it's a hassle to update, might backfire in the future due to a security exploit.
The same applies to OS updates. Keep the installed packages up-to-date and give special attention to the security updates available. Some OS might handle this auto-update automatically, but keep an eye just in case. Periodically running an
apt-get dist-upgrade just to ensure that everything is in the latest version is a good idea.
I don't think you need to get obsessed with this, but set a weekly/monthly reminder (depending on how popular/critical your web app is) and ensure that everything is updated.
In case your keys were compromised, it's a good idea to switch keys at reasonably regular intervals. This is similar to changing passwords periodically for highly sensitive accounts (e.g. some banks you ask to change passwords every year).
The reasoning behind this is that in case that your keys were compromised and you are not aware, this will deactivate the compromised keys. Hopefully, this will happen after you've fixed the reason that the original keys were compromised (e.g. outdated libraries).
In case you are using Docker to serve your web app, remember to check that the images you are using for your container are trustworthy. Prefer to use official images, or open-source images that you can audit exactly how they are built.
Hopefully, you got some ideas on how to keep your server and web app a bit more secure. As I said, these will not make your server "unhackable" but will make it a bit more secure.