eventyay-checkin: Event Check-In, Badges, and Lead Scanning

What eventyay-checkin handles at an event

eventyay-checkin targets the operational part of an Eventyay event rather than the main event website. The client is intended for organizers who need to register a device from the Connected devices screen and then select a station for that device. The documented station types are Check-In Staff, Badge Station, and Lead Scanner. This division maps directly to common event jobs: staff scan and validate tickets, attendees receive badges, and exhibitors collect and manage leads.

For a Check-In Staff station, the README lists QR or barcode scanning, attendee search, live registration processing, badge printing, and offline work after the initial sync. Badge Station is a self-service kiosk mode for attendee check-in and on-demand badge printing, but the documentation specifies online mode for this station. Lead Scanner covers exhibitor lead capture and management. The project is therefore aimed at operators who already have an Eventyay event and need a station client connected to that event's data, not at developers looking for a general-purpose ticket scanner.

Station modes and the client-side architecture

The repository describes a JavaScript client built around Vue, Vite, Vue Router, and Pinia. The package also includes QR code generation and reading libraries, PDF generation libraries, Headless UI components, and Vue I18n. This composition matches the documented jobs. QR and barcode input can be handled through `vue-qrcode-reader`, while `qrcode` supports QR generation. `pdf-lib` and `arabic-persian-reshaper` indicate that badge or label output includes PDF preparation and Arabic script handling. Pinia provides client state management, and `pinia-plugin-persistedstate` is present for persisted state.

The application calls Eventyay's `/api` interface. In local development, the README says requests to `/api` proxy to `http://127.0.0.1:8000` by default, where an Eventyay Backend may be running. The package scripts include `dev`, `build`, `preview`, unit tests, and Cypress end-to-end tests. The repository layout includes `src/`, `public/`, `docs/`, Cypress configuration, and a Dockerfile, indicating a browser client packaged as a static application rather than a server that owns the event database.

Local setup and the first real use

The README requires Node.js `v20.x` or newer and npm `v9.x` or higher. A local Eventyay Backend is optional for a full local environment. For a first developer run, clone the repository and install dependencies. The following commands are copied from the installation instructions:

git clone https://github.com/fossasia/eventyay-checkin.git
cd eventyay-checkin

The clone creates the project directory and changes into it. The README then lists `npm install` for normal installation and `npm ci` for a clean CI-style install.

npm install

After dependencies are installed, start Vite's development server:

npm run dev

The application should be available at `http://localhost:8085`. The default local configuration proxies `/api` to `http://127.0.0.1:8000`. If the backend is not running, the client can still be started for frontend development, but API-backed features such as device registration, attendee data, and event operations require a compatible Eventyay Backend. The README links to `docs/checkin.md` and `docs/exhibitor.md` for operator procedures.

Checking and validating before deployment

The repository provides separate scripts for linting, formatting, unit tests, and production builds. The documented commands are suitable for checking a change before a pull request:

npm run lint
npm run format:check
npm run test:unit -- --run
npm run build

`npm run lint` runs ESLint with zero warnings allowed. `npm run format:check` uses Prettier for unit-test files under `src/utils/__tests__/`. The Vitest command executes unit tests, while `npm run build` creates the production bundle with Vite. The package also defines `npm run test:e2e`, which starts the preview server and runs Cypress in end-to-end mode. These checks matter for this project because it combines browser hardware workflows, API state, PDF-related code, and kiosk-specific behavior, although the repository does not state that the hardware paths are covered by every automated check.

The package includes `npm run i18n:check`, which runs `scripts/check-i18n.mjs`. That is relevant because the dependency list includes `vue-i18n`, and event interfaces often need consistent translations. The README does not document a release process or a stable release version, and the repository currently has no GitHub releases. The default branch is `development`, so operators should confirm which branch or deployment artifact they intend to use.

Kiosk deployment and printer dependencies

Badge Station is the clearest example of a deployment mode that depends on the host environment. The README provides a Google Chrome command for launching a dedicated terminal with silent badge printing. It uses kiosk and kiosk-printing browser flags, then opens the production application with the kiosk query parameter:

open -a "Google Chrome" --args --kiosk --kiosk-printing --app=https://access.eventyay.com/?kiosk=true

The documented procedure is to select Badge Station, register the device, and configure the default system printer for label or badge printing. The command is specific to macOS because it uses `open` and names the Google Chrome application. The README does not provide equivalent Chrome or Windows kiosk commands, so it would be inaccurate to assume the same launch syntax works on those platforms.

Printing is also a system integration rather than a self-contained browser feature. The documentation calls for a default system printer, but it does not describe supported printer models, label sizes, print failure recovery, or offline badge generation. Those details must be checked against `docs/checkin.md` and the event's physical setup before a public kiosk is deployed.

Offline operation and container deployment boundaries

Offline support has a precise documented boundary. Check-In Staff can continue working offline after the initial sync, which is useful where venue connectivity is intermittent and staff need to search attendees, process scans, and print badges. Badge Station, however, is documented as online mode. That difference means offline availability should not be treated as a property shared by every station. The README does not state the size of the initial sync, conflict resolution rules, maximum cached event size, or behavior when a device has never synced.

The repository also includes a Dockerfile and `compose.yaml`. The Compose file defines a `server` service built from the repository, sets `NODE_ENV` to `production`, and maps host port `8080` to container port `8080`. The Dockerfile declares a default Node.js version of `18.16.0`, while the README's prerequisite section recommends Node.js `v20.x` or newer. This difference is worth resolving before using the container as the deployment baseline.

services:
  server:
    build:
      context: .
    environment:
      NODE_ENV: production
    ports:
      - 8080:8080

The Compose file does not add a database service. Its commented database example is an optional template, so the actual event data still depends on the Eventyay Backend and its API.

Alternatives, licensing, and maintenance considerations

A general-purpose QR scanning and badge-printing application is the closest alternative, but it follows a different approach. Such an application can usually read codes and produce labels independently, whereas eventyay-checkin is tied to Eventyay station registration, attendee state, live registrations, exhibitor leads, and the Eventyay `/api` contract. It is the better fit when the event data and workflows already live in Eventyay. It is the wrong choice when the requirement is a self-contained scanner with its own unrelated database or when the backend cannot be replaced by an Eventyay deployment.

The repository is licensed under Apache License 2.0. That license permits broad use of the licensed code subject to its terms, but the license file should be reviewed for obligations relevant to a particular deployment. The client package is marked private in `package.json`, and the repository has no GitHub releases. The last push was on 2026-10-06, but release maturity should still be assessed from the `development` branch, deployment process, and operator documentation rather than inferred from the repository activity alone.

For adoption, verify whether your event requires offline use from the first device startup, whether badge printing works with the selected printer and label stock, and whether the Eventyay backend can serve the configured `/api` route. Those checks are more informative than the fact that the client includes scanning, PDF, kiosk, and lead-capture components.

Editorial conclusion

Adopt eventyay-checkin for Eventyay deployments that need a dedicated check-in station, badge workflow, or exhibitor scanner. Do not choose it as a standalone check-in system without an Eventyay backend or for workflows requiring broad offline operation before the initial sync. Verify printer setup, device registration, proxy configuration, kiosk behavior, and the exact offline scope with the operator guides before deployment.

Frequently asked questions

Official sources

1. fossasia/eventyay-checkin on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README