OP

OpenRA

Open-source remake of classic RTS games

Game Engines & Frameworks ★ 17.4k stars Medium setup GPL-3.0

OpenRA is a free, open-source game engine that reimagines classic Command & Conquer real-time strategy titles. It includes dedicated server support for hosting modern multiplayer matches.

Key features

  • Classic C&C-style RTS
  • Dedicated server support
  • Modernized gameplay and UI
  • Mod and map support

Pros & cons

Strengths

  • Faithful yet modernized RTS
  • Active multiplayer scene

Trade-offs

  • Requires original game assets
  • Server config is text-based

OpenRA replaces

Last reviewed Aug 26, 2026 · 790 words

An OpenRA dedicated server is fussy about exactly one thing: version. A server on one release and a client on another cannot see each other, and neither side tells you why in a way that a friend joining from a different install will understand. Get that right, keep it right, and the rest of hosting Red Alert or Tiberian Dawn matches for 8 people on a 512 MB container is a single script with a handful of settings.

Version lockstep is the whole job

OpenRA publishes numbered releases, and between them, playtests. Multiplayer requires every client and the server to run the identical build. When a new release lands, players' clients update on their own schedule and your server does not, so the first symptom is "the server disappeared" reported by whoever updated first. The fix is boring: pin a release tag, tell your group which one, and upgrade the server the same evening a release ships. Docker images are the sane way to do this because the tag is the version; use a community image or build from the release archive, and never run from a moving latest for a server other people depend on.

What the original games contribute

The engine is GPL-3.0 and free. The game content, the sprites, sounds and music, is not part of it. For Red Alert and Tiberian Dawn the original assets were released as freeware by the rights holder years ago, and the OpenRA client offers to download them on first launch, so players need nothing but the installer. Dune 2000 requires the original game files. The dedicated server itself needs maps and rules, which ship with the release, and it does not render anything, so the 512 MB figure is honest for a small lobby. Server operators sometimes install the assets anyway to test locally; players always need them on the client.

The launch script and the 6 settings that matter

The dedicated server is started with launch-dedicated.sh from the release, and it reads its options from environment variables or command-line flags. The ones that matter:

Name="Thursday Night RA" \
Mod=ra \
ListenPort=1234 \
AdvertiseOnline=False \
Password=our-lan-password \
RecordReplays=True \
./launch-dedicated.sh

Mod is ra, cnc or d2k. AdvertiseOnline=True registers the server with the public master list so strangers can find it; leave it False for a private group, or you will spend the evening kicking people. Password protects the lobby. RecordReplays writes every match to disk, which is worth the space for a group that likes to argue about who lost. Additional settings cover requiring a forum authentication for players and restricting single-player lobbies; leave those alone until a problem prompts them.

Port 1234 and the two ways to reach it

The server listens on TCP 1234 by default. If you forward that port on your router and set AdvertiseOnline=True, the server appears in every client's public browser, which is what a public server wants and a private one does not. For a group of friends, the better pattern is to forward nothing: put the server on a Tailscale network, invite each player, and have them connect directly to the server's tailnet address on 1234. Latency over a mesh VPN is fine for an RTS, no port is exposed, and the "who is this stranger in our lobby" problem never arises. The remote access piece weighs that pattern against the alternatives for other services.

Hosting it like any other game server

Treat it as one more service in the compose file: a named volume for ~/.config/openra (maps, replays, settings), a restart policy, and a log you can read. Multiple servers on different ports and mods run happily on one box for different game nights. If you already host other games through a panel such as Pterodactyl, OpenRA fits as a custom egg or a plain container beside it; a panel is overkill for one server but pays off at 3 or 4. The compose patterns that keep a homelab tidy apply unchanged.

What I'd do

One container per mod, pinned to the current release tag, AdvertiseOnline=False, a password, replays on, reachable only over Tailscale. Put a note in the group chat with the exact release name and update the server the day a new one ships. That setup has no exposed ports, costs under 512 MB per lobby, and turns the only real failure mode, version drift, into a 5-minute chore you control instead of a mystery your friends report. Other engines in the games category need more hardware; this one needs discipline about a tag.

Similar game engines & frameworks apps