Hi.Events: a self-hosted ticketing platform for organizers who want the checkout and the data
Open-source event management and ticket selling platform — perfect for concerts, conferences, and everything in between 🎟️ If you find this project helpful, please consider giving us a star ⭐️
At a glance
- What is it?
- Hi.Events is an AGPL-licensed event ticketing and management platform built on Laravel and React, shipped with a Docker all-in-one image. It is aimed at organizers who would rather run the stack than pay per-ticket fees, and the licence's attribution clause is the first thing to read.
- Who is it for?
- Adopt Hi.Events if you run your own infrastructure, want the attendee list and the checkout under your own domain, and can live with the "Powered by Hi.Events" attribution that the additional terms require on generated pages and emails. Do not adopt it if you need a vendor to be accountable for uptime during a ticket on-sale, or if your legal review cannot accept AGPL-3.0 with additional terms.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The per-ticket fee problem Hi.Events is built around
The README states the motivation plainly: most ticketing platforms charge per-ticket fees and keep your data inside their ecosystem. Hi.Events positions itself as a modern open-source alternative to Eventbrite, Tickettailor and Dice.fm for organizers who want control over branding, checkout, data and infrastructure. That is a specific claim, and it maps to a specific audience: nightlife promoters, festivals, venues, community groups and conference hosts who already have somewhere to run a container and would rather pay for that than pay a percentage of every sale.
The repository topics reinforce the positioning. Alongside event-ticketing and self-hosted, the list includes attendize-alternative, eventbrite-alternative, tickettailor-alternative and tito-alternative. The project is not trying to be a general calendar or a CRM with a ticketing module bolted on. It is trying to be the thing you migrate to when the per-ticket cut becomes the line item you resent.
Who it is not for is equally clear from the README. If you do not want to operate PostgreSQL, Redis and a PHP application, the README points at Hi.Events Cloud, described as the fully managed version of this repository, run by the same team. Self-hosting here is a real commitment, not a checkbox.
What the stack actually looks like: Laravel, React SSR, PostgreSQL, Redis
The README's Quick Start section names the components: Laravel 13 with PHP 8.3 or newer, React 19 with server-side rendering, TypeScript, PostgreSQL, Redis, and Docker. The repository layout matches that split, with backend/, frontend/, docker/, e2e/ and scripts/ as top-level directories, plus a Dockerfile.all-in-one at the root.
The data flow implied by that structure is conventional for a Laravel plus React application. The backend owns the domain: events, ticket types, orders, attendees, promo codes, check-in lists, reports and webhooks. The frontend is a separate React application rendered on the server for public-facing event pages, which matters for the SEO metadata controls the README lists as a feature. PostgreSQL is the system of record and Redis sits alongside it, which in this kind of stack usually means queues, cache and session state.
Two operational details are worth pulling out of the feature list. Payments go through Stripe Connect, which means money moves to the organizer's connected account rather than pooling in a platform account, and the README also lists offline payment methods for organizers taking cash or bank transfer. The second is the REST API: the README says the API ships with interactive OpenAPI documentation, served at /docs/api when API_DOCS_ENABLED is set to true. An export path exists too, via php artisan scramble:export. For anyone wiring Hi.Events into an existing box office or CRM, that API is the integration surface, and the repository layout does not show a separate API package, so it is the same Laravel application serving it.
Installing Hi.Events with the Docker all-in-one image
The README's Docker path is short and assumes a Linux or macOS shell. Clone the repository, move into docker/all-in-one, generate two secrets into a .env file, and bring the stack up. The two secrets are APP_KEY, generated as base64 from openssl rand, and JWT_SECRET.
git clone [email protected]:HiEventsDev/hi.events.git
cd hi.events/docker/all-in-one
echo "APP_KEY=base64:$(openssl rand -base64 32)" >> .env
echo "JWT_SECRET=$(openssl rand -base64 32)" >> .env
docker compose up -dAfter the containers start, the README says to open http://localhost:8123 and create your account. That first account is the one you will use to create an organizer and then an event. The README notes separately that Windows users should read ./docker/all-in-one/README.md for key generation instructions, because the shell commands above assume a POSIX environment. If you are on Windows, follow that file rather than adapting the commands by guesswork.
The all-in-one image is published as daveearley/hi.events-all-in-one on Docker Hub, which is what the badge in the README points at. Beyond Docker, the README links to a full installation guide on hi.events/docs/getting-started, and the repository carries INSTALL_WITHOUT_DOCKER.md at the top level for the non-container route. Those two documents are where the environment variables, database credentials and queue worker setup live; the README itself does not enumerate them.
For the API, enable the docs endpoint in .env and restart:
API_DOCS_ENABLED=trueWith that set, the interactive OpenAPI documentation is served at /docs/api on your own instance. If you would rather consume the spec in another tool, the README gives php artisan scramble:export as the export command.
Where Hi.Events will not fit: attribution, release candidates and operational load
The licensing is the constraint most teams will hit first. Hi.Events is licensed under AGPL-3.0 with additional terms, and the README is explicit about what the additional terms do: they require the "Powered by Hi.Events" attribution to be retained on pages and emails generated by the software. Commercial licences are available for organizers who want to remove that attribution or need terms suited to a white-labelled deployment. If your brand guidelines forbid third-party attribution on checkout pages, you are either buying a commercial licence or you are not using this software. Note also that the repository's licence field reports NOASSERTION while the README and the LICENCE badge say AGPL-3.0 with additional terms; read LICENCE itself rather than trusting the metadata field.
The release cadence is the second thing to weigh. The most recent release listed is v2.0.0-rc.1 from 2026-08-27, a release candidate, preceded by v1.11.1-beta and v.1.11.0-beta in the two months before it. The 1.11 line is labelled beta and the 2.0 line is at release candidate. Nothing in the README says a stable 2.0 has shipped. An organizer with a fixed on-sale date should confirm which tag they are deploying and what the upgrade path between them looks like, because the README does not document rollback.
The third limitation is the one that applies to every self-hosted ticketing system: you are the on-call rota. A ticket on-sale is a traffic spike with a hard deadline, and the README's Docker instructions cover starting the stack, not scaling it, backing it up, or recovering it. The last push to the repository was on 2026-09-09, so the project is not dormant, but activity in the repository does not answer questions about your instance at 10am on the morning tickets go live.
Hi.Events compared with pretix and hosted platforms
The obvious open-source comparison is pretix, and the difference is architectural rather than cosmetic. Pretix is a Python and Django application with a plugin system at its centre; Hi.Events is a Laravel and React application with a documented REST API and an OpenAPI spec served from the instance itself. If your team writes PHP, or if you want to extend the checkout by editing a Laravel codebase directly rather than building a plugin against someone else's extension points, Hi.Events is the shorter path. If you want a plugin ecosystem that already exists and a longer track record of large-scale deployments, pretix is the more conservative choice.
The comparison against hosted platforms like Eventbrite or Tickettailor is a different trade. Those services take a per-ticket cut and keep the attendee relationship; Hi.Events gives you the attendee list, the checkout under your domain, and the ability to export it, at the cost of running the infrastructure and accepting the attribution terms. The README also lists affiliate tracking, outgoing webhooks, promo codes with gated and hidden tickets, sold-out waitlists, and CSV/XLSX export of attendees, which are the features that usually decide whether a migration is realistic.
One honest caveat on the feature list: it is a list of capabilities, not a statement about depth. The README does not say how many payment providers beyond Stripe Connect are supported, so if you need a second processor, check the documentation before assuming it exists.
Maintenance, upgrades and what the licence obliges you to do
The repository is not archived and the last push was on 2026-09-09. Releases are frequent enough that the changelog matters: v1.11.0-beta, v1.11.1-beta and v2.0.0-rc.1 all landed within roughly seven weeks. That pace is good for fixes and awkward for operators, because beta and release-candidate tags mean you should be reading release notes before pulling, not after.
The upgrade mechanics are only partially documented in the README. For the Docker path, the README shows how to start the stack but not how to migrate an existing database between versions. The full installation guide on hi.events/docs is the place to look, and the repository's INSTALL_WITHOUT_DOCKER.md covers the non-container case. Budget for a staging instance that mirrors production, because the README does not describe a rollback procedure.
On licensing, the practical obligations are: keep the attribution on generated pages and emails unless you hold a commercial licence, and understand that AGPL-3.0 reaches network users of modified versions. If you fork Hi.Events and run it as a service, the copyleft terms are not the same as a permissive licence. This is not legal advice; the LICENCE file and a lawyer are the right sources. The CLA.md at the repository root also matters if your team plans to contribute patches back, since contributors sign it.
Editorial conclusion
Adopt Hi.Events if you run your own infrastructure, want the attendee list and the checkout under your own domain, and can live with the "Powered by Hi.Events" attribution that the additional terms require on generated pages and emails. Do not adopt it if you need a vendor to be accountable for uptime during a ticket on-sale, or if your legal review cannot accept AGPL-3.0 with additional terms. Before committing, read LICENCE in full, confirm the all-in-one image exposes PostgreSQL and Redis as you expect on port 8123, and decide whether the v2.0.0 line, which is still at release candidate, is the branch you want to run in production.
Frequently asked questions
What is Hi.Events?
Hi.Events is an open-source event management and ticket selling platform built with Laravel, React, PostgreSQL and Redis, distributed under AGPL-3.0 with additional terms. It can be self-hosted via Docker or used through Hi.Events Cloud, the managed version run by the same team.
How does Hi.Events compare with pretix?
The README does not compare the two directly. What it does show is that Hi.Events is a Laravel and React application with a REST API and an OpenAPI spec served at /docs/api, whereas pretix is a Python and Django project. The choice usually comes down to which stack your team can operate and extend.
What is a Hi.Events alternative?
The README names Eventbrite, Tickettailor and Dice.fm as the platforms Hi.Events is an open-source alternative to, and the repository topics list attendize-alternative, eventbrite-alternative, tickettailor-alternative and tito-alternative. The main difference is that Hi.Events can be self-hosted, so you keep the attendee data and the checkout rather than paying per-ticket fees.
What is the cheapest ticketing platform?
The README does not compare pricing across platforms. It does say that most ticketing platforms charge per-ticket fees, and that Hi.Events can be self-hosted, which moves the cost from a per-ticket cut to the infrastructure you run yourself.
What does event hosting mean?
The README does not define the term. In the context of Hi.Events, the platform covers online and in-person events, ticketing, attendee management, QR check-in and reporting, either on your own infrastructure or on Hi.Events Cloud.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hieventsdev-hi-events)