Engelsystem: the shift planning system behind the German chaos events

What the Engelsystem actually does for an event

The Engelsystem is a shift planning system for chaos events, and the README points you to engelsystem.de for the feature list rather than reproducing it here.

The domain is narrow and worth understanding before the technical details. A large German chaos congress can have several thousand helpers, and those people have to be scheduled onto shifts: someone has to staff the entrance, the kitchen, the network, the stage, the cleaning, the security, the children's area, and each of those shifts has a minimum headcount that has to be met or the event does not work. Engelsystem is the tool that holds the schedule, the people, the qualifications and the attendance, and it is the reason a volunteer can turn up, look at a board, and find a task.

The topics list confirms the context, with ccc and chaos among the tags, and the release history ties the project directly to the congresses. The releases are v3.7.1, a security update, on 2026-09-28, v3.7.0 named 39c3 from 2026-03-03, and v3.6.0 named 38c3 from 2025-02-18.

Those release names are the clearest signal about the maintenance model. A new major version is cut for each congress, so the version you run tells you which event season it was built for, and the 39c3 and 38c3 names correspond to the 39th and 38th Chaos Communication Congress. The v3.7.1 patch then landed in September 2026, months after the 3.7.0 release, which is the shape of a security fix applied to a system that is already deployed.

The project is GPL-2.0 licensed, the homepage is engelsystem.de, the last push was on 2026-10-12, and the code is PHP with a JavaScript front end.

Requirements, and the sizing note that tells you who it is for

The requirements are ordinary PHP hosting requirements, which is part of why the project has been able to run unchanged for years.

PHP 8.2 or later is needed, with a specific set of modules: dom, json, mbstring, PDO with the mysql driver, tokenizer, xml with libxml and SimpleXML, and xmlwriter. The database is MySQL 5.7.8 or later or MariaDB 10.7 or later. The webserver can be nginx, lighttpd or Apache.

The sizing note is the most informative line in the whole README. From previous experience, 2 cores and 2GB of RAM are roughly enough for up to 1000 helpers, described as about 700 arrived plus 500 arrived but not working, during an event.

That parenthetical is the detail that shows the author understands the domain. The number that matters is not the helpers on the roster but the people who showed up, and the fact that only some of those are actually working the shift at any given moment. An attendance system where 500 people are marked as present but not on task is a normal state, not a data error, and a system sized for the roster rather than the floor plan will fall over at the busiest moment.

So the sizing guidance tells you this is a system for a large event rather than a small one, and that the operational load comes from attendance rather than from the number of scheduled shifts.

The installation routes reflect the same pragmatism. The Engelsystem may be installed manually by uploading files to a web host, or by using the provided Docker setup. Nothing about it requires a platform as a service or a container orchestrator.

Configuration, migrations, and the default password you must change

The setup instructions are specific enough to follow without guessing, and each item corresponds to a way the application can be misconfigured.

The webserver must have write access to the storage directory and read access for all other directories, and it must point to the public directory rather than the project root. It must read the .htaccess file and mod_rewrite must be enabled. Directory listing should be disabled, which is a plain security measure for a directory that holds uploaded files. There must be a MySQL database with a user who has full rights to it.

Configuration is done through the web UI, which the README recommends over editing files, with a config/config.php available to override values. The minimal example given connects to the database:

      <?php
      return [
        'database' => [
          'host' => 'localhost',
          'database' => 'engelsystem',
          'username' => 'engelsystem',
          'password' => '<your password here>',
        ],
      ];

There is one sharp edge in the configuration notes. If you want to change items from a list, all values must be present in your config.php, including new ones. That is a behaviour worth knowing in advance, because a config file that overrides a list partially will not merge with the defaults.

The database is imported with the bin/migrate script, and there is a fallback for hosts where you cannot execute scripts: import the initial-install.sql file from the release zip instead.

And then the line every installer should read twice. In the browser, log in with the credentials admin and asdfasdf, and change the password. A first-run credential published in the README is a shared secret, and the instruction to change it is the whole of the mitigation. If you expose this system before changing that password, you have exposed the whole event schedule.

Session settings need one more check after that. Make sure the config allows for sessions, and note that both Apache and Nginx allow for different VirtualHost configurations, so the session handling has to be verified against whichever server you use.

The Docker path, and the CLI scripts that make it operable

The Docker instructions are separate from the manual ones, and the first thing they say is that the development container build is documented in DEVELOPMENT.md rather than in the README.

The build is a compose build from the docker directory:

cd docker
docker compose build

or, to build the container on its own:

docker build -f docker/Dockerfile . -t es_server

The container is named es_server, and running it is the same directory with compose up in detached mode:

cd docker
docker compose up -d

Migrations run inside the running container, which handles both a fresh schema and upgrading an existing one:

cd docker
docker compose exec es_server bin/migrate

The scripts directory is the part that makes the system operable rather than merely installable, and each of the four scripts has a distinct job.

bin/migrate imports and updates the database, with its own help output for the available commands. bin/deploy.sh deploys the application to a server, using rsync over ssh, with a usage flag. bin/config2docs is a helper that generates the configuration documentation page, which is how the config reference on the site stays in step with the code. And bin/pre-commit is a development aid that checks code quality against the expected standard before a commit lands.

That last one matters for a project that asks for contributions. The README says the Engelsystem is open source and that they really love pull requests containing fixes or improvements, and asks contributors to read CONTRIBUTING.md and DEVELOPMENT.md first. A pre-commit script that enforces the standard is what makes that request workable, and it explains the presence of a phpstan.neon.dist and a .phpcs.xml at the root.

More documentation is at engelsystem.de/doc/, and bugs go to the GitHub issues tracker.

The front end toolchain, and what the repository layout reveals

The package.json is for the front end, and it is a modern one.

The build is webpack, with a production script that sets NODE_ENV, a watch mode, and a set of loaders for CSS, PostCSS, Sass and resolve-url. The minification is handled by minimizer-webpack-plugin and terser-webpack-plugin, and there is a webpack-manifest-plugin for asset naming and a mini-css-extract-plugin for stylesheets.

The runtime dependencies are deliberately few, and they explain what the interface is built from. Bootstrap 5.3 with bootstrap-icons provides the base styles and the icon set, Popper handles the positioning that Bootstrap's dropdowns and tooltips need, core-js provides the polyfills, and choices.js is a select replacement that gives the shift and task pickers the searchable behaviour a large schedule needs.

The linting is interesting. It runs biome check and editorconfig-checker, with fix variants including an unsafe one. The editorconfig-checker is the tool that keeps whitespace and line endings consistent across a codebase with many contributors, and using it as a lint step rather than a convention is a deliberate choice.

The rest of the repository layout is conventional for a PHP web application with a separated front end. There is a public/ directory for the webroot, a src/ directory for the application code, includes/ and resources/ for templates and assets, a config/ directory, a db/ directory, a storage/ directory for the writable data, tests/ with phpunit.xml, a bin/ directory for the CLI scripts, a docker/ directory, and a deployment.tpl.yaml template for deployment configuration.

There is also a security file in the root, a SECURITY.md, alongside the licence and the contributing and development guides, and a .gitlab-ci.yml for the pipeline, with the badges at the top of the README pointing at a pipeline status and a coverage report hosted on chaos.expert.

Editorial conclusion

Adopt Engelsystem if you are running a multi-day event with enough volunteers that shift coordination needs a database and a login system, and you have someone who can run a web server and a MySQL instance. Do not adopt it for a small meetup, since it is sized for up to 1000 helpers and expects a real operations setup. Before you deploy, change the default admin password, because the documented first login is admin with a well known password, and decide whether you need the Docker path or a plain web host, since the two differ in how you run migrations.

Frequently asked questions

Official sources

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