The database password is irrelevant unless your database is exposed to an attacker - if it is, you've not set your system up correctly. Your first line of secu

The database password is irrelevant unless your database is exposed to an attacker - if it is, you've not set your system up correctly. Your first line of security should be the perimeter - preventing access to services which aren't needing exposed (like databases). Then you should consider your exposed attack surfaces you can't avoid - the SSH interface for git over SSH, and the HTTPS interface for web access. You could protect the HTTPS interface by requiring a client certificate before allowing a connection, by using a reverse proxy like nginx or caddy. If you do this, make sure your underlying gitea web server isn't accessible from outside of the server (e.g. via another port). For the SSH interface, look at whether you are using the system SSH instance, or another one - if you run gitea via docker, you can have an isolated SSH instance running on a separate IP (or port) from your underlying system, and limit the risk of a compromise. But don't overlook the simplest issues - using weak or re-used user passwords, not using MFA, using passwords for SSH. At a certain point, your VPS is probably more vulnerable to attack through your regular management SSH access, or the customer portal of your VPS provider.