Metin2 Server Hosting

What does renting a Metin2 server mean?

Renting a Metin2 server means getting the processing power, memory, storage and network protection needed to launch your own private Metin2 project (commonly called a “PvP server” in Türkiye) from a hosting provider. You rent the infrastructure the game runs on, not the game itself: the server files, database, client and website are prepared by the project owner.

Türkiye is one of the countries with the highest concentration of private Metin2 projects. These projects usually focus on a particular era of the game (“oldschool” servers that preserve the classic experience, or “middle-school” and “newschool” servers with added systems) and aim to welcome hundreds or even thousands of players at once on launch day. That load is far too high to run on a home computer or in a shared environment.

The right infrastructure for a Metin2 project must provide three things at once: dedicated CPU and memory so the game cores run without interruption, fast storage that can carry the database write load, and network-level filtering against DDoS attacks that may come from rival projects. That infrastructure is exactly what LIONFIN provides; sourcing the game files, their licensing status and content management are the project owner's responsibility.

How does the Metin2 server architecture work?

A Metin2 server is not a single program but several processes working together: a db process that talks to the database, an auth core that verifies player logins, and multiple game cores that run the maps channel by channel. Each core runs in its own folder with its own CONFIG file.

• db: acts as an intermediary and cache between the game cores and MySQL/MariaDB. It keeps player data in memory and writes it to the database at set intervals, which is why an improper shutdown of the db process can lead to data loss.
• auth: the core the client connects to first; it verifies the account and password, then routes the player to the chosen channel.
• Game cores: each channel is usually split across several cores, and each core runs specific maps. The number of channels and the map distribution directly determine the server's CPU and memory plan.
• Database: usually consists of the account (accounts), player (characters, items), common (shared settings, banned words) and log (logs) schemas.

On the client side, the server address and ports are defined in files such as the client's serverinfo.py; they must match the port values on the server exactly. This architecture also explains why Metin2's resource needs depend on the number of channels and cores as well as on player count.

Which operating system does a Metin2 server run on?

Most Metin2 server files are compiled for FreeBSD, so the classic infrastructure for Metin2 projects is a server running FreeBSD. Old file sets may depend on older FreeBSD releases and 32-bit libraries, while up-to-date sets recompiled from source can run on newer FreeBSD versions.

Things to consider when choosing the operating system:

1. Target system of the file set: find out which FreeBSD version and architecture (32/64-bit) your compiled cores were built for. On an incompatible system, the cores fail to start with library errors.
2. Source code access: projects that have the source code can recompile the cores for the target server's system. This is also a major advantage for applying security patches and debugging.
3. Database version: old sets were written around the behaviour of specific MySQL versions. On MariaDB or newer MySQL versions, strict SQL mode can cause query errors; you may need to configure sql_mode to match the set's expectations.

A VDS server uses KVM virtualisation, so it is suitable for installing different operating systems. If you do not see the FreeBSD version you need in the operating system list, you can open a ticket from the Support section of the customer panel before or after ordering to ask about installation options.

How much RAM and CPU does a Metin2 server need?

The resource needs of a Metin2 server depend on concurrent player count, the number of channels and cores, the complexity of added systems (bonus switching, alchemy, pets, war systems and so on) and database load. The table above gives estimates that also account for launch-day load; load observations during a closed beta show the real requirement best.

Keep these points in mind when planning:

• Launch-day effect: in Metin2 projects, player numbers on the first day and in the first week can be several times those of later weeks. Plan resources for the peak, not the average; scaling down later is better than crashing at launch.
• Load per core: spreading busy maps (starting villages, popular grinding spots) across separate cores balances CPU load.
• Database: as player numbers grow, write load on the player and log schemas increases. Fast NVMe storage and enough memory for the database reduce latency.
• Separate database server: on large projects, moving MySQL/MariaDB to a separate server improves both performance and security.

Dedicated cores give more predictable results than shared resources for applications under constant load like Metin2. For very large projects, a dedicated server that reserves all of the hardware is also worth considering.

Ready-made package, VDS or dedicated server for Metin2?

Metin2 uses a VDS or dedicated server with reserved resources rather than a ready-made game panel package, because a Metin2 server is a multi-process system that requires OS-level configuration and full administrator access. The package table on this page shows the current VDS options suitable for Metin2 projects live.

The biggest advantage of a VDS for Metin2 projects is flexibility: you can add resources as the project grows, open a second VDS for testing, and review your plan once post-launch traffic settles down. You manage the server yourself; the operating system, database and firewall settings are under your control. For a general comparison, see the game server package or VDS page.

How do you set up ports and the firewall on a Metin2 server?

The ports used on a Metin2 server are not fixed; in every file set, the auth core port, the channel core ports and the inter-core communication ports are defined separately in the CONFIG files. That is why giving a single value as “the Metin2 port” is wrong; you should go by the values in your own set.

The basic principle when setting up a firewall is this: open to the outside only the ports players need to connect to, and close everything else.

• Must be open to the outside: the auth port and the channel ports players connect to.
• Must be closed to the outside: the db process port, the inter-core (P2P) communication ports and the MySQL/MariaDB port (3306). Only the server itself or the separate database server should reach these ports.
• Management access: open the SSH port only to your own IP address and log in with a key instead of a password.

On FreeBSD, the firewall is usually configured with pf; setting a per-IP connection limit is one of the most effective ways to mitigate connection flood attacks. After every change, check that the port values in the client match those on the server.

How do you protect a Metin2 server against DDoS attacks?

Because of fierce competition between rival servers, Metin2 projects are among the game servers most often targeted by DDoS attacks; launch days and big events in particular carry the highest risk. Effective protection starts with filtering attack traffic at the network level before it reaches the server.

On LIONFIN infrastructure, the RouteFence firewall filters volumetric attacks at the network level; 600 Gbit/s of total upstream capacity and 24/7 NOC and SOC monitoring in our data center are the foundation of this protection. However, with TCP-based games like Metin2, attacks are not only volumetric; connection floods that imitate the game protocol also occur. So you need to take measures on the server side too:

1. Per-IP connection limit: limit the number of concurrent connections a single IP address can open in the firewall.
2. Core-side checks: if you have the source code, add timeouts and packet validation at the handshake stage.
3. Separate the website: host the registration and news site on infrastructure separate from the game server, so the site's IP does not reveal the game server.
4. Separate patch distribution: distribute client patches (the patcher) from a separate server or a CDN, not from the game server.

What should you do about cheats and vulnerabilities on a Metin2 server?

Cheat prevention on Metin2 servers works on two layers: client-side protections that detect cheat programs, and server-side checks that verify whether every packet a player sends makes sense. Client-side protection alone is not enough, because the client always sits on the player's computer and can be bypassed.

Server-side checks you should prioritise include:

• Speed and position validation: block speed and teleport hacks by checking the distance a player can cover between two packets.
• Attack speed and range checks: validate the frequency of hit packets and the distance to the target.
• Item and trade checks: item duplication (dupe) exploits usually appear in trade, storage and market systems. Make transactions in these systems atomic and keep logs.
• Database security: use parameterised queries for registration and item-shop operations on the website; SQL injection is among the most exploited vulnerabilities in Metin2 projects.
• Admin accounts: limit GM rights to as few accounts as possible and log GM actions.

For overall server security, keeping the operating system and database up to date, disabling unnecessary services and allowing only key-based SSH access are the basic steps.

How do you manage and back up a Metin2 database?

The most valuable asset of a Metin2 project is its database: accounts, characters, items and everything players have worked on for months are stored in the account and player schemas. Backing up the database regularly and copying the backup off the server prevents the worst disaster that can happen to a project.

1. Take consistent backups: because the db process keeps data in memory and writes it at intervals, the safest backup is taken during maintenance after the db process has been shut down cleanly. For live backups, use mysqldump with the --single-transaction option on InnoDB tables.
2. Move backups off the server: a backup on the same server offers no protection against disk failure or attacker access. Keep a copy in a different location.
3. Manage the log schema: the log schema grows fast. Regularly archiving and deleting old records eases both disk usage and backup time.
4. Test restores: you only know a backup works by restoring it. Run periodic restores on a test server.

Whether the database is MySQL or MariaDB does not change the management logic; however, because of version differences, restoring the backup on the same version is the smoothest route.

How do you monitor and improve Metin2 server performance?

Performance on a Metin2 server is managed by monitoring the CPU usage of the cores, the speed at which the db process writes to the database, and the stability of the network connection. Finding out which layer the problem players describe as “lag” comes from is the first step towards the right fix.

• Per-core monitoring: on FreeBSD, the top command shows which game core is using a lot of CPU. If a single core is constantly struggling, its maps need to be split up.
• Database latency: enable the slow query log to find long-running queries; missing indexes cause slowness especially in item and market tables.
• Memory: the db process and cores increase memory usage with player count. A Metin2 server that falls into swap slows down noticeably.
• Disk: heavy writes to the log schema and frequent backups can increase disk latency; NVMe storage reduces this effect.

Restarting the server before events and launch times clears memory build-up. Distinguish player-side network latency from server load before changing anything. For projects aimed at players in Türkiye, a server located in Türkiye is a natural advantage for keeping ping low.

Why should test and live environments be separated in a Metin2 project?

Separating the test and live environments in Metin2 projects is the only safe way to try new systems, patches and events without harming players. A code or database change made directly on the live server can lead to results that are hard to undo, such as an item duplication exploit or loss of character data.

A practical setup looks like this:

1. Separate test server: a small VDS with the same operating system and database version as the live server is enough for testing.
2. Anonymised data: if testing needs real player data, take a copy of the live database and clear personal fields such as email addresses and passwords.
3. Version tracking: keep the core code and client files in a version control system (for example Git), so what each patch changed is on record.
4. Rollback plan: take a database backup right before every update goes live, and decide in advance how you will return to the previous version if something goes wrong.

This setup may look like an extra cost at first, but in a large project a single faulty patch that drives players away costs far more.

What are the most common Metin2 server errors?

The most common problems on Metin2 servers are cores that will not start, clients unable to connect to the server, database connection errors and unexpected core crashes. Each core produces syslog and syserr files in its own folder; reading them is the first step of diagnosis.

For infrastructure issues (network, disk, access to the virtual server), you can open a ticket from the Support section of the customer panel; the content and code of the game files remain the project owner's responsibility.