# Eventyay is a Django and Vue event platform developed since 2014

> Eventyay is FOSSASIA's open source event management platform covering ticketing, CFP, scheduling, video and check-in, built on Django 5.2 with PostgreSQL, Redis and Celery. Its own README is explicit that dev is the branch to target and that its components were historically separate.

**fossasia/eventyay** — Open Source Event Management, Ticketing and Checkins, Talks and Schedules, Video and Interpretations, Badges, Exhibitions and more https://eventyay.com

- Repository: https://github.com/fossasia/eventyay
- Website: https://eventyay.com
- Stars: 1,713 · Forks: 533
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/fossasia-eventyay

## main is production, dev is where you send the pull request

The README opens with a branch model rather than a feature list, which tells you what kind of project this is.

The default branch of the repository is `dev`, and the stated model is that `main` is the production ready branch while `dev` is the testing and active development branch. Pull requests should normally target `dev`. Changes are tested and stabilised there before being moved to `main`.

There are no GitHub releases. Combined with a last push on 2026-10-16 and a README that says Eventyay is actively developed, that means the deployable artefact is a branch, not a version. If you self-host, you are choosing a commit, and the README's `DEPLOYMENT.md` is where that decision is documented rather than in release notes.

The project's history explains the current shape. Eventyay has been in development since 2014, and parts of the system historically originated from separate components for tickets, talks and video. The current repository contains the unified codebase. That sentence is doing real work: it warns you that a unified platform born from three products will have seams where a ticket system meets a video system, and it explains why the README still points at separate Eventyay components, including the Eventyay Checkin component for separate check-in stations.

For a contributor, the other visible signals are the presence of `CONTRIBUTING.md`, `agents.md`, `.cursorrules`, `CODEX.md` and `.coderabbit.yaml` at the root. Those are agent and automation configuration files committed to the repository, which tells you the project expects AI-assisted contributions and has rules for them.

## The Docker stack starts six things, and the compose file names them

Docker is the recommended quick start, and the README lists the requirements as Docker, the Docker Compose plugin and Git. The local stack starts the Django web service, a Celery worker, Celery beat, Redis and PostgreSQL, and mounts `./plugins` for local plugin development.

The compose file is more specific than the prose. It is named `name: eventyay-next`, which tells you this is the next generation of the platform rather than the original. The web service builds from `./app`, runs `python manage.py runserver 0.0.0.0:8000`, and is named `eventyay-next-web`.

```bash
git clone https://github.com/fossasia/eventyay.git
cd eventyay
git switch dev

cp deployment/env.dev.sample .env.dev

docker compose up -d --build
```

Ports published by the web service are 8000, 8080, 8082, 8085 and 8880, which is a hint that the frontend sub-applications have their own dev servers rather than being served by Django alone.

The worker service is worth reading closely because it encodes the queue topology:

```yaml
command: celery -A eventyay worker -l info -Q default,notifications,longrunning,background
```

Four queues, with a comment in the file noting that production uses `worker` plus `worker-heavy` from `deployment/docker-compose.yml`. So the queue split is a design decision, not a default: notifications, long-running work and background work are separated so a slow task does not delay an email.

Admin creation and shutdown are one-liners, and the container name in the README matches the compose file:

```bash
docker exec -ti eventyay-next-web python manage.py create_admin_user
docker compose logs -f
docker compose down
```

The site then answers on http://localhost:8000.

## Running without Docker means Postgres, Redis, uv and four build steps

The local Python setup is for people who want services on their own machine, and it is longer than the Docker path.

Requirements are Python 3.12, uv, PostgreSQL, Redis, Node.js and npm, plus the Debian or Ubuntu packages listed in `deb-packages.txt`. That file is meant to be piped straight into the package manager:

```bash
xargs -a deb-packages.txt sudo apt install
```

The README also gives the Nushell equivalent, which tells you the maintainers expect a range of shells. On another distribution you install the corresponding packages yourself.

PostgreSQL setup has a specific default name, `eventyay-db`, and a recommended peer mode path. Creating a PostgreSQL user matching your Linux user avoids specifying a password, host or port:

```bash
sudo -u postgres createuser -s "$USER"
createdb eventyay-db
```

If peer mode is unavailable, the alternative is a local config file at `app/eventyay.local.toml`:

```toml
postgres_user = "your_db_user"
postgres_password = "your_db_password"
postgres_host = "localhost"
postgres_port = 5432
```

Then the actual work, all from the `app` directory:

```bash
uv sync --all-extras --all-groups
. .venv/bin/activate
python manage.py migrate
python manage.py create_admin_user
make npminstall
python manage.py collectstatic --noinput
python manage.py compress --force
python manage.py runserver
```

The static pipeline is three steps rather than one: install npm packages, collect static files, then compress. That matches the README's mention of Django Compressor for selected legacy and Django integrated assets, which is the residue of a frontend that partly predates the Vue rewrite.

Background tasks need a worker alongside the server:

```bash
celery -A eventyay worker -l info
```

Two environment details are documented and both cost people time. For Android emulator testing, the host is `http://10.0.2.2:8000/`, Android's alias for the host's localhost rather than `localhost`. And permission errors on `eventyay/static/CACHE` mean the directory and everything below it must be owned by your user.

## Plugins are discovered and URL-registered, and the check-in station is separate

The plugin system is how the platform covers territory it does not implement itself.

The README lists plugin discovery and plugin URL registration as features, along with standard plugins and external plugin extensions for payments, CRM, exhibitions, social media, team shifts, interpretation and spatial event integrations. The domains in that list are exactly the ones a conference needs but a general platform cannot own: payment processors differ by country, interpretation depends on the event format, spatial integrations depend on the venue.

Mechanically, the local Docker stack mounts `./plugins` into the container at `/usr/src/plugins`, and the compose file also mounts a plugin's `node_modules`. So a plugin is a directory with Python and possibly its own frontend, mounted rather than copied, which is what makes live plugin development possible in the same way `app/eventyay` is mounted.

Check-in is the clearest example of the split architecture. The README lists separate check-in station support through the Eventyay Checkin component, and the compose file mounts `/usr/src/plugins/eventyay-checkin/node_modules`. That plugin path plus the separate component naming tells you the architecture rule: anything that must run on a staff laptop at the door is a separate component talking to the main system, not a page served from the main server.

Two frontend directories with their own `node_modules` mounts, `webapp/video` and `webapp/schedule-editor`, plus `webapp/schedule`, follow the same logic. Those mounts show separate frontend dependencies, but do not by themselves establish the number of applications or dev servers.

The backend stack behind all of this is Python 3.12, Django 5.2, Django REST Framework, PostgreSQL, Redis, Celery, Django Channels with Daphne or ASGI, Pydantic settings and uv for dependencies. Django Channels and ASGI are what make live schedule updates and check-in sync possible rather than polled.

## Where the scope ends, and what to check before adopting

Three boundaries are visible without reading the source.

Scope is broad but not infinite. The feature list includes event ticketing and registration, item sales such as shirts or add-ons, organiser and event administration, CFP workflows, speaker, submission, review and schedule management, public event pages, schedule display and schedule editor frontends, online event and video workflows, PDF ticket and badge workflows, REST API endpoints, OAuth and social authentication, multi-domain and multi-event handling, email, notifications, scheduled tasks, reports, statistics and check-in lists, health check and metrics endpoints, and internationalisation with a hosted Weblate based browser translation workflow.

What is absent is equally informative. There is no statement about mobile apps, no native client, and no mention of a specific payment provider working out of the box. Payments appear as a plugin category, so the first integration is your work.

The operational surface is the real constraint. This is a multi-service system with Celery queues, Redis, Postgres, three frontend applications and a plugin mount, and the README's own advice is that Docker is for local development and first testing, with production deployment documented separately in `DEPLOYMENT.md`. Someone has to run that.

Internationalisation deserves attention for a European or Asian conference: Weblate is browser-based, hosted, and the workflow is community translation rather than a file-based one. That is efficient and it means your strings live in a hosted tool rather than only in the repository.

Licence is Apache-2.0, with both `LICENSE` and `NOTICE` files at the root, and the repository has a `CLA.md`. Apache-2.0 permits commercial self-hosting and modification, which is what a foundation-run project needs to be adopted by organisations that resell event services.

## Conclusion

Eventyay fits a community or conference organiser who needs ticketing, a call for participation, a schedule and on-site check-in in one self-hosted system, and who can run PostgreSQL, Redis and a Celery worker. It does not fit a small one-off event, because the deployment surface is multi-service that is only worth it when the workflow demands it. Verify first by starting the Docker stack on the dev branch, creating an admin user with `docker exec -ti eventyay-next-web python manage.py create_admin_user`, and checking that port 8000 serves, because the repository is on dev with no GitHub releases, so the stability you get depends on that branch rather than on a tag.

## FAQ

### How do I run Eventyay locally with Docker?

Clone the repository, switch to the dev branch, copy deployment/env.dev.sample to .env.dev, then run docker compose up -d --build. Create an admin with docker exec -ti eventyay-next-web python manage.py create_admin_user and open http://localhost:8000.

### Which branch should I deploy Eventyay from?

The README states that main is the production ready branch and dev is the testing and active development branch, with pull requests normally targeting dev. The repository publishes no GitHub releases, so you deploy a commit rather than a tag.

### What services does Eventyay need to run?

PostgreSQL, Redis and a Celery worker alongside the Django web service, plus Node.js and npm for the frontend build. The local Docker stack starts the web service, a Celery worker, Celery beat, Redis and PostgreSQL.

### How do plugins work in Eventyay?

Plugins are discovered and their URLs registered by the framework, and the Docker stack mounts ./plugins into the container so you can develop them live. Standard and external plugin extensions cover payments, CRM, exhibitions, social media, team shifts, interpretation and spatial integrations.

### Can Eventyay run check-in on a separate machine?

Yes. The README lists separate check-in station support through the Eventyay Checkin component, and the compose file mounts a plugin path for eventyay-checkin, indicating the door workflow runs as its own component against the main system.

## Sources

- [fossasia/eventyay on GitHub](https://github.com/fossasia/eventyay)
- [Issues](https://github.com/fossasia/eventyay/issues)
- [License: Apache-2.0](https://github.com/fossasia/eventyay/blob/dev/LICENSE)
- [Project website](https://eventyay.com)
- [README](https://github.com/fossasia/eventyay/blob/dev/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fossasia-eventyay