SoulFire's readme says the image bundles the software renderer and then tells you to install it

The readme says the renderer is bundled and then says to install it

The installation section describes a headless setup with no system graphics packages and no display server, because the server carries its own Vulkan runtime and a software rasteriser for CPU rendering. Installed graphics drivers give hardware acceleration when they are present. Two sentences later, the same section says the Docker image includes the software rasteriser and then, in the next sentence, tells Debian and Ubuntu users to install two packages when running without a graphics driver. Those are the packages the rasteriser needs, so the instruction either restates what the image already carries or contradicts the previous sentence. Two more details in that section are worth knowing. Point-of-view captures and inventory images render on demand without ever opening a native window, and OpenGL is disabled outright, which is why a software Vulkan path is there at all. A separate document holds manual comparison tests for the renderer.

The container fetches its jar from a release URL and verifies nothing

The image is one stage on a Java 25 runtime, creating a non-root user with a fixed identifier, installing an init wrapper and a client for health checks, then declaring a build argument whose default is a download URL pointing at the release asset for the requested version. That URL is used in an add instruction, so the jar is retrieved while the image is being built rather than being copied in, and nothing in the file hashes or verifies what arrived. The argument can also be overridden with a local path, which the comment says is for validating an unpublished build, so the same file can equally pull from any location you name. The rest of the container is careful: the data directory is created and handed to the unprivileged user, the jar is made world-readable inside a private home, the health check polls a port that is also the exposed one, and the labels carry the licence and the vendor identity.

The feature list advertises a graphical client that lives elsewhere

The opening line repeats the project description: an advanced bot tool for server testing, automation and development. Two lines into the document it says this repository contains only the command line and server implementation, and that the official graphical client is in another repository. That matters because the feature list leads with a graphical interface in multiple themes alongside the command line, so the headline feature is not in the tree you are reading. The build-from-source section repeats the split in a more confusing way. It tells you to install a recent Java, run the Gradle wrapper build, and then take the jar from one of two module output directories, one of which belongs to the client module whose sources live in the other repository.

The readme lists no commands and recommends two sponsored proxy vendors

There is not a single command in this document. The commands section sends you to a documentation site or tells you to run a help query in the graphical or command line interface, and the version support, plugin, account and proxy sections are all links to the same site. The only actions printed anywhere are the build commands. The proxy section is the one place with content beyond a link, and it is a warning rather than a guide: free proxies are described as unreliable and insecure, and two paid providers are recommended by name, both noted as sponsors of the project, both reached through links carrying referral and campaign parameters. That is a reasonable disclosure to have in a readme, and it is also the only piece of the project's economics a reader can see.

The plugin API carries an explicit promise of breaking changes

The developer section is the most candid paragraph in the document. There is a plugin API for writing your own behaviour, and mixins for going deeper, and then a warning that the project can include breaking changes, with the instruction to pin your plugin to a project version or update it when the project changes. That is unusual to see stated plainly and worth more than a compatibility table would be. Alongside it are two SDKs, one TypeScript and one Python, documented in their own directory, connecting over a web-based RPC transport to stream bot events, issue actions against individual bots, and provision a local dedicated server. A separate repository holds the example plugin, so the reference implementation is not in the same tree either.

Four planning documents sit at the repository root

Among the fifty-odd top-level entries, four are named after plans rather than after code: one about beating games, one about pathfinding, one about an SDK for beating games, and one about improving that SDK. They sit next to a deferred-work list, a prompt file, two shell scripts, and a metadata file for publishing. The workspace configuration confirms the direction, since one of the three JavaScript packages declared is the beat-game SDK, so the plan has become a package rather than staying a document. Nothing in the readme mentions any of this. For anyone auditing what the tool is being extended towards, the root of the repository is more informative than the readme, which is an unusual place for a roadmap to live but not an unusual practice for a project of this size.

Three toolchains and a Java 8 launcher beside a Java 25 requirement

One repository runs three build systems. Gradle is the main one, with a Kotlin build script, a build logic directory, a properties file, both shell and batch wrappers, and configuration for a Lombok annotation processor and a licence header template. A JavaScript workspace uses a different package manager entirely, with three packages, a prepare script that executes a shell script from the repository, and a lifecycle allowlist naming exactly two trusted packages. The third is a protobuf toolchain with its own generation, lock and lint configuration and a proto directory. Alongside all of it sits a directory named for a Java 8 launcher, in a project whose build instructions ask for Java 25 or newer, which is presumably how older servers are supported. Static analysis and dependency updates are automated through two more configuration files.

Editorial conclusion

Before anything else, confirm you are allowed to run automated clients on the server you have in mind and that your hosting provider permits it, because the project states that twice and puts the burden of unauthorized use on the operator. If you are building rather than testing, the plugin API is the part to plan around: it carries an explicit promise of breaking changes, so pin to a version and expect to move. And if you deploy the container, verify the jar you end up running, since the image fetches it from a release URL at build time without checking it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes