I'm not great at such things, but here are some ideas on where to start looking.

Most of this is probably overkill for your situation, so concentrate on suggestions #2 and #4. This is especially important if you need something running in the foreground, because the other two suggestions don't have an associated foreground.

Since you did mention the magic word, "server", the other two options may be worth considering as well.

1) When Linux boots it goes through one or more run levels to get running. (What run level does what varies a bit from distro to distro.) Each run level has a set of scripts that are executed when the run level starts. The scripts themselves live in /etc/init.d. Each run level has a directory /etc/rcx.d where x is the run level 0 - 6. I think 3 is for normal up and running, but you'll have to check.

In each of these directories, you put symlinks to your scripts that are in /etc/init.d and you name them starting with a two digit number prefix. When the run level starts, all the scripts in its directory are executed in order by the prefix numbers so that things happen in a predictable, orderly manner. Add a link (with a high number prefix so it gets executed after everything else that's already there) to your script into rc3.d (or whatever the right run level is for your system).

If you want to get fancy, there's a file called skeleton in /etc/init.d that show you a bit about all the bells and whistles that are available. E.g. You can write you script as a big case statement with a case for START, STOP, etc. and symlink it in the appropriate run levels to start your program and then shut it down when the system is shutting down. If you do this, the symlink you add to the shutdown run levels should have a low numeric prefix so it gets done before everything else it may need has been shut down.

Look at the PATH notes in skeleton. The paths you have available during run level changes are very restricted, so you don't have access to everything.

If you go this route, make backups and have a live CD, etc. ready in case you do something that breaks the boot sequence.

2) When bash starts up on your user (usually, once per session), it runs ~/.profile which is itself a bash script that can run whatever you want for your particular user.

When an individual bash shell is started (can happen many times per session), another script, ~/.bashrc is also executed. You can run your script from either of these as appropriate. It's a lot closer to what you normally would do in a terminal, so it's a lot easier and safer to do.

Since things run this way are associated with your user, they will terminate when you log out unless you do special things like using nohup in your scripts.

3) You can store your script somewhere in system land like /usr/bin or /usr/local/bin and set up cron to run it by adding an entry into either the system crontab or your user's crontab.

If your system stays up a lot, you should add a check in your script so it doesn't do anything extra if another instance of it is already running or has run since the last boot.

If you use a notebook or other system that gets turned off frequently, make sure anacron is installed and working. Shortly after boot, it (over simplified) looks at cron activities to see if any were missed while the system was off and runs them. Usually, scheduling things to run shortly after midnight simplifies things so that it's less likely something will get run twice in the same day.

4) If you use a gui desktop like kde or gnome, they have startup script utilities that will run things for you. kde puts them in $HOME/.kde/Autostart. You can put your script there.

The same considerations apply that were noted in suggestion #2.