Hi.Events: a self-hosted ticketing platform under AGPL-3.0 with an attribution clause

The problem: per-ticket fees and data you do not own

Commercial ticketing platforms bill per ticket sold and hold the attendee relationship. The README frames Hi.Events as an answer to that: it says most platforms charge per-ticket fees and lock data into their ecosystem, and positions the project as an open-source alternative to Eventbrite, Tickettailor and Dice.fm for organizers who want control over branding, checkout, data and infrastructure. The target user is not a hobbyist running one meetup. The listed scenarios are nightlife promoters, festivals, venues, community groups and conference hosts, which implies multiple events, multiple ticket tiers and staff who need differentiated access. The repository topics name the same audience from the other direction: attendize-alternative, eventbrite-alternative, tickettailor-alternative, tito-alternative, door-management, event-check-in. So the pitch is a full replacement rather than a registration form. What that buys you is the ability to keep the attendee list, the sales reports and the checkout flow in a database you control, and to change them, because the source is in front of you. What it costs you is everything a hosted vendor used to absorb: servers, upgrades, payment configuration and the operational work of running a Laravel application in production.

What the stack actually is, and where the data lives

The README states the build: Laravel 13 on PHP 8.3 or newer, React 19 with server-side rendering, TypeScript, PostgreSQL and Redis, shipped in Docker. That combination tells you the shape of the system before you read a single controller. PostgreSQL is the system of record for events, tickets, orders and attendees. Redis is present, and in a Laravel application of this type that usually means queues, cache and sessions, though the README does not spell out which of those Hi.Events uses it for, so treat the exact role as something to confirm in the compose file rather than assume. React with SSR means the public event pages are rendered on the server first and hydrated in the browser, which matters for the SEO metadata controls the feature list mentions. The operational surface is broad but concrete: multi-user roles, Stripe Connect for payments, offline payment methods, automatic invoicing, custom checkout questions, promo codes including promo-gated and hidden tickets, product add-ons, waitlists, full and partial refunds, bulk messaging, QR check-in with scan logs and access-controlled check-in lists, affiliate tracking, outgoing webhooks, and a REST API. Stripe Connect is the load-bearing piece. It is the mechanism by which money reaches an organizer rather than pooling in one account, and it is also the piece most likely to require configuration outside the application, because Connect onboarding is tied to the organizer's own Stripe account and jurisdiction.

Getting an instance up with the all-in-one Docker compose

The README gives a short path. Clone the repository, change into the docker/all-in-one directory, generate two secrets, then bring the stack up. The commands are literal: git clone git@github.com:HiEventsDev/hi.events.git, then cd hi.events/docker/all-in-one, then two echo lines appending to .env, one writing APP_KEY=base64: followed by openssl rand -base64 32, the other writing JWT_SECRET= followed by the same generator. After that, docker compose up -d. The README notes that Windows users should consult docker/all-in-one/README.md for key generation instructions, which is a sign the shell one-liners are not portable as written. Once the containers are running, the stated entry point is http://localhost:8123, where you create your account. That is a development or evaluation setup, not a production topology, and the README does not pretend otherwise. For the API, set API_DOCS_ENABLED=true in .env to serve interactive OpenAPI documentation at /docs/api on your own instance, or export the specification with php artisan scramble:export. There are also one-click deploy buttons for DigitalOcean, Render, Railway and Zeabur, each pointing at a separate repository, which is the lower-effort route if you do not want to manage the compose file yourself. The README does not document the contents of those templates, so what they provision is something you would check before trusting them with a live event.

The licence is the real adoption decision

The repository metadata reports the licence as NOASSERTION, and the README explains why: Hi.Events is AGPL-3.0 with additional terms. Those additional terms require the Powered by Hi.Events attribution to be retained on pages and emails generated by the software, and the README points to the LICENCE file for the exact wording. This is the point where a technical evaluation turns into a business one. AGPL-3.0 already carries network-copyleft obligations: if you modify the software and let users interact with it over a network, you are expected to offer them the corresponding source. The added attribution term sits on top of that, and it is the kind of clause that a white-label deployment will collide with, because a white-label deployment exists precisely to remove other people's branding. The README acknowledges the conflict directly and offers the exit: commercial licences are available if you want to remove the attribution or need terms suited to a white-labelled deployment, with a licensing page and a contact address. I am not a lawyer and this is not legal advice. The practical reading is that if your event brand and the Hi.Events badge can coexist on your checkout pages and confirmation emails, the AGPL path is open to you; if they cannot, budget for the commercial licence before you build anything on top. Read the LICENCE file yourself rather than relying on the badge in the README.

Where it fits badly: pre-release versions and a thin operations story

Two things in the supplied material should temper enthusiasm. First, the release line. The most recent release listed is v2.0.0-rc.1, dated 2026-08-27, and the two before it are v1.11.1-beta and v.1.11.0-beta. A release candidate at the head of the line means the newest code is explicitly not declared stable, and the betas behind it suggest the project has been shipping pre-release versions as its public artifacts. If you are selling tickets for a festival with a fixed date, running the head of the develop branch is a poor trade. Second, the operational documentation visible here is thin. The README covers the all-in-one compose file and points to an external installation guide, but it does not describe backups, queue workers, scheduled jobs, log retention or how to upgrade an existing instance without losing data. For a Laravel application with Redis in the stack, those are not optional concerns. There is also a real ceiling on the model: you are the operator. A payment dispute, a Stripe Connect onboarding failure at 9pm on the night of an event, or a database that fills its disk is your problem, not a support desk's. Organizations without someone who can read a container log should weigh the cloud option instead. And the attribution clause rules out one common use case outright: an agency reselling ticketing under its own brand to multiple clients.

Compared with Pretix, and the difference in approach

The obvious open-source comparison is Pretix, a long-running self-hosted ticketing system in the same space. The two differ in how they are built and therefore in what you can change cheaply. Pretix is a Python and Django application with a plugin architecture that is the documented extension path; adding behaviour generally means writing a plugin against its API. Hi.Events is a Laravel and React application with a documented REST API and outgoing webhooks, so the extension path is more likely to be an external service reacting to webhooks or calling the API than a plugin loaded into the core. For a team already fluent in PHP and Laravel, Hi.Events means reading and patching the application directly, which is faster than learning a plugin framework. For a team that wants to keep its customizations in a separate, upgradeable layer, Pretix's plugin boundary is the cleaner separation. The other difference worth noting is licensing posture: the additional attribution term in Hi.Events is not something you find in every open-source ticketing project, and it changes the calculus for anyone whose product is the ticketing page itself. Neither choice is wrong. They suit different teams, and the deciding question is whether you would rather write a plugin or fork a Laravel application.

Maintenance cost and what to verify before you commit

The maintenance burden here is the ordinary burden of a self-hosted web application, and the README does not reduce it. You are tracking Laravel 13 and PHP 8.3 or newer, PostgreSQL, Redis and a React build with SSR. Upgrades arrive as releases, and the most recent one is a release candidate, so an upgrade path from a stable version to v2.0.0 is something you would want to test on a copy of your database before touching production. The API surface adds a second compatibility concern: anything you build against the REST API is coupled to a project whose head is currently pre-release, and the README gives no stability guarantee for the API across versions. On the licence side, the attribution term is not a one-time setup step. It applies to pages and emails generated by the software, so if you customize templates you need to keep that badge intact, and if you later decide you want it gone, the commercial licence conversation happens after you have already built on the AGPL version. Before adopting, read the LICENCE file for the exact wording rather than the summary in the README, confirm your PHP version against the stated 8.3 minimum, check whether your payment flows depend on Stripe Connect features your country supports, and decide in advance which release you will pin to. A team that pins to a stable version, keeps the attribution, and has someone who can run docker compose and read a log will get a lot out of this. A team that wants a vendor to own the 2am problem will not.

Editorial conclusion

Adopt Hi.Events if you are a technical organizer or venue that wants ticket inventory, QR check-in and Stripe Connect payouts inside your own infrastructure and can live with the Powered by Hi.Events attribution on generated pages and emails. Do not adopt it if you need a white-labelled checkout without paying for a commercial licence, or if you cannot operate a Laravel application plus PostgreSQL and Redis. Before committing, read the LICENCE file for the exact wording of the additional terms, confirm your PHP version meets the stated 8.3 minimum, and verify on a staging instance that your Stripe Connect account and your tax rules behave the way your finance process expects.

Official sources

1. HiEventsDev/Hi.Events on GitHub
2. Issues
3. Project website
4. README
5. Releases