Managing rFactor 2 with APX

Somehow I spent "some" time developing an automation tool.

Managing rFactor 2 with APX

What the f*ck?

APX is a orchestrator (resulted out of a proof-of-concept), allowing league organisators to automate servers. As APX is following the concept of a non-invasive tool, there is no binary-patching or any reverse engineering. No dependencies will be added to the server. Basically, it clicks buttons for you. In this blog article, I want to show what steps will be required to attach APX to a rFactor 2 server.

As APX is still developed behind closed doors, the purpose of this article is more to present the concept behind the project than being a tutorial.


I don't like clicking buttons, but I like shells. And shells can be used for automation much better.

What does APX stand for?

The name follows the concept of the naming of package managers, such as apt, dnf or npm. APX is roughly an abbreviation for "you missed the apex".


APX is a Python 3 based tool, composed out of two components: A CLI interface and a reciever component, communication is done via HTTP. The cli interface commands the reciever, which is clicking buttons using the pywinauto library.

For production use, I will provide precompiled binaries for the CLI and the reciever. Less dependencies for your server :)

Requirements: Directory structure

APX requires a defined structure.

  • build: Required for later usage (skin building mostly)
  • reciever: The APX reciever component
  • server: The rFactor 2 server
  • steamcmd: A steamcmd installation

Requirements: Configuring the reciever

You will have to to this once per managed server

The reciever reads it's settings from the configuration file server.json, located inside the reciever directory. It is important that APX does not manage the firewall, requiring the administrator to set the ports up. APX requires an TCP port according to the value port from the configuration accessible from the outside.

  "root_path": "Absolute path to the root folder (containing build, reciever, server, steamcmd)",
  "port": 5000,
  "host": "",
  "auth": "an-given-password",
  "debug": false,

Requirements: Configuring the CLI

You will have to do this once per managed server

Each managed server is an entry inside the file servers.json in the CLI folder. You can either run the CLI from another computer or from the server itself. But I recommend managing everything from the outside, in case you don't want to evade automatically opening windows ;)

  "a_name_for_the_server": {
    "url": "http://server_ip:5000/",
    "public_ip": "server_ip",
    "secret": "an-given-password",
    "env": {
      "build_path": "An local, absolute path where the livery files are located",
      "out_path": "An local, absolute path to tempary put VEH files into",
      "packs_path": "An local, absolute path to paste skin archives into"

Managing the event

You will have to do this per event and update you want to run

Per event, you create a event config file, describing cars, sessions, ports and so on. A sample configuration for a event config can be found here. You don't have to fiddle around with files, you manage everything inside this file.

Let APX do it's job

The reciever component needs to be running to continue. Any further steps will be done using the CLI. No clicking on the server required. APX will patch the server to the latest version. In this concept, you will basically only log onto the server to patch Windows itself, unless you use something to automate that aswell.

# deploy the server, you can switch between configs at any point!
python apx.cli --server a_name_for_the_server --cmd deploy pathtoyourconfig.json pathtoyourrfm.rfm

# start the server
python apx.cli --server a_name_for_the_server --cmd start

# do some stuff
python apx.cli --server a_name_for_the_server --cmd chat --args "hello everyone"

python apx.cli --server a_name_for_the_server --cmd kick --args "G√ľnther Hubspecht" # he is a prick

Looking into the future

The initial setup requires some time, but when you are done, the setup becomes much easier and can be automated (e. g. with planned tasks)

  • There are still "some" issues to fix (note the quotes)
  • Adding a web interface
  • Licensing everything under an open source license (most likely MIT, MPL or GPLv3)

Join the discussion!

I created a discord for announcements and dicussion: - feel free to join!

Photo by Andrey Konstantinov on Unsplash


Disclaimer: APX is not related in any way with S397. It's just an idea to make the life of admins easier.