alf.io needs a non-superuser Postgres role, and its Docker Compose file is development only

Row security in Postgres is the foundation, not a detail

The prerequisites section is short and one line in it decides whether your deployment is safe.

You need Java version 25 to build and run alf.io, and the JDK specifically for the build process, from Oracle, OpenJDK or any other distribution. You need PostgreSQL version 10 or later.

Then this: the database user that creates and uses the tables should not be a SUPERUSER, or else the row security policy checks will not be applied.

That is not a style recommendation, it is a correctness condition. A system that isolates one organizer's event data from another's at the database layer depends on those policies actually running, and a superuser bypasses them. A deployment that connects as a superuser looks fine in testing and leaks rows in production.

This also shapes the local setup, because the documented PostgreSQL container is configured with a plain POSTGRES_PASSWORD and POSTGRES_DB, and you are expected to create the application role yourself. The dev-mode prerequisites are a PostgreSQL instance on localhost:5432, a postgres user whose password is password, and a database named alfio.

docker run -d --name alfio-db -p 5432:5432 -e POSTGRES_PASSWORD=password -e POSTGRES_DB=alfio --restart unless-stopped postgres

Once it starts, alf.io creates the tables it needs and serves the admin interface at http://localhost:8080/admin, with the username admin and a password printed to the console. That printed password is the only copy, so capture it before you scroll.

Five Spring profiles, one of which changes your login

The application is a Spring Boot project and the profiles are listed rather than explained, which makes them worth reading twice.

dev enables dev mode. spring-boot is added when launched by spring-boot. demo enables demo mode, and the important detail is that the accounts for the admin are created on the fly. disable-jobs turns off the scheduled jobs. jdbc-session persists the user session in the database.

demo is the one with operational consequences. If you enable it anywhere near a real event, your admin account is created automatically with credentials you did not choose, which is a hosting-level footgun in a multi-tenant deployment.

disable-jobs matters for running more than one instance. Jobs are what send email, expire reservations and do the background work of a ticketing system, so two instances with jobs enabled means duplicate emails and double-expiring holds.

jdbc-session is the one to think about before you scale horizontally, because the default in-memory session means a user logged in on one instance is logged out when they land on another.

Multi-profile runs are done with a project property.

./gradlew -Pprofile=dev :bootRun

And the build needs no local Gradle, because the repository ships a wrapper.

./gradlew clean

custom.jvmargs is where the secrets go, and git already ignores it

System properties beyond the profile can go into a file with one property per line.

vi custom.jvmargs

The file can hold sensitive values, and the README names Google Maps private API key as the example, which tells you what kind of configuration belongs there. It is automatically ignored by git, and the repository ships custom.jvmargs.example as the tracked template.

The same file is where debugging happens, by adding one line.

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

suspend=n means the JVM does not wait for a debugger, which is the setting you want in a container that also has to serve traffic.

The task list is discoverable rather than documented.

./gradlew tasks --all

And there is a dedicated task for the maintenance chore most Java projects have.

./gradlew dependencyUpdates

Docker Compose here is a development harness

Container images are published on Docker Hub under alfio/alf.io, so production does not require building anything.

Compose is also shipped, and the file is small enough to be decisive.

services:
    db:
        image: postgres:10
        env_file:
            - .env
        healthcheck:
            test: [ "CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}" ]
            interval: 10s
            retries: 5
            start_period: 30s
            timeout: 10s

One service, a database, with a pg_isready healthcheck on a ten second interval and a thirty second start period.

The application service is present but commented out, under a comment saying that if you want to try out alf.io you can uncomment the following service.

#    alfio:
#        image: alfio/alf.io
#        env_file:
#            - .env
#        depends_on:
#            db:
#                condition: service_healthy

The README is explicit that running alf.io in production using Docker Compose is not officially supported, and lists what you would have to change if you insist: uncomment the alfio service, check the user and password in .env, and handle SSL termination yourself, for example with something like tutum/haproxy mapping 443 to 8080.

So the compose file is a development harness with a database, and the untested path is the one most self-hosters will take. That is the single most important thing to know before planning an install.

Contributing means IntelliJ, Lombok and a real PostgreSQL

Importing the Gradle project into IntelliJ and Eclipse both work, and there are two notes that will stop you otherwise.

The project uses Project Lombok, so you need the corresponding Lombok plugin for IDE integration. That is the usual Lombok experience: the code compiles and the IDE shows errors until the plugin is installed.

It uses TestContainers to run integration tests against a real PostgreSQL database, so your environment has to meet TestContainers requirements. The integration tests are not mocked, which is the right choice for a system whose correctness depends on database behaviour like row-level security, and it means your CI needs a container runtime.

There is a specific Podman recipe for Fedora, and the caveats are as valuable as the recipe.

export TESTCONTAINERS_RYUK_DISABLED=true
export DOCKER_HOST=unix:///run/user/1000/podman/podman.sock

With podman system service -t 0 running in another console. Two warnings come with it: the first time podman downloads missing images, TestContainers fails and a second run works; and with systemd socket activation the service should start automatically but the author was not able to make it work.

That level of detail in a README is a signal about the project's maturity. The contributors hit these problems and wrote down what happened.

The branch you are on decides whether you can trust it

The note above the prerequisites section is the one to read before anything else.

As the work for Alf.io v2 has started, this branch may contain unstable and untested code. If you want to build and deploy alf.io by yourself, please start from a released version.

The tags follow that pattern. The recent releases are all milestone builds in the 2.0-M5 line: 2.0-M5-2609 from 2026-09-18, 2.0-M5-2606 from 2026-06-02 and 2.0-M5-2509-1 from 2025-09-10, where the suffix encodes the month and year. No stable major version is tagged in that list, so the released builds and the main branch are not the same thing.

The repository is not archived and the last push was on 2026-10-12, so work continues on main.

Around the code there is the usual infrastructure of a project with real users: CHANGELOG.md, CODE_OF_CONDUCT.md, SECURITY.md, a Docker-based docker-compose.yml, .env for configuration, config/, docs/, frontend/, etc/, a clevercloud/ directory for a specific hosting platform, website/, and build.gradle.kts with settings.gradle.kts and gradle.properties written in Kotlin DSL. The .bowerrc file and a lib_exclude entry point at the root suggest a frontend asset pipeline that predates modern bundlers.

Licensing is GPL-3.0, which matters if you intend to modify and host it for paid events, and the project also takes financial contributions through Open Collective.

Editorial conclusion

Adopt alf.io if you run a conference, workshop or meetup and want ticket sales with fair pricing and attendee privacy rather than a generic ticketing page, and you are willing to run PostgreSQL 10 or later and Java 25. Do not deploy from the main branch: the README says v2 work has started there and that the branch may contain unstable and untested code, so build from a released version. Verify first that your database role is not a SUPERUSER, because the row security policy checks silently do not apply otherwise, and that the alfio service in docker-compose.yml is uncommented and SSL terminated before you point a real domain at it. Images are on Docker Hub and the licence is GPL-3.0, with the most recent release being the 2.0-M5-2609 milestone build from 2026-09-18.

Frequently asked questions

Official sources

1. alfio-event/alf.io on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases