How to Set Up a DarkOrbit Server

DarkOrbit has no official dedicated server, so a “DarkOrbit server” always means a community-built emulator — an independent reimplementation of the game server that your pilots reach through a browser. Nobody can sell you one ready to play. What you can rent is the machine it runs on. This guide explains what an emulator needs, how to get yours running, and exactly where our job ends and yours begins.

What you are actually setting up

The official game is closed source and hosted by Bigpoint. Private servers exist because people have rebuilt the server side from scratch, usually in Java or PHP, and paired it with a MySQL database and a copy of the browser client. A working setup has four parts:

• The emulator build — the server application itself. You choose and supply this.
• A database — MySQL or MariaDB, holding accounts, ships, maps and your economy.
• The client assets — what the browser loads when a pilot opens your address.
• A machine to run all three on — that part is what you are buying from us.

What we provide, and what you bring

Being blunt about this up front saves everyone a support ticket:

We provide: a Linux container with guaranteed RAM and vCPU, the control panel (live console, file manager, FTP/SFTP, scheduled restarts and automatic backups), a MySQL database, a DDoS-filtered network address, and support for anything to do with the box itself.

You provide: the emulator build and its configuration. We do not ship an emulator, we do not build one for you, and we cannot debug someone else's reimplementation of a game. The work itself is short: upload the build, point it at the database, start it from the console — a minute or so once you have the files ready.

Before you start

• An emulator project you have already chosen. These projects appear and go quiet often. Pick one that still gets commits and has a community you can ask questions in.
• Its own documentation. Ports, config file names and database schema differ between builds, and the project's README beats any generic guide — including this one.
• Some comfort with Java or PHP, depending on which build you picked.
• 2 GB of RAM for a test galaxy you and a few friends poke at; 4–6 GB once real pilots are online.

Step 1 — Size the plan

RAM is the figure that matters. An emulator idles small but grows with concurrent pilots, active maps and whatever your database is doing. Start on Starter if you are testing, and move up once you can see real numbers in the panel's CPU and memory graphs. Upgrading keeps your files.

Step 2 — Upload the emulator

Your files live in /home/container. Drag the build in through the panel's file manager for anything small, or connect over SFTP with the credentials on your service page for a full build. Keep the directory layout the project expects — most emulators are unforgiving about paths.

Step 3 — Create the database and import the schema

Create a MySQL database from the panel's Databases tab, then import the .sql schema your emulator ships. Put the resulting host, database name, user and password into the emulator's config file. A wrong password here is the single most common reason a build starts and immediately dies, so check the console output before assuming anything else is broken.

Step 4 — Open the ports your build needs

Emulators typically want more than one port: a socket port for the game itself, and an HTTP port serving the client. Your service comes with a primary port allocation. If your build needs extra ones, open a ticket and tell us which ports the project documents — we will add the allocations.

Step 5 — Point the client at your server

Configure the client assets with your server's address, then start the server from the panel console and watch it boot. Your pilots join by opening that address in a browser. There is no server list and no “add server” screen in the official game — a private emulator is reached directly.

Step 6 — Keep it running

Once it works, make it boring: schedule a nightly restart, turn on automatic backups so a bad database migration is not the end of your galaxy, and keep an eye on the console after any change. The panel does all three without SSH.

One thing to settle before you go public

DarkOrbit is Bigpoint's intellectual property. Emulators are unofficial fan projects, some of them bundle assets nobody has a licence to redistribute, and a public private server can attract a takedown. That decision is yours to make and yours to own — we host the machine, not the project. Our acceptable use policy applies either way.

Recommended specs

DarkOrbit server FAQ