Azuriom: a Laravel web platform for hosting game server communities

One Laravel application that stands in front of one game server

Azuriom is described in the README as a complete open-source web solution for game servers, with dozens of extensions for endless possibilities, and it is already trusted by what the project reports as over 1,800 servers totalling more than two million users.

The shape of the thing matters more than the feature list. Azuriom is a PHP application built on Laravel, with a plugins directory, an app directory for the core, a routes directory, and a database directory holding migrations. What it gives a server operator is the set of web things every game community ends up writing: user accounts, a forum, a store, a news or announcement area, and an administrative back office. The operator gets all of that as one deployable application rather than as a set of separate scripts to glue together.

The supported games are listed as native: Minecraft, Hytale, Garry's Mod, ARK Survival Evolved, Rust, FiveM, Unturned, Counter-Strike 2, 7 Days to Die, DayZ, Project Zomboid and Team Fortress 2. The repository topics also list csgo and ark, and the older names appear alongside the current ones.

And the platform is extensible at the game level too. The README says you can implement your own game, and gives two examples of community work: a Flyff implementation and a Dofus 1.29 implementation, both in separate repositories, with the how-to in the documentation under the games section. That is the important structural fact here. A community that is not on the list of twelve does not have to wait for the core project to add it.

Plugins and a separate game binding, chosen by an environment variable

The architecture has two extension points and they are worth separating, because they are often confused.

The first is the plugin system. The plugins directory in the repository holds the extensions, and the README describes dozens of them as the source of the endless possibilities. A plugin adds a feature to the site regardless of which game is behind it, and the admin panel, the theme layer and the surrounding community features are the core application.

The second is the game binding, and this is where the selection happens. The environment file example shows the key.

AZURIOM_GAME=mc-offline

That single variable names the game integration the instance is bound to, with mc-offline pointing at Minecraft in its offline mode. Other integrations are named in the same way for the other supported titles. The implication is direct: an Azuriom instance is bound to one game, and the binding is a configuration value rather than a runtime switch across many games. If your community spans three different games, you are looking at three instances, not one portal with three sections.

The Dockerfile and the compose file fill in the rest of the stack. The application image is built on php:8.3-fpm-alpine with the pdo, pdo_pgsql, bcmath and zip extensions compiled in, and it runs as the www-data user.

FROM php:8.3-fpm-alpine

RUN apk add --no-cache \
    git \
    curl \
    zip \
    unzip \
    libzip-dev \
    postgresql-dev \
    openssl \
    && docker-php-ext-install pdo pdo_pgsql bcmath zip

The compose file adds an nginx front end publishing port 8000 to the container's port 80, and a postgres:18 database service with a named volume for the data directory. The application service receives its database connection through the standard Laravel environment variables, with DB_CONNECTION set to pgsql, DB_HOST set to db, and DB_PORT set to 5432.

The compose file is a development setup, and the README says so

The Docker instructions are short, and the order of them matters.

First download the latest Azuriom release and extract it in a folder. The note at the top of the README is emphatic about this: to install Azuriom, do not clone this repository directly, instead download from the official website or from the releases page. Then start the stack with a single command.

docker-compose up -d

The README frames Docker as an easy development setup, and reading the compose file explains why that qualifier is there. The application service binds the working directory into the container, so the code on the host is the code that runs.

        volumes:
            - .:/var/www/azuriom

The nginx service does the same thing, and also mounts the repository's own nginx configuration into place, and the database service uses a named volume for the PostgreSQL data directory. The credentials in the compose file are development credentials, with the database password literally spelled password, which is fine for a local stack and wrong for anything else.

The environment file example shows how a real deployment differs. The default DB_CONNECTION there is mysql rather than pgsql, with the host at 127.0.0.1, the port at 3306, and the root user with an empty password field to fill in. The same file covers the rest of the configuration surface: APP_KEY is empty and has to be generated, APP_ENV is production while APP_DEBUG is false, the session driver is file with a 120 minute lifetime, the cache driver is file, the queue connection is sync, and the filesystem disk is local.

The file also lists the third-party integrations Azuriom can talk to, and this is where the operational scope becomes visible. There is a STEAM_KEY for Steam, EPIC_CLIENT_ID and EPIC_CLIENT_SECRET for Epic Games, and a full set of AWS variables including AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION, AWS_BUCKET and AWS_USE_PATH_STYLE_ENDPOINT, which is how the file storage for user uploads and store assets is pointed at S3 rather than local disk.

A frontend built with Vite and AdminKit, not server-rendered Blade alone

The package.json shows the asset pipeline, and it is a modern one. The build script is vite build and the dev script is vite, with a vite.config.js at the top level and the laravel-vite-plugin in the dev dependencies, so the Laravel side and the asset build are wired together in the conventional way.

The design system is AdminKit, taken as a tarball of a specific tag rather than from a registry, which pins the exact version of the theme the build expects. Around it sit Bootstrap 5 and bootstrap-icons for the base layer and the icons, and a set of interactive libraries: axios for requests, chart.js for the graphs in the admin panel, sortablejs for drag and drop ordering, flatpickr for date inputs, tinymce for rich text, easymde for markdown editing, petite-vue for small components, and @simonwep/pickr for colour pickers. Sass is the stylesheet language, and vite-plugin-static-copy handles copying static assets into the build output.

The scripts are only two, build and dev, and there is no test script, no lint script and no type check in the file. The JavaScript side is not a place where Azuriom asks its contributors to do much.

That contrasts with the PHP side, where there is a phpunit.xml, a tests directory, a pint.json for code style, an .editorconfig, a .styleci.yml, and a phpunit-based CI workflow with a badge in the README. The PHP application is where the project's testing and style discipline sits, which is the expected shape for a Laravel application with a large plugin surface.

Licence, security reporting, and the permission model in the admin area

Azuriom is licensed under the GNU General Public License v3.0 or later, with an attribution appendix in a separate LICENSE_APPENDIX file. For a web platform that operators host themselves, the copyleft terms mean that a modified version distributed as a web application carries obligations, and the appendix is there to cover that case.

The security policy is specific and worth reading before deploying. The README says that if you discover any security related issues within Azuriom, send an e-mail to [email protected] instead of using the issue tracker, and that all security vulnerabilities will be promptly addressed. A private reporting channel is a sign of a project with a real disclosure process rather than a token one.

The second part of the security section is a policy statement about the admin area, and it is unusual enough to quote closely in substance. Features in the admin area that allow users with the relevant administrative permissions to configure HTML, JavaScript, or other active content are considered administrative content management features. Reports demonstrating script execution through these features are not considered vulnerabilities unless they show that a user without the required permission can inject such content or that the permission allows crossing an additional privilege boundary.

In plain terms, an administrator being able to put a script into a page is a feature of the product, and the disclosure threshold is whether a lower-privileged user can reach it. That is a coherent and defensible line, and it also means a site owner has to be careful about who gets which admin permission, since the platform treats that permission as granting script execution on the site.

The rest of the community infrastructure is conventional and well signposted. Support is on Discord, translations are managed through Crowdin at translate.azuriom.com, and there is a code of conduct, a contribution guide, and a GitHub sponsors page.

The alternative is building the same thing yourself, in pieces

The realistic alternative to Azuriom is not another PHP platform, it is assembling the same set of features from separate parts, and the comparison is worth making explicitly because it is the case where Azuriom earns its place.

A community that needs accounts, a forum, a store and a donations page has a short list of options today. A game platform's own forum handles the forum but not the store or the user accounts for a web portal. A general purpose forum with a plugin for the game handles the forum well and the rest badly. A generic web application framework, Laravel or Symfony, gives you the accounts and the admin panel and leaves the game integration, the store and the plugin ecosystem to you. And a hosted all-in-one game community service gives you the whole thing with no hosting but no ownership of it either.

The difference in approach that Azuriom offers is the combination of a generic community core with a first-party binding for a dozen games and a plugin ecosystem that is not tied to one of them. The Flyff and Dofus implementations show that a game outside the supported list can be added by a third party, which is the property that makes the platform extensible rather than merely broad.

The cost of that approach is that you are committing to a PHP and MySQL or PostgreSQL deployment and to a platform with a regular release cadence. The tags are frequent, v1.2.11 in June 2026, v1.2.12 later that month, and v1.2.13 in August 2026, with the last push on 2026-10-03. That is a project being maintained, and it is also a project whose upgrade notes you will need to read, because the plugin API underneath the extensions is the thing that moves.

Editorial conclusion

Azuriom fits a community operator running a single Minecraft, Rust, CS2 or FiveM server who wants accounts, a forum, a store and an admin panel in one PHP application that they can host on ordinary shared hosting or a small VPS. It does not fit a network of many separate games, since the game binding is selected by the AZURIOM_GAME environment variable and one instance serves one game, and it does not fit a team unwilling to own a PHP and MySQL deployment. Before installing, read the installation page on the documentation site rather than the Docker route, because the compose file in the repository is described as a development setup with the application directory mounted into the container and a default database password, so a production deployment needs the environment configured properly.

Frequently asked questions

Official sources

1. Azuriom/Azuriom on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases