How to set up a Silkroad Online server: a step-by-step guide

This guide sets up the structure of a Silkroad Online private server: choosing the operating system and database, the order in which the processes start, opening ports and the mistakes most often made on first boot. The one thing we deliberately leave out is distribution-specific commands. There is no official distribution of Silkroad server files, and the file names, folder layout and configuration keys of the package in your hands may differ from the next one. So what follows is the skeleton that stays the same across every distribution; the correct commands are always in your own package's documentation.

Before you start

• A Windows-based server. The gateway, agent and shard processes are compiled for Windows, and the database layer is Microsoft SQL Server. This decision cannot be changed later; you need to select a Windows template when ordering.
• A resource plan. For a single shard with up to 250 players, 8 GB / 4 vCPU / 100 GB is the practical starting point. With active trade and unique events, the 250-700 player range needs 16 GB / 8 vCPU. Know from the start that this calculation cannot be made around a single game process: the budget has to cover gateway, agent, download and MSSQL together.
• The server files. They are obtained independently of the game; the hosting provider supplies hardware and the operating system, and you manage the server software.
• RDP access. All administration happens over remote desktop: connecting to a Windows server over RDP

1. Operating system

Install from a Windows Server template. Here the operating system is a requirement rather than a preference, but it still helps to know what you are getting: the Windows baseline alone holds 2-3 GB of memory, which directly reduces what is left for the game processes. We have covered how a Windows VDS is managed and how the licensing side works on a separate page: Windows server

If you want to see the cost and administration difference between the two sides: Windows VDS or Linux VDS, which one is a better fit?

2. Installing MSSQL and restoring the databases

Microsoft SQL Server is installed before the server processes, and your package's database backups are restored into it. Check the edition limits here rather than later: the Express edition is capped at roughly 1410 MB of buffer pool per instance and 10 GB per database. That ceiling goes unnoticed on a freshly opened server and announces itself as the character and inventory tables grow — first as query latency, then as write failures.

The weight of memory planning on Silkroad sits in the database: the buffer pool can hold 4-12 GB depending on database size. Create a separate MSSQL login for the server processes and write that into the configuration files; using the system administrator account directly means that password travels around with your server files.

3. Configuring the processes and the start order

Silkroad's architecture is layered and each layer has its own configuration file. GatewayServer handles the client's first connection and the server list, AgentServer takes over the session and runs game traffic, DownloadServer distributes client updates, and shard processes run the world.

The most critical and most frequently skipped step in this setup is the IP values. The gateway tells the client the address of the agent server; if that address is left as a local IP in the configuration, the client makes the first connection and sees the server list but cannot enter the game. Make sure the server's real public IP is written in every configuration file. The same address is needed on the client side too: if the server address and port inside the client package your players use do not point at your server, no amount of server-side configuration will help.

Start the processes in order: MSSQL first, then GatewayServer, then AgentServer and the shard processes. When the order is wrong the error messages are misleading — the process that "cannot connect" is actually waiting on a layer that should have come up before it.

4. Ports

Opening the MSSQL port to the outside means putting your database on the internet, and in this game the data lost is player characters. If you will distribute client updates, plan separate bandwidth for DownloadServer: on update days egress traffic spikes briefly but sharply. If you are on Datafex, port management and extra IP requests are handled from the customer panel.

The most common first-boot mistakes

1. A local IP left in the configuration. Players see the server list and cannot enter the game. This is the source of most connection problems.
2. Processes started in the wrong order. An agent brought up before MSSQL or the gateway is ready throws errors that make no sense.
3. The MSSQL edition limit noticed too late. Once the database hits the cap, the migration has to happen on a live server.
4. Port 1433 exposed. That one-line mistake is the whole server.
5. Peak event load not accounted for. Trade and war events produce load well above the average, and a plan sized for the average stutters exactly when the server is busiest.
6. The database is not backed up. All character progress lives in MSSQL: server backup strategy

On the DDoS side

Competition in the private server ecosystem is sharp, so Silkroad servers are targeted around launches and event hours. The gateway port is the first door open to the outside and most attacks concentrate there. Filtering has to happen at the network layer; limiting connection counts at the application layer is not enough on its own: what is DDoS protection?

On Datafex servers, layered Fexwall DDoS protection is included free on every plan.

Next step

In multi-shard setups above 700 players the most effective step is not a bigger single machine but splitting MSSQL and `DownloadServer` off; at that point a dedicated server gives a better baseline for both memory and storage. We have put the recommended configurations by player count and the processor options on one page: Silkroad server plans.