There are different options to consider. Which one you pick depends on your requirements and preference.
You just put all the values right into your sourcecode.
This is the easiest solution for the programmer because no code is needed to read these values from a file or database. Unfortunately it is a real maintainance nightmare, because only a programmer can change the values and each change requires to recompile the binary.
This solution is only recommendable for very small games or during the prototyping stage.
Put the values in a file
You store the values in one or more file in JSON, XML, CSV or some other format. When the server starts, it reads the file and loads all the values from it. When you do it well, you can even design your server in a way that it can reload and apply the files without having to restart.
Maintainers can then edit these files with any text editor without having to change the sourcecode. You also have the option to develop a GUI-based tool to edit these files, when you feel that it is worth the effort.
Another advantage of files is that any files which are needed by both the server and the client can be easily shared between server and clients through your usual asset distribution process.
Put the values in a database
You need a database anyway for storing all your dynamic data, so putting your static data there seems like an obvious solution.
The advantage is that databases are built for having multiple users work with them at the same time. That means your maintainers can work in parallel without edit conflicts. When you would use files, multiple users would not be able to edit the same file at the same time.
However, there are some drawbacks to databases: Editing a live SQL database (or some noSQL solution, when you swing that way) can not be done with a text editor. Your maintainers either need to know SQL (which is a really inconvenient way to do data entry) or they need a GUI tool. There are general-purpose GUI tools available for SQL databases which make this a bit more convenient than a SQL shell, but are still not as intuitive as a simple text editor. That means you likely won't get around writing your own GUI tool for maintaining your data.
Another drawback of databases is that they usually can not be versioned. A text file can be put under version control, so you have a change history. But with a SQL database, you can't do this. You would have to implement your own versioning feature in your GUI application.