MTA Roleplay Server Setup Guide: Step by Step From Scratch

Setting up an MTA Roleplay server is a considerably heavier technical job than launching a plain freeroam server. Player data is persistent: characters, inventories, vehicles, houses and bank accounts all live in a database, so almost every player action has a query behind it — and one badly written query can bring a 60-player server to its knees. This guide walks through standing up an MTA:SA roleplay server from scratch, from hardware planning to a pre-launch checklist.

What Is an MTA Roleplay Server and How Does It Differ?

On a classic MTA server, a player connects, plays, leaves, and nothing remains. On a roleplay server the player creates a character, and that character persists. The technical consequences are significant:

• A persistent data layer: MySQL or MariaDB becomes mandatory. Character, inventory, vehicle, property, job, banking and log tables are read and written continuously.
• Long sessions: Roleplay players stay connected far longer than deathmatch players. Memory leaks and ever-growing tables surface mercilessly under these conditions.
• Far more elements: Vehicles scattered across the map, interiors, pickups, markers, blips and NPC-like structures. The more elements exist, the heavier every server tick becomes.
• A permission hierarchy: Admins, moderators, support staff, developers and players all need different command sets, which makes ACL configuration a real piece of work.

In short, a roleplay server behaves less like a game server and more like an application server.

Before You Start: Infrastructure Planning

Choosing the right foundation before touching any code eliminates the most expensive problems in advance.

CPU: single-core strength, not core count

The MTA server process runs its main game loop largely on a single core. A modern CPU with strong single-core performance will always beat a weak 16-core chip for this workload. Our AMD Ryzen 9 9950X based Turkey VDS plans fit this scenario precisely: high single-core performance, DDR5 memory and NVMe M2 storage.

Memory

Roleplay gamemodes consume noticeably more memory than freeroam scripts. Plan generously: the server process plus the database should not consume more than half of physical memory, leaving the rest as buffers and disk cache.

Storage

Because the workload is database heavy, disk type translates directly into in-game latency. NVMe M2 SSDs deliver far higher IOPS than SATA SSDs on random reads and writes, which is what makes saving a character feel instant.

Location

If your player base is in Turkey, your server should be in Turkey. Vehicle synchronisation and combat moments in roleplay scenarios are extremely sensitive to ping; an extra 60-90 ms from an overseas location visibly degrades the experience. An Istanbul location gives the lowest latency for Turkish players.

Step 1: Prepare the Server

Once your VDS is delivered, the first task is not installing the game but securing the system. We covered the baseline steps for a fresh server in a separate article: First 10 Steps to Secure Your Server. In short: update system packages, never run the game server as root, create a dedicated user for it, and open only the necessary ports in the firewall.

MTA uses these ports:

• 22003/UDP — the main game port. Players connect here.
• 22005/TCP — the HTTP resource download port, where clients pull scripts and files.
• 22126/UDP — the server browser (ASE) port, required for your server to appear in the list.

If any of these three are blocked, the server either never appears in the browser or players get stuck on the download screen while connecting.

Step 2: Install the MTA Server Software

On Linux, download the official 64-bit server package, extract it into a dedicated directory and run the mta-server64 binary. On Windows, the server ships with an installer and is started through MTA Server.exe.

On first run the server generates its configuration files under mods/deathmatch. The two most critical ones are:

• mtaserver.conf — server name, ports, maximum players, resources loaded at startup, anti-cheat settings.
• acl.xml — permission groups and which group may run which command.

Start the server in the foreground console the first time rather than as a background service. A missing resource or a malformed meta file will show up in the console immediately.

Step 3: Choose Your Roleplay Gamemode

This decision shapes the entire project. There are three routes:

1. Use an open-source roleplay base. The fastest start, with character, inventory, vehicle and job modules already built. The downside is legacy code nobody fully understands.
2. Build on top of an existing base. The most common route in practice: inherit the core systems and write the modules that give your server its identity yourself.
3. Write everything from scratch. Full control, but months of work. Do not take this path without an experienced Lua developer.

Whichever route you take, check the licence of every resource and never load third-party scripts you have not read — a gamemode from an unclear source can carry a backdoor onto your server.

Step 4: Set Up and Connect the Database

Install MySQL or MariaDB, create a dedicated database for the server, and create a separate user with privileges on that database only. Having the game server connect as the root database user is an unnecessary and substantial risk.

On the Lua side, the connection is established with dbConnect and queries run asynchronously through dbQuery. Three rules determine performance on roleplay servers:

• Run queries asynchronously. A synchronous query halts the entire server until it returns. That is exactly why everyone freezes when one player opens an inventory.
• Never embed user input directly into a query. Always escape variables or use parameterised queries. SQL injection remains one of the most common ways MTA servers get compromised.
• Add indexes. If constantly filtered columns such as character ID, account ID or vehicle owner are not indexed, the server slows down as tables grow. This problem is invisible in week one and painful in month three.

Also configure automated database backups on day one. On a roleplay server, data loss means player loss; deleting a character somebody spent months building creates a trust deficit you rarely recover from.

Step 5: mtaserver.conf and acl.xml

Fields worth your attention in mtaserver.conf:

• servername — the name shown in the server browser. Keep it short and searchable.
• maxplayers — set what your hardware can genuinely handle. Advertising 200 slots on an empty server impresses nobody; buckling under 200 players on a full one is fatal.
• fpslimit — the server-side tick limit. Raising it makes gameplay smoother but costs CPU. Do not raise it without measuring your hardware first.
• ac / enablesd — MTA's built-in anti-cheat modules. There is no valid reason to disable these on a roleplay server.
• httpdownloadurl — used when you want to serve resources from an external web server. On large roleplay gamemodes it noticeably shortens first-connection time.

The golden rule for acl.xml: never grant anyone more permission than they need. Moderators should not be able to restart resources, and support staff should have no access to commands that touch the database. Keeping permissions narrow from the beginning prevents most future internal incidents.

Step 6: Performance Optimisation

Performance problems on roleplay servers almost always come from the same three places:

• Perpetual timers. A timer running once per second per player means 100 jobs per second at 100 players. Move to event-driven structures wherever possible.
• Unnecessary element traffic. Scripts that constantly push data from server to client eat both bandwidth and tick time. Send data in batches and only when it actually changes.
• Heavy queries. Instead of querying ten tables at once when a player logs in, load data at the moment it is needed.

You can review our game server plans for hardware suited to this workload.

Step 7: Security and DDoS Protection

As a roleplay server's player base grows, it becomes a target for competing servers. Because MTA game traffic runs over UDP, conventional web-based protection does not help here — we examined this in detail in Does Cloudflare protect game servers. What you need is a DDoS-protected network that understands game traffic. Nubitro's MTA server plans run on DDoS-protected network infrastructure.

On the software side: switch SSH to key-based authentication, close the database to the outside world, enable two-factor authentication on staff accounts, and keep logs.

Pre-Launch Checklist

1. Are all three ports reachable from outside?
2. Does the server appear in the server browser list?
3. Can a brand new account register and create a character?
4. Is character data saved on disconnect and restored correctly on the next login?
5. Do automated database backups run, and has a restore actually been tested?
6. Have ACL groups been tested — can a moderator account run an admin command?
7. Are there recurring errors or warnings in the console?
8. In a closed test with 20-30 players, do tick time and memory usage stay stable?

Do not announce the server until every item is green. First impressions happen once, and a roleplay server that collapses on launch day rarely gets its players back.

Frequently Asked Questions

Is a shared game panel enough for a roleplay server?

It may be adequate for a small test server, but not for a serious project. Roleplay gamemodes need their own database service and tooling that requires root-level access, which a VDS provides.

How much resource do I need per player?

Any precise table would be misleading: the deciding factor is not player count but how well the gamemode is written. A poor script struggles at 40 players while a well-optimised base carries far more on identical hardware. Run closed tests and measure your own script.

Should I choose Windows or Linux?

Linux offers lower overhead and better resource management for long-running game servers, and is the recommended choice for production. Windows is easier to start with if you are unfamiliar with the command line and prefer a graphical interface.

I have never set up an MTA server before — what should I learn first?

Learn to install and run a basic MTA server before moving to roleplay. Our step-by-step MTA:SA server setup guide covers this. Jumping into a roleplay base without understanding the fundamentals makes debugging far harder.

Summary

Setting up an MTA Roleplay server is manageable when approached in the right order. Start with strong single-core performance, NVMe storage and a location close to your players. Secure the system, open the three ports, and confirm a clean console start. Connect the database with a limited-privilege user, write asynchronous and parameterised queries, and add indexes from day one. Keep ACL narrow, leave anti-cheat enabled, run on a DDoS-protected network, and clear the full checklist before going live.

If you are looking for the right infrastructure for your MTA Roleplay project, take a look at our MTA server plans and our high single-core performance Turkey-located VDS options. If you are unsure which configuration suits your project, get in touch with us — our support team is available 24/7 for setup and migration.