QuizDock
Menu

QuizDock in an organisation

Single sign-on with your OpenID Connect provider, host and administrator roles, a web administration, an audit trail of every change, and settings the operator keeps under control.

QuizDock is open source under the MIT licence. There is no paid edition and no contractual support. Everything on this page is in the image anyone downloads.

From a first test to production

  1. Evaluation: the live demo, then ./quizdock init --full on a test machine, with Keycloak and two sample accounts.
  2. Validation: Compose on your infrastructure, behind your reverse proxy, sized from the published measurements.
  3. OIDC: connect your identity provider.
  4. Roles: decide who hosts and who administers.
  5. Administration: accounts, quizzes, media, statistics from the browser.
  6. Audit: every change recorded, from the web and the command line.
  7. Governance: what the web may change, and what it never may.
  8. Operations: backup, upgrade, health, sizing.

The full setup creates a host account (roles host and admin) and a player account, with temporary passwords written in .env (mode 600) and changed at first sign-in.

Choose a deployment →

How does sign-in work?

With AUTH_MODE=oidc, QuizDock signs people in through your OpenID Connect provider: discovery, authorization code with PKCE, refresh, signing keys, logout at the provider. A public client (PKCE) or a confidential one (with a secret) both work. The backend holds the tokens in Redis; the browser gets an HttpOnly cookie, and a session unused for 24 hours is forgotten.

The protocol is standard; the testing is not universal. Keycloak is the provider the project tests and ships, with a ready realm in the full setup. Other providers have not been tested by the project.

Connect an identity provider →

Who can do what?

  • Participant: joins rooms. Every account is at least a participant.
  • Host: creates, edits and presents their own quizzes.
  • Manager (admin): reads the whole instance and administers it. Managing is not hosting: an administrator without the host role presents nothing.

Roles are read from a claim of the token (OIDC_ROLES_CLAIM: roles, groups, or a path such as realm_access.roles), or granted on Administration › Accounts or with ./quizdock user:set-role. A grant is never lowered by the token.

Under OIDC every participant signs in. If the operator sets ALLOW_ANONYMOUS_PARTICIPANTS=true, a host may open a game to the PIN and a nickname instead; nothing is then kept per person.

Accounts and roles →

What can administrators see and do?

  • Statistics: games under way (refreshed every 5 seconds), the instance at a glance, twelve months of history.
  • Quizzes: every quiz, by owner and status, quizzes nobody can reach; open, export, hand over, archive, restore, delete; import for an account; purge old sessions.
  • Media: disk use by owner and kind, usages, clean-up, media offered to every host.
  • Accounts: search, roles, quizzes and games per account, the local host seat.
  • Settings, Health and Audit.

Destructive operations ask for confirmation; several offer a preview first.

The Statistics page of the administration: games under way, the instance at a glance and the history by month
Statistics: what is played now, and over twelve months.

The administration →

Is every change recorded?

Yes. The audit records each administrative change: when, who and how (Web or Command line), the client address, the operation, its parameters with secrets masked, the outcome (Done, Nothing to do, Partly, Refused, Failed) and what it replaced. Refused attempts are recorded; reads and the hosts' own edits are not. Entries are never edited or deleted. From a shell, ./quizdock qd audit.list lists them, also per setting.

The audit →

What does the operator keep control of?

  • Levels. Every setting is C1 (critical: start-up, data, security), C2 (access, resources), C3 (behaviour) or C4 (look, wording). C1 is never changed from the web; C2 changes are confirmed.
  • ADMIN_WEB_SCOPE: read by default, so the web shows the instance settings, accounts and host seat but changes none of them. write allows C2 to C4. Quizzes and media are not concerned.
  • ADMIN_LOCK: variables the web never changes, whatever the scope.
  • ADMIN_OVERRIDES=ignore: start on .env alone, ignoring web changes without deleting them.

These are set in .env and read at start. The command line on the server is never limited by them.

Settings and their levels →

How is it operated?

  • Backup and restore: ./quizdock backup dumps the database (and Keycloak's in the full setup) while the instance runs, and copies media, the templates folder and .env. ./quizdock restore puts a backup back. Scheduling is yours.
  • Upgrade: ./quizdock upgrade X.Y.Z backs up, pulls, migrates, waits for health and runs doctor. No rollback but the backup.
  • Health: a public /health endpoint (status, version, authentication mode) for your monitoring; the Health page and ./quizdock doctor for the checks behind it.
  • Logs: plain text on the container's standard output, ./quizdock logs.
  • Sizing: one process on one core runs the live games. Measured with the backend on one core: 700 players in one room fluid, 1500 at the edge. Deduced from it: 2 vCPU and 2 GB up to 700, 2 vCPU and 4 GB up to 1500. No horizontal scaling.
  • Security: a distroless image running as non-root; in Compose, a read-only file system and no Linux capabilities; dependencies and images scanned for known vulnerabilities.

Sizing measured on 2026-09-27: backend on one 2.1 GHz core, players simulated on the same machine, no media. Conditions and figures.

Back up an instance →

Questions

Is there a paid edition or a support contract?

No. QuizDock is open source under the MIT licence, and everyone runs the same software. There is no paid edition, no licence key and no contractual support. Security issues are reported privately, as the project's security policy describes; fixes go to the latest release.

Does QuizDock support SSO?

Yes, through OpenID Connect: authorization code with PKCE, discovery, token refresh, signing keys, and logout at the provider. The backend keeps the tokens; the browser only holds an HttpOnly session cookie. QuizDock speaks OpenID Connect only, not SAML or LDAP.

Which identity providers are supported?

Any provider that follows the OpenID Connect standards should work. Keycloak is the one tested and shipped: the full setup includes it, with a ready realm. Other providers have not been tested by the project; test yours before relying on it.

Can administrators manage roles?

Yes. Roles come from a claim of the provider's token, and an administrator can also grant or revoke host and admin on Administration › Accounts (with ADMIN_WEB_SCOPE=write), or with ./quizdock user:set-role at any time. A grant adds to the token's claims: a role the provider gives can only be removed in the provider.

Can settings be locked by the operator?

Yes. ADMIN_WEB_SCOPE=read, the default, keeps the web administration from changing any instance setting; ADMIN_LOCK names variables it never changes even with write; critical settings (level C1) are never changed from the web. The command line is not limited by either.

Is there an audit trail?

Yes. Every administrative change, from the web or the command line, is recorded with its time, actor, client address, parameters (secrets masked), outcome and what it replaced. Refusals are recorded too; reads and the hosts' own edits are not. Entries are never edited or deleted.

Can QuizDock run behind a corporate reverse proxy?

Yes. Serve the pages, the API and the WebSocket from one origin, forward WebSocket upgrades, accept request bodies of at least 50 MB for media and imports, and set TRUST_PROXY so that QuizDock reads the client's address and marks cookies secure.