Guide · August 1, 2026

How to deploy QM (and when you shouldn’t)

QM is the multiplayer agent harness Y Combinator built to run itself, open-sourced under MIT in late July 2026. Every person in an org gets an isolated agent workspace — scoped memory, files, keychain, crons, a durable sandbox — and shared rooms and projects for working together, in Slack and on the web. The core is harness-agnostic: Pi, OpenCode, Codex, and Claude Code can all drive it, so a deployment isn't tied to one vendor.

This guide covers what a real deployment involves, the fastest supported path, and — just as important — the cases where deploying QM is the wrong move for you. It reflects the public repository as of August 1, 2026; QM is young and moving fast, so check the repo's own docs for anything load-bearing.

What a QM deployment actually is

QM is not an app you install; it's a small fleet you operate, in your own cloud account. A deployment comprises a headless core (API, identity, policy, scheduler, agent loop), a Postgres database, per-scope sandboxes, and optional surface plugins — web UI, admin panel, public portal, Slack — plus an egress proxy. The supported targets are Fly.io and AWS. YC's repository deliberately ships no production deployment workflow and no hosted option: you are the operator.

Prerequisites, honestly

A cloud account you control (Fly.io or AWS) with billing enabled
Node.js and npm on the machine driving the setup
An admin email plus a verified sender for sign-in links — a Resend API key or SMTP credentials — unless you bring an external identity provider
API keys for the model/harness you'll run (e.g. Anthropic for Claude Code)
Optionally, a Slack workspace you admin (the generated app manifest wires it up)
A coding agent, realistically. The init flow materializes a deployment skill designed to be handed to one — it walks infrastructure, sign-in, connectors, Slack, and live verification
Someone to operate it. QM ships fast and describes itself as early, experimental software. Budget for pulling updates, reading changelogs, and occasionally fixing your deployment

The supported path: qm init

You don't need a source checkout. Create an empty deployment repository for your org and initialize it from the published package:

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install

Initialization materializes a deployment directory — config, provider templates, a generated deployment.md, and a deploy skill. Hand that skill to your coding agent: it confirms the account and billing before mutating anything, configures email-gated web onboarding first, optionally adds connectors and Slack, deploys, and runs live checks. The provider choice matters up front — Fly and AWS produce different config, secret rules, and teardown contracts, and switching later means initializing fresh.

Pick a security posture deliberately

An org chooses one posture, and narrower scopes can only tighten it: Strict (every harness tool call pauses for human approval), Auto (the default — a classifier screens external data and tool results before they reach the model), or Dangerous (no screening, no pauses). A predeclared command policy — hard denials for things like recursive deletes and destructive SQL — applies in every posture, including Dangerous. If you're unsure, that's a sign to stay on Auto and keep approvals on for anything outward.

Customizing: deployment repo vs. private fork

Most orgs only ever need the deployment repository — config and a sandbox layer, no source checkout. If your engineers want the whole codebase alongside private customizations, QM's README documents a private fork via plain clone — and warns, correctly, against GitHub's Fork button for this: a GitHub fork of a public repo can't be made private, and forks share an object network, so commits pushed to your fork stay fetchable by SHA from the public side. Use a bare clone pushed to a fresh private repository, keep everything yours under deploy/layers/<org>/, and merge from upstream.

When you shouldn't deploy QM

Skip self-hosting — at least for now — if any of these is true:

Nobody owns operations. If no one on the team will pull upstream weekly and own the deployment when it breaks, a self-hosted harness becomes shelfware with a cloud bill.
You need a public or multi-tenant boundary. QM's own security policy is explicit that it is "not a hardened public or multi-tenant service boundary" — one deployment assumes one organization of authenticated, mutually-trusting users. Don't put strangers or customers inside one deployment; published apps' capability links are the only sanctioned external surface.
You're a solo, non-technical founder. The prerequisites above are the job description of a part-time platform engineer. Your job is a venture, not a harness — see our companion guide, QM for solo founders.
Procurement needs a vendor. QM is MIT-licensed experimental software with no SLA, no certification, and a threat model that names its own limitations. That honesty is admirable — and disqualifying for some compliance postures today.

FAQ

Is QM free?

The software is MIT-licensed and free. You pay for your own cloud infrastructure, model API usage, and — the real cost — the operator time to run it well.

Does QM require Slack?

No. Slack is an optional plugin; the web UI works without it. The Slack surface is where the "multiplayer" character shows most, though — channels, group messages, shared projects.

Can I contribute code?

Not directly — the project takes contributions as human-written prose proposals (ADRs), and the team implements. Vulnerabilities go through private disclosure, not public issues.

Is there a hosted QM?

Not from Y Combinator — deployments run in the operator's own cloud by design. If what you actually want is the outcome — an agent that launches and runs a venture — that's the hosted layer Muakkil is building; and if you do run QM, our free venture skill pack imports straight into it.

Sources: the QM repository (README, deployment and getting-started docs, security policy) and YC's announcement.