Ralex91/Rahoot: Self-Hosted Quiz Platform for Developer Events

Ralex91/Rahoot: Self-Hosted Quiz Platform for Developer Events

Running interactive quizzes for team events, workshops, or meetups typically means accepting opaque data practices, recurring SaaS fees, and limited customization. For developers and DevOps^{↗ Bright Coding Blog} teams who already maintain infrastructure, this trade-off feels unnecessary. Ralex91/Rahoot offers a different path: a self-hosted, open-source quiz platform that you control entirely.

Built in TypeScript and distributed under the MIT License, Ralex91/Rahoot lets you deploy a fully functional quiz system on your own server. With 959 GitHub stars and active maintenance through mid-2026, it has attracted a community of developers who need event tooling without platform lock-in. This article examines what Ralex91/Rahoot actually delivers, how to deploy it, and where it fits in your stack.

What is Ralex91/Rahoot?

Ralex91/Rahoot is a self-hosted, open-source quiz platform designed for smaller events. The project is maintained by Ralex91 and hosted at github.com/Ralex91/Rahoot. It is written primarily in TypeScript and released under the MIT License, giving users broad freedom to modify, redistribute, and deploy the software commercially or privately.

The project's README explicitly positions it as "straightforward" — a deliberate contrast to feature-bloated enterprise alternatives. Ralex91/Rahoot provides core quiz functionality: a manager interface for hosts, participant join flows via room codes, real-time question delivery, and answer collection. The system is architected around WebSocket communication, enabling synchronous gameplay without polling overhead.

With 959 stars and 22 forks as of the last commit on July 14, 2026, Ralex91/Rahoot sits in a sweet spot of proven utility without the complexity of larger platforms. The Docker^{↗ Bright Coding Blog} image has accumulated meaningful pull volume, suggesting production deployments beyond experimental use. The project includes documentation for configuration, quiz creation, branding customization, reverse proxy setup, and even a documented WebSocket protocol for building custom hardware clients like ESP32 buzzers.

The disclaimer on the repository is worth noting: Ralex91/Rahoot is an independent project with no affiliation to commercial quiz platforms. Any resemblance to proprietary services is incidental — the codebase is original.

Key Features

Self-hosted deployment is the defining characteristic. You run Ralex91/Rahoot on infrastructure you control, with data remaining on your servers. This matters for organizations with compliance requirements, privacy-conscious events, or simply teams that prefer owning their tooling stack.

Dual deployment paths accommodate different operational preferences. Docker Compose provides a one-command setup with persistent volume mounting for configuration and quiz data. For teams already running Node.js infrastructure, native deployment via PNPM is equally supported, requiring Node.js 24+ and PNPM 10.16+.

Persistent configuration via mounted volumes solves a common containerized application pain point. The config directory maps to /app/config in the container, storing game settings and quiz definitions on the host filesystem. This enables direct file editing, backup simplicity, and state preservation across container updates. An example quiz auto-populates on first run, reducing initial setup friction.

Manager authentication enforces access control to the administrative interface. The managerPassword field in config/game.json is mandatory — the system blocks manager access if left at the default "PASSWORD" value. This is a security-conscious design choice that prevents accidental public exposure of game controls.

WebSocket-based real-time gameplay delivers questions and collects answers without page refreshes. The protocol is sufficiently documented to enable third-party client implementations, including hardware integrations.

Branding customization allows visual theming to match event or organizational identity, documented in the dedicated branding guide.

Reverse proxy compatibility is explicitly tested and documented for Traefik, Nginx, and Caddy — the three most common choices in modern containerized environments.

Use Cases

Internal team events and remote socials represent the most natural fit. Engineering teams already running Docker infrastructure can deploy Ralex91/Rahoot for trivia nights, onboarding activities, or sprint retrospective gamification without provisioning external accounts or sharing participant data with third parties.

Technical workshops and conference side events benefit from the self-hosted model. Trainers can preload quizzes relevant to session content, run them on local network infrastructure, and retain full control over question timing and participant data. The room code system scales to smaller event sizes without requiring user registration systems.

Educational environments with strict data policies find Ralex91/Rahoot compatible with institutional requirements. Student participation data never leaves controlled infrastructure, and the MIT License permits institutional modification without legal review of proprietary terms.

Custom hardware integration projects leverage the documented WebSocket protocol. The ESP32 buzzer example in documentation suggests Ralex91/Rahoot serves as a backend for physical computing experiments, escape room installations, or maker fair demonstrations where off-the-shelf quiz apps lack integration flexibility.

Privacy-sensitive organizations in healthcare, finance, or government sectors can evaluate Ralex91/Rahoot against internal security requirements rather than relying on vendor compliance attestations. The complete source code visibility supports this use case directly.

Installation & Setup

Ralex91/Rahoot supports two deployment methods. Choose based on your existing infrastructure and operational preferences.

Docker Deployment (Recommended)

The Docker path minimizes dependency management and provides consistent environments across development and production.

Using Docker Compose:

# Clone or navigate to the repository directory where compose.yml exists
docker compose up -d

The -d flag detaches the process. The compose.yml file in the repository defines the service configuration.

Using Docker directly:

docker run -d \
  -p 3000:3000 \
  -v ./config:/app/config \
  ralex91/razzia:latest

For teams preferring GitHub Container Registry over Docker Hub:

docker run -d \
  -p 3000:3000 \
  -v ./config:/app/config \
  ghcr.io/ralex91/razzia:latest

The -v ./config:/app/config mount is critical: it persists your game.json configuration and quiz files on the host. Without this volume, container recreation destroys your data. The directory initializes automatically with an example quiz on first run.

Access the application at http://localhost:3000 after container startup.

Native Node.js Deployment

For teams running Node.js services or preferring direct process management:

# Clone the repository
git clone https://github.com/Ralex91/Razzia.git
cd ./Razzia

# Install dependencies with required package manager
pnpm install

Development mode with hot reloading:

pnpm dev

Production build and start:

pnpm build
pnpm start

Native deployment requires Node.js version 24 or higher and PNPM version 10.16 or higher. The README explicitly specifies PNPM over npm or yarn — this is a hard requirement, not a suggestion.

Real Code Examples

The Ralex91/Rahoot README provides configuration and deployment examples. Below are the documented snippets with context.

Required Manager Password Configuration

Before any deployment goes live, you must set the manager password. The system enforces this at the configuration level:

{
  "managerPassword": "PASSWORD"
}

Replace "PASSWORD" with your chosen value. The README states unequivocally: managerPassword must be changed from the default, otherwise manager access is blocked. This is not optional hardening — it is a functional gate. Place this file at config/game.json relative to your project root or mounted volume.

Docker Compose Service Definition

While the full compose.yml is not reproduced in the README body, the one-line invocation implies a standard service definition. The direct Docker run equivalent shows the port and volume mapping explicitly:

docker run -d \
  -p 3000:3000 \
  -v ./config:/app/config \
  ralex91/razzia:latest

Breaking this down: -d runs detached; -p 3000:3000 exposes the application port; -v ./config:/app/config mounts host configuration into the container; ralex91/razzia:latest pulls the current stable image. The latest tag follows Docker conventions — pin to a specific digest in production for reproducibility.

Native Build and Start Sequence

For Node.js deployments, the documented production sequence is:

pnpm build
pnpm start

pnpm build compiles TypeScript and bundles assets. pnpm start launches the production server. The README does not specify a process manager — in production, consider wrapping with systemd, PM2, or your orchestrator of choice.

These three examples represent the complete code surface documented in the README. The project prioritizes operational simplicity over extensive configuration examples, which aligns with its "straightforward" positioning.

Advanced Usage & Best Practices

Volume backup strategy: The config directory contains your operational state. Include it in your existing backup regime — simple file copy or snapshot tools suffice. The flat JSON and markdown^{↗ Smart Converter} quiz formats are human-readable, aiding disaster recovery without specialized tooling.

Reverse proxy TLS termination: The README documents Traefik, Nginx, and Caddy specifically. Terminate TLS at your reverse proxy and forward to Ralex91/Rahoot's HTTP port. The application does not appear to handle TLS natively — this is standard for containerized services but worth confirming in your deployment.

Custom client development: The WebSocket protocol documentation enables building alternative frontends or hardware interfaces. For events requiring physical buzzers, custom mobile applications, or accessibility adaptations, this protocol specification is your integration point. Evaluate message formats before committing to hardware builds — the README points to docs/websocket-protocol.md for specifics.

Quiz versioning: Quiz files live as flat files in the mounted config directory. Track them in your preferred version control system to enable collaborative editing, review workflows, and rollback capability. This "infrastructure as code" approach to event content is natural for developer teams.

Resource planning: The README targets "smaller events." For larger deployments, benchmark concurrent WebSocket connections against your infrastructure. The TypeScript/Node.js stack handles moderate concurrency well, but the project does not claim enterprise scale — plan load testing for events exceeding the documented sweet spot.

Comparison with Alternatives

Ralex91/Rahoot occupies a distinct position: lower setup friction than a custom build, with data control and customization depth unavailable in commercial SaaS alternatives. The trade-off is operational responsibility — you manage uptime, updates, and scaling. For teams already running container infrastructure, this overhead is marginal. For one-off events without technical staff, commercial SaaS may prove simpler despite limitations.

FAQ

What license covers Ralex91/Rahoot? MIT License. Commercial use, modification, and redistribution are permitted with attribution.

What are the exact Node.js requirements? Node.js 24 or higher, PNPM 10.16 or higher. npm and yarn are not documented as supported.

Can I run Ralex91/Rahoot without Docker? Yes. Native deployment via git clone, pnpm install, pnpm build, pnpm start is fully documented.

Where is quiz data stored? In the mounted config directory on your host filesystem, persisted across container restarts and updates.

Is there a default manager password? The placeholder is "PASSWORD", but manager access is blocked until changed. This is enforced, not merely recommended.

Does Ralex91/Rahoot support custom themes? Yes. Documentation covers branding customization in docs/branding.md.

Can I build a custom buzzer or mobile client? The WebSocket protocol is documented at docs/websocket-protocol.md for this purpose.

Conclusion

Ralex91/Rahoot delivers exactly what its README promises: a straightforward, self-hosted quiz platform for smaller events. It does not attempt to compete with commercial SaaS on convenience or enterprise scale. Instead, it offers developer teams something more valuable — complete control over data, infrastructure, and customization.

The 959-star project is best suited for technical teams already comfortable with Docker or Node.js deployment, organizations with privacy requirements that preclude third-party SaaS, and builders who want to extend quiz functionality through custom clients or hardware. The MIT License removes legal friction for commercial and educational use alike.

If your next team event, workshop, or installation needs interactive quiz functionality without platform dependency, evaluate Ralex91/Rahoot directly. The repository includes everything needed to assess fit: documented deployment paths, configuration examples, and a complete protocol specification for extensions.

Start with the repository at https://github.com/Ralex91/Rahoot — clone it, run docker compose up -d, and have a working quiz platform in minutes.