The Manifold monorepo holds the whole prediction market, not just the front end

One tree for a whole market

The README describes the repository as a monorepo that has basically everything involved in running and operating Manifold, and the directory overview makes that concrete. web/ holds the user interface and the business logic for the client, and the README says most of the site lives there, along with the public API endpoints. backend/ is everything else they run on Google Cloud. common/ is the TypeScript library code shared between web/, backend/ and shared/, and it is where the market math is, called from the bet and sellBet endpoints in functions/. docs/ is the public documentation that lives at docs.manifold.markets. The root package.json confirms the shape as a Yarn workspace with common, backend/api, backend/discord-bot, backend/scheduler, backend/scripts, backend/shared, web and client-common as the members, under the package name mantic. There is also a native/ directory, a client-common/ one, a twitch-bot/, a mani/ directory, and a dev.sh script that the dev command calls.

Getting it running on your machine

The getting started steps are short, and the first one is a version constraint rather than a command. You need Yarn 1.x, then you change into the web directory, install and start the dev build:

cd web

yarn

yarn dev:dev

and the site is available on http://localhost:3000. The dev script in the root package.json is a cross-env invocation of dev.sh with the dev environment, and it points GOOGLE_APPLICATION_CREDENTIALS_DEV at a local file named dev-mantic-markets-firebase-adminsdk.json, which tells you that a Firebase service account credential has to be present on your machine before the dev server can talk to anything. The web directory has its own README for the details of working on the client.

Where the data lives now, and where it used to

The architecture note in the README describes a migration in progress rather than a finished state. The public API and the web app are hosted by Vercel. The data was stored in Firebase's Cloud Firestore database, but the README says they have almost entirely migrated it to SQL hosted on Supabase. That is the kind of sentence worth reading twice, because it tells you that a Firestore-shaped assumption is still lurking in parts of a codebase whose data now lives in Postgres. The client often talks to Supabase directly for reads, but complicated operations, and buying shares is the example given, go through a separate internal HTTP API deployed in a Docker container on Google Cloud. That internal API is distinct from the public-facing one on Vercel, and the README points at the functions README for the details of the split.

The verification pipeline a contributor has to pass

The root scripts are worth looking at because they define what a change has to survive. There is a build:ci script that builds common and backend/shared, and a verify script that chains the whole thing:

  "typecheck": "yarn typecheck:web && yarn typecheck:api && yarn typecheck:scheduler",
  "lint": "yarn lint:common && yarn lint:api && yarn lint:shared",
  "verify": "yarn build:ci && yarn typecheck && yarn lint && yarn format:check && yarn test",

Type checking is per-project, with separate tsconfig files for web, backend/api and backend/scheduler, and the api and scheduler runs use --skipLibCheck while the web one does not. Linting is per-package too, and format checking is Prettier over web, package.json and .github. Tests run for common and backend/shared. The husky prepare script wires this into git hooks, and the tree also carries a .prettierrc, a .prettierignore and a knowledge.md alongside knowledge.cursorrules, which suggests the project keeps some of its own conventions in files meant to be read by tooling.

How the project asks for contributions

The contributing section is unusually honest about the state of the project. It says they are pretty new to open-source culture, asks for patience, invites issues, pull requests and discussion on Discord, and states a preference for small pull requests they can effectively evaluate and review, with a check-in before a big change. By contributing, you agree to the terms of the Manifold CLA in .github/CONTRIBUTING.md. There is also a practical note: if you need additional access to infrastructure to work on something, such as Vercel, Firebase or Supabase, ask on Discord. The last point is the one that tells you what contributing here is really like, because the development environment depends on credentials in the maintainers' own cloud accounts, not on a local stack you can stand up alone.

The artefacts around the code

Beyond the source, the root directory holds a set of files that are unusual for a repository and worth knowing about. There is SHOP_SYSTEM.md, perps-launch-runbook.md and a perps-model-classification-backlog.md, which read like operational notes and planning documents kept next to the code. There is a private-storage.rules and a storage.rules file, which are Firebase storage security rules, and a .firebaserc plus firebase.json for the Firebase project configuration. dev-docs/ is a separate documentation directory, and .claude/ and .cursor/ directories alongside an .mcp.json and knowledge.cursorrules suggest the project ships some of its own agent tooling configuration. A SECURITY.md is present, and the licence file is LICENSE.md. None of this is unusual for a young company that opened up its monorepo, but it does mean the repository is a working company codebase rather than a curated library.

Where this monorepo is the wrong thing to fork

Three cases. The first is a team that wants to run a prediction market on its own infrastructure today, because the documented development path points at a Vercel deployment, a Supabase database and Firebase credentials, and the internal API runs as a Docker container on Google Cloud, so standing up the whole thing means assembling four hosted services rather than one application. The second is a developer who wants to contribute a substantial feature, because the project asks for small pull requests and a check-in first, which is a reasonable request but does mean the large change has to be negotiated. The third is a team that wants to reuse just the market math, because it lives in the shared library inside this monorepo rather than in a published package with a stable API. Against a single-purpose library, the difference in approach is that Manifold is an application monorepo, so what is reusable has to be extracted, and the price of the openness is that the internals move with the product rather than with a version contract.

Editorial conclusion

Manifold is a good fit for a developer who wants to read how a prediction market is actually implemented, especially the market math in the shared library and the split between the public API and the private one, and for someone running a self-hosted instance on their own infrastructure. It is a poor fit if you want to fork and ship a hosted market quickly, because the web app and the public API are assumed to live on Vercel with Supabase behind them. Check three things before you start: that you have Yarn 1.x, since the getting started steps assume it and the repository has a .yarnrc, that you have Firebase service account credentials, since the dev script points at a local adminsdk file, and that you read the CLA in .github/CONTRIBUTING.md, because contributing to the codebase means agreeing to it and the project asks you to check in before a large change.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. manifoldmarkets/manifold on GitHub
4. Project website
5. README