Open-source, headless, plugin-based, AI-native iGaming framework. Clone it, extend it, deploy it - without forking core.

The platform ships the backend surface (auth, wallet, player management, compliance, audit, chat, backoffice) as composable modules and a typed SDK. Game lobby and CMS are early; bonuses, tournaments, affiliates and jackpots are not built yet - the order is being picked in Discussions. Your frontend, branding, and vendor adapters live in your own consumer repo and talk to it over HTTP. Nothing operator-specific lives here.

• Headless by design - backend modules, contracts, and an SDK consumption surface only. No UI ships here; you own the frontend.
• Plugin host - typed plugin objects are the single way new functionality enters the system. Overlay a folder or install an npm package; same contract.
• Zod-first contracts - every shape is a Zod schema; types are inferred, never hand-written. Routes are oRPC on Hono with a live OpenAPI reference.
• Explicit wiring - a small functional DI container with typed tokens. No decorators, no auto-discovery; everything is greppable.
• Swappable vendor seams - PSP, KYC, aggregator, chat, realtime transport, job queue, and message broker are ports with default in-process drivers and adapter overrides.
• Regulatory audit log - append-only, sha256 hash-chained. Every state-changing action leaves a trail.
• AI-native - scaffolders as slash commands, a queryable MCP dev server, and a generated machine-readable catalog.json.

• Requirements
• Quick start
• How it fits together
• Extending the platform
• Build your own iGaming on top
• Frontend
• Roadmap
• Documentation
• Community
• Contributing
• Security
• License

Node 26+, pnpm 11+, Docker.

Two ways to get the API up at http://localhost:3001. Demo credentials after seeding: admin@oss.dev / password123.

For agents (Claude Code, Copilot, Codex, Cursor) and anyone who wants a single onboarding step.

pnpm setup   # checks prereqs, installs deps, boots Postgres, runs migrations, prints a summary
pnpm db:seed          # demo data: admin + players + wallets + transactions + games
pnpm dev           # api :3001

The oss-dev MCP dev server is wired in .mcp.json (stdio, launched by the editor - no port). It exposes the schema registry, route catalog, plugin manifest, and scaffolders as tools so an agent can extend the platform without re-asking the same questions each session.

claude mcp list    # verify the oss-dev server is connected

Then use list-modules, list-routes, get-drizzle-schema, propose-table-change, docs-search, db-query-readonly, and the scaffold-* tools. See docs/guides/agent-quickstart.md.

pnpm install                                  # install workspace deps
docker compose up -d                          # start Postgres + Redis (library-first: no app containers)
pnpm gen:drizzle             # generate Drizzle migrations
pnpm db:migrate                            # apply them
pnpm db:seed                                     # demo data
pnpm dev                                      # api :3001

pnpm db:seed is idempotent and deterministic. Flags: --players=<n>, --admin-email=<e>, --admin-password=<p>.

To run the whole reference stack in containers instead of on the host, use the opt-in profile: docker compose --profile full up --build (api :3001, web :3000, backoffice :3002).

The platform is a pnpm + Turbo monorepo. @openora/core is the single published package, exposing subpaths (/contracts, /server, /react, and one per domain). Domains are wired into a domain-agnostic runtime through the composition root; overlay plugins extend it without touching core.

apps/examples       # consumer reference implementation
apps/mcp-server-dev # MCP dev server (stdio) for agents
packages/core       # @openora/core - contracts, server engine, react SDK, all 15 modules
extensions.config.ts# the single registry of enabled plugins

See docs/platform/architecture.md and the pillars + decision tree in AGENTS.md.

pnpm gen module <domain> <name>

Generates the module under packages/core/src/<domain>/<name>/, wires its domain barrels, @openora/core exports, contract slice, and extensions.config.ts entry. Run pnpm regen && pnpm verify. See AGENTS.md for the full decision tree.

Drop a folder under extensions/<name>/ or point to an npm package. Both use the same plugin-object contract:

// extensions/my-feature/plugin.ts
import type { CoreTokenCatalog, Plugin } from '@openora/core/server';

export default {
  id: 'my-feature',
  dependsOn: ['identity', 'wallet'], // optional load-order hint
  register(ctx) {
    ctx.provide(MY_ADAPTER, () => new MyAdapter()); // bind a vendor seam
    ctx.routers.add('myFeature', (c) => createMyRouter(c)); // oRPC router
    ctx.events.on('wallet.deposit.completed', handler);
    ctx.mcp.tool({ name: 'my-tool', description: '...', handler });
  },
} as const satisfies Plugin<CoreTokenCatalog>;

Then register it in extensions.config.ts.

Scaffold a consumer turborepo that links this checkout - it holds only what's unique to your operation (frontend, branding, vendor adapters, overlay plugins). Core is consumed as linked @openora/* packages, never forked.

pnpm create:app ../my-igaming --name my-igaming
cd ../my-igaming && pnpm install && pnpm dev

See docs/guides/downstream-consumer.md for the full guide.

The platform is headless and ships no UI - backend modules + contracts + the SDK consumption surface only. The frontend (pages, components, styling, theme) lives in your consumer repo and talks to the api over HTTP via @openora/core/react (data hooks, auth, navigation, typed client). Use whatever UI stack you like.

Planned work and progress live on the public board: openora roadmap. Have a request or found a gap? Open an issue and we triage it onto the board.

docs/ holds one folder per kind, plus the generated catalog.json.

• docs/platform/ - what the platform is: introduction, core concepts, architecture, system design, glossary.
• docs/guides/ - how to do a job: quickstart, agent quickstart, agentic workflow, consuming downstream, MCP setup.
• docs/standards/ - the rules a change must follow (money, custody, database, types, testing...).
• docs/adapters/ - binding a vendor behind a port (payment, custody, KYC, notification, error tracking).
• docs/modules/ - a module's own surface and invariants (wallet).
• docs/adr/ - why each decision was made.
• docs/catalog.json - the generated module/route/table/event surface. Never hand-edited.
• Pillars & decision tree: AGENTS.md

GitHub Discussions is where the project talks.

• Q&A - something does not run, or the docs do not cover it.
• Ideas - propose a module, an adapter, or a contract change; RFCs land here before any code.
• Announcements - releases, breaking changes, roadmap updates.
• General - introductions, what you are building, architecture talk.

Picking the next module happens in the open: What should we build next?

Contributions are welcome. Read CONTRIBUTING.md for the workflow, then run pnpm verify (typecheck + unit tests + lint + module-shape + boundary gate) before opening a PR. By participating you agree to the Code of Conduct.

Please do not file public issues for vulnerabilities. See SECURITY.md for private reporting.

Dual-licensed: AGPL-3.0-only OR a commercial license.

• Open source: GNU AGPL v3. If you self-host, modify, or redistribute, you must make your complete corresponding source available under the same terms. Section 13 extends this to network/SaaS use - running a modified version as a hosted service obliges you to offer its source to users.
• Commercial: for closed-source/SaaS deployments that cannot meet the AGPL's copyleft and network-use obligations, Blurify offers a separate commercial license. See LICENSE-COMMERCIAL.md - contact contact@openora.ai.

See NOTICE for the attribution and dual-license summary.

Copyright (c) 2026 Blurify and contributors.