How to Create an OGame Server? The Complete Guide

To create an OGame server, one of the most actively updated open-source projects is OGameX, a fan clone written with Laravel and distributed under the MIT license. It installs with Docker in a few commands, but it isn't an official server: the OGame name, the interface and the artwork remain the property of Gameforge. This tutorial details production installation, administration and updating, and ranks the old abandoned engines.

Key takeaways

• OGameX is the engine we chose: it is under the MIT license, runs with Docker and reproduces OGame as it was before Lifeforms (2022).
• The first start can take up to 10 minutes, while dependencies initialize and the combat engine compiles.
• The first account created becomes administrator, and the production configuration requires security settings before opening to the public.
• XNova, 2Moons, XG Proyect 3 and other engines are archived, inactive or stuck on old PHP versions: avoid them for a new server.

Which engine to choose in 2026?

Here are the main open-source OGame engines listed on GitHub as of October 10, 2026. The dates are those displayed by GitHub for the repository's last update: they give a trend, not a commit history.

Our take: for a server you want to open in 2026, OGameX is the safest choice: its code is updated regularly (October 5, 2026 according to GitHub), its tests run on every build and it installs with Docker. If you prefer the pre-redesign OGame, ogame-opensource (version 0.84, old design) is an alternative that is still active, but its maintainers report ongoing refactoring with possible bugs.

Prerequisites

For OGameX, the method recommended by the project is Docker, which installs all the dependencies. You need:

• a Linux server, with Git, Docker and Docker Compose installed (the README steps are written for Linux and may differ on Windows);
• ports 80 and 443 free, or the ability to change them in the Docker Compose file;
• PHP ^8.5 if you give up Docker and install by hand: that is OGameX's requirement, whereas Laravel 13 requires at least PHP 8.3.

A domain name pointing to the server is recommended to host players. The README doesn't quantify the minimum hardware configuration: test with the number of players you're aiming for before opening.

Installing OGameX in production

The repository offers a development Docker Compose file and a production one. For a public server, use the production one. The project warns that it isn't fully optimized yet: review all the settings before exposing it.

1. Clone the repository:

   git clone https://github.com/lanedirt/OGameX.git
   cd OGameX

2. Copy the production configuration file:

   cp .env.example-prod .env

3. Edit the .env and docker-compose.prod.yml files before the first launch (see the next section).
4. Start the containers:

   docker compose -f docker-compose.prod.yml up -d --build --force-recreate

5. Be patient: the ogamex-app container can take up to 10 minutes to start, because of Composer initialization and the compilation of the Rust engine on first launch.
6. Open your server's address over HTTPS and create an account. The first account created automatically receives the administrator role: create it yourself before announcing the address.

Securing before opening

The .env.example-prod file contains default values meant for a test, not a public server. Check at least these points:

• Database password: the README asks you to replace the default root password with a unique value. It is hardcoded in docker-compose.prod.yml (MYSQL_ROOT_PASSWORD: toor) and the .env file contains DB_PASSWORD=toor. Replace both with the same value before the first launch.
• Site address: the APP_URL variable is http://localhost by default. Replace it with your server's real address.
• HTTPS: in production, the site forces HTTPS with a self-signed certificate, which triggers a warning in browsers. The README doesn't detail replacing the certificate: plan for a valid certificate before hosting players. For a test over HTTP, switch APP_ENV from production to local, but don't do it on a public server.
• phpMyAdmin: it is bound to port 8080. In production, access requires declaring your IP addresses in ./docker/phpmyadmin/.htaccess.
• Emails: the file contains MAIL_* variables set to a test service. According to the pull request list we consulted (state as of July 2026), the addition of password reset by email (SMTP) was still in progress: test this feature before opening registrations.
• Ports: HTTP_PORT, HTTPS_PORT and PHPMYADMIN_PORT (to uncomment in .env) change the exposed ports. The WebSocket server also publishes port 8090 (REVERB_SERVER_PORT). The database is not exposed in production.

Administering the server

The administrator role gives access to the admin bar and the server settings. To assign or remove it for another player, run the command in the application container:

docker compose -f docker-compose.prod.yml exec ogamex-app php artisan ogamex:admin:assign-role player_name
docker compose -f docker-compose.prod.yml exec ogamex-app php artisan ogamex:admin:remove-role player_name

The project states that other administration and server management tools are in preparation: check your version's panel to see which settings are actually available.

Updating OGameX

First back up the database and your files. You have modified docker-compose.prod.yml: set those changes aside with git stash before switching versions, then reapply them with git stash pop. The README then describes three steps:

1. Stop the containers:

   docker compose -f docker-compose.prod.yml down

2. Get the new version, either the main branch or a specific stable version:

   git pull origin main
   git checkout 0.14.0

   Use one or the other, and replace 0.14.0 with the latest published version.
3. Rebuild and restart:

   docker compose -f docker-compose.prod.yml up -d --build --force-recreate --remove-orphans

On startup, the container's entry script applies the database migrations and refreshes the cache, which can take a moment. If you run into trouble, check the logs or open a ticket on the project's issues page.

Abandoned or obsolete engines

These projects powered generations of private servers, but they're no longer suitable for a new installation:

• XNova (French fork): repository archived and read-only since January 29, 2023.
• 2Moons: repository archived since November 24, 2021. Its README states it is no longer under active development and points to SteemNova.
• SteemNova: a fork of 2Moons, whose README still describes an installation with PHP 7.3, a version that is no longer supported. We couldn't verify its latest activity.
• UniEngine: requires PHP 7.0 to 7.2, versions that are no longer supported (php.net now only lists the 8.2 to 8.5 branches), and its last noted activity dates from November 2025.
• Dark-Nova: a server written in TypeScript for Node.js, last activity noted in January 2023.
• XG Proyect 3.x: repository archived on May 30, 2026, with PHP 7.4 minimum. Its README recommends XG Proyect 4, based on Laravel (PHP 8.2 minimum, GPL-3.0 license), for new installations.

If you prefer the pre-redesign OGame, look at ogame-opensource, which provides classic and Docker installation guides. For a Java stack, retro-game was updated in 2026, but its README specifies that its Docker setup isn't production-ready.

Opening your server to players

An empty universe doesn't start on its own. Before announcing the address, create your administrator account and test a full registration, a construction, a fleet dispatch and a battle on a second account.

Our advice:

• Test locally first: docker compose up -d, without the production file, starts a development version at http://localhost (allow up to 10 minutes the first time). On Windows, the README recommends production mode instead, because development mode is slow there.
• Back up the database before each update, and only use the main branch for testing: for a server open to players, pin a stable version.
• Test the emails, the HTTPS certificate and phpMyAdmin access before the first announcement.
• State clearly that your universe is a fan clone, independent from Gameforge.

Is your server ready? List it on Private Server to introduce it to a new community, or browse the ranking of OGame servers.

Frequently Asked Questions

Can you create an official OGame server?

No. Official universes are run by Gameforge, which holds the rights to OGame. An engine like OGameX lets you create a private server, that is, an independent fan clone. The project in fact encourages its users to try the official version at ogame.org.

Is OGameX free?

Yes, its code is under the MIT license. The only costs are those of hosting and the domain name. The project specifies that it contains no commercial features.

What configuration do you need to host OGameX?

The README gives no minimum configuration. It asks for Docker (recommended) or PHP ^8.5 for a manual installation, whereas Laravel 13 requires at least PHP 8.3. The first start compiles a combat engine in Rust, which takes up to 10 minutes: test with the expected number of players before opening.

Can you sell dark matter on your server?

The project presents itself as non-commercial. The dark matter features already built in (merchant, planet relocation) are versions without purchase, and the other announced features will be too. The rights to OGame belong to Gameforge: get advice from a lawyer before any monetization.

OGameX or ogame-opensource?

OGameX is written with Laravel, uses a combat engine in Rust and deploys with Docker. ogame-opensource recreates OGame 0.84 with the old design, and its maintainers report ongoing refactoring with possible bugs. Choose OGameX for a game close to the pre-Lifeforms OGame, and ogame-opensource if you want the old interface.

How do you update OGameX without breaking your server?

Back up the database and files, stop the containers, get the new version with Git, then rebuild the containers. On startup, the entry script automatically applies the database migrations. Prefer a stable version over the main branch for a server open to the public.