Game servers · 9 min read · Updated May 2026 · by Hostini Team

How to auto-start a FiveM server on VPS boot with systemd

Set up your FiveM server to come up by itself after a Linux VPS reboot using systemd, with automatic restart on crash and centralized logs.

A production FiveM server has one simple rule: it needs to be online when a player connects. A VPS reboots for kernel updates, power loss at the datacenter, scheduled maintenance or a crash of the FXServer process itself — and any of these events takes the server down if it depends on you manually reopening tmux and running run.sh.

This tutorial configures the FiveM server on a Linux VPS to come up by itself at system boot, automatically restart on crash and stay monitored through systemd like any production service. The persona here is the owner who already has the server installed, knows how to run run.sh manually and wants to drop the dependency on an active SSH session.

Estimated time: 15 to 20 minutes. Works on any Linux with systemd (Ubuntu 22.04+, Debian 12+, AlmaLinux 9+).

Prerequisites

Before you start

You need a Linux VPS with FXServer already installed and working manually, sudo (or root) access, port 30120 open in the firewall and basic familiarity with a text editor (nano or vim). If you haven’t installed FiveM yet, do that first — this tutorial assumes bash run.sh brings up the server without error.

Identify the data of your current setup before moving on — you’ll need it when writing the service unit:

FXServer path /home/fivem/server

Server data path /home/fivem/server-data

System user fivem

Default port 30120 UDP/TCP

The paths above are convention — adjust to match your actual structure. If you installed everything in /root/fivem, swap them for your paths in every command of this tutorial.

Create a dedicated user for the server

Running FiveM as root is an unnecessary risk vector. If you already have a separate user, skip this section.

Create a system user without an interactive shell (you don’t need to log in directly with it):

sudo adduser --system --group --home /home/fivem --shell /bin/bash fivem

The --system flag creates a low UID (under 1000), the standard for service accounts. --group creates a group with the same name.

Move the FXServer files into the new user’s home (if they’re not there yet) and fix ownership:

sudo chown -R fivem:fivem /home/fivem

This guarantees that the process running as fivem can read resources, write logs and store cache.

Confirm the user can run the server manually. Use sudo -u fivem -i to switch to it and test:

cd /home/fivem/server-data
bash ../server/run.sh +exec server.cfg

If it comes up without error, stop it with Ctrl+C. The systemd service unit is going to run exactly this command — only without a terminal attached.

Create the systemd service unit

The service unit is a text file that describes to systemd how to start, stop and monitor your server. It lives in /etc/systemd/system/ with a .service extension.

Create the service file:

sudo nano /etc/systemd/system/fivem.service

Paste the configuration below, adjusting paths to reflect your installation:

[Unit]
Description=FiveM Server (FXServer)
After=network-online.target mysql.service
Wants=network-online.target
Requires=mysql.service

[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server-data
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10
StartLimitBurst=5
StartLimitIntervalSec=300
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fivem

# Optional but recommended hardening
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only
ReadWritePaths=/home/fivem

[Install]
WantedBy=multi-user.target

Each block has a specific role:

After= and Requires=mysql.service guarantee the database is ready before the server starts. If you use MariaDB, swap it for mariadb.service. If you have no database, drop those two lines.
Restart=on-failure restarts on crash but not on clean exit (Ctrl+C / systemctl stop).
StartLimitBurst=5 and StartLimitIntervalSec=300 prevent an infinite restart loop from eating CPU.
The hardening block isolates the process from the rest of the system — if an exploitable resource is loaded, the damage stays contained.

Careful with ProtectHome if the server lives in /root

The ProtectHome=read-only directive blocks the process from writing anywhere in /home. If you installed FiveM outside /home (e.g. /opt/fivem or /root/fivem), adjust ReadWritePaths= to point at that folder — otherwise the server can’t write cache or logs and breaks silently.

Save the file (Ctrl+O, Enter, Ctrl+X in nano) and reload systemd so it sees the new unit:

sudo systemctl daemon-reload

Without this command, any change to .service files is ignored until the next reboot.

Enable and start the service

enable makes the service come up automatically at every boot. start launches it now. They’re separated on purpose — you may want one without the other.

Enable automatic boot:

sudo systemctl enable fivem.service

The output shows Created symlink /etc/systemd/system/multi-user.target.wants/fivem.service. That symlink is what makes systemd load the service on every startup.

Start the service now:

sudo systemctl start fivem.service

The command returns immediately — the process goes up in the background. Don’t confuse silence with success, check status in the next section.

Verify it’s working

Check the service status:

sudo systemctl status fivem.service

You should see Active: active (running) in green, with PID, uptime and the latest log lines. If it shows failed, jump straight to the detailed logs.

Follow the logs in real time:

sudo journalctl -u fivem.service -f

-u filters by unit, -f follows in real time (Ctrl+C to leave). You should see the typical FXServer boot messages: Server started on port 30120, resource loading, etc.

Test the automatic restart by forcing a crash. Kill the process manually:

sudo pkill -f FXServer

Wait 10 seconds (the RestartSec=10 from the unit) and run systemctl status fivem.service again. The PID should be different — systemd restarted on its own. Logs will show Stopped, Start request repeated too quickly (if applicable) or a new Started.

Last, the definitive test: reboot the VPS.

sudo reboot

Wait 1-2 minutes, reconnect over SSH and run systemctl status fivem.service. If it shows active (running), your configuration is complete — the server now comes up on its own at every future reboot.

Troubleshooting

The service hangs in “activating” and never reaches “active”

FXServer takes a few seconds to initialize resources. If the service stays stuck at activating (auto-restart), it’s usually a boot failure. Look at the full logs from the latest cycle:

sudo journalctl -u fivem.service -n 100 --no-pager

Common errors: bad syntax in server.cfg, missing resource under resources/, port 30120 already taken by another process, or MySQL not ready yet. If it’s the last case, confirm with systemctl status mysql that the database is active.

Server comes up but nobody can connect

Check that the port is actually listening:

sudo ss -tulpn | grep 30120

A line with users:(("FXServer",pid=...)) should appear. If it does but external connections fail, the problem is the firewall — verify UDP+TCP rules on port 30120 with sudo ufw status or sudo iptables -L -n.

Logs are too verbose and filling up the disk

Cap the journal size

By default, systemd-journal grows without bound. Edit /etc/systemd/journald.conf and uncomment SystemMaxUse=500M and MaxRetentionSec=2week. Apply with sudo systemctl restart systemd-journald. This keeps enough history for debugging without blowing up the disk.

Server restarts in a loop and pegs the CPU

StartLimitBurst=5 already protects against this, but if you removed that line for some reason, put it back. To stop the loop immediately without editing the file:

sudo systemctl stop fivem.service
sudo systemctl reset-failed fivem.service

Then investigate the cause of the crash in the logs before re-enabling.

Next steps

With the server coming up on its own, it’s worth hardening the setup with:

txAdmin as a wrapper: configure ExecStart to launch txAdmin instead of FXServer directly. You get a web panel for scheduled restarts, resource management and extra protection against specific FXServer crashes.
Automated server-data backup: set up cron or another systemd timer to export the resources/ folder and the MySQL database to external storage daily.
Uptime monitoring: integrate with Uptime Kuma or an external healthcheck pointing at http://your-ip:30120/info.json — you get an alert when the server drops before players even complain.
Per-systemd resource limits: add MemoryMax=4G and CPUQuota=200% to the unit to keep a memory leak from taking down the whole VPS.

If you’re moving the server into production, a Hostini VPS comes with low latency for nearby players and DDoS protection — combined with the auto-restart from this tutorial, your uptime lives in the infrastructure instead of in your availability to type bash run.sh.

Frequently asked questions

Why use systemd instead of tmux with cron @reboot?

systemd gives you automatic restart on crash, centralized logs through journalctl, boot-time dependencies (waiting for MySQL/Postgres to come up first), resource limits and watchdog. tmux + cron @reboot only starts the process once — if it crashes in the middle of the night, nobody restarts it. For real production it's systemd; tmux is for development.

Does the FiveM server need to run as root?

No, and it shouldn't. Create a dedicated user (`adduser fivem`), put the server files in its home and configure the service unit with `User=fivem`. It runs on high ports (30120 UDP/TCP by default), so it doesn't need root. If an exploit compromises the process, the attacker is stuck inside the fivem user instead of the whole system.

How do I make the server wait for MySQL to come up before starting?

Add `After=mysql.service` and `Requires=mysql.service` to the `[Unit]` section of the .service file. For MariaDB use `mariadb.service`. This makes systemd only start FiveM after the database is available — it avoids the server coming up broken, failing the connection and falling into a restart loop.

Can I use txAdmin and systemd at the same time?

Yes, and that's actually the recommended pattern. The systemd service starts txAdmin, and txAdmin manages the FXServer process internally with its own auto-restart on crash. You get two layers: systemd makes sure txAdmin never dies, and txAdmin makes sure FXServer restarts on resource crashes or hangs.

How do I see if the server restarted by itself overnight?

Use `journalctl -u fivem.service --since '1 hour ago'` or `systemctl status fivem` — the restart count and the timestamp of the last start are visible. For longer history, `journalctl -u fivem.service --since yesterday | grep 'Started\|Stopped'` shows every boot cycle from the previous day.

What do I do if the server falls into a restart loop and pegs the CPU?

Add `StartLimitBurst=5` and `StartLimitIntervalSec=300` to the `[Unit]` section. This makes systemd stop trying to restart after 5 failures in 5 minutes, avoiding 100% CPU consumption in a loop. Investigate the cause through `journalctl -u fivem.service -n 200` before removing the limit.

Topics:

fivem

Next steps VPS, dedicated or managed panel for FiveM, SAMP, MTA, Tibia and more.Host your game server with Hostini →

Was this tutorial helpful?