Which integrations does Workhorse support?
The two support tiers, what each one proves, and every integration Workhorse documents.
Every catalog of integrations makes the same silent promise: that the things it lists work. Most cannot keep it, because a page written once and never run again ages into fiction while still reading as fact. Before you adopt anything below, you need to know which claims a machine re-checks and which claims a person made on a particular day.
Workhorse separates them into two tiers and never mixes them.
The two tiers
Verified. Workhorse publishes a package for it, and continuous integration exercises that package against the real tool on every change. The four ORM adapters run through a shared conformance suite that opens actual transactions; the dashboard is built and typechecked against the React version it declares. Breaking one of these fails the build before it can ship, so the version listed beside a verified integration is the version something ran against, not the version someone remembered.
Documented. Workhorse publishes no package, and nothing in continuous integration proves the claim. The page describes how the platform behaves and where its boundary is, checked by hand on the date it names. A documented page is still worth reading — it is how you learn that a request invocation cannot host a worker — but the platform can change underneath it without anything here turning red.
The tier is the only thing that decides how much a page proves. Neither tier means Workhorse maintains the tool, and no page below implies that a platform's vendor tests against Workhorse.
What every page owes you
The catalog is cheap because Workhorse asks so little of an integration. An ORM only has to hand
back something that can run a parameterized query, which is the Queryable protocol; the adapter
converts the database and transaction objects your application already holds, and Queue.enqueue
runs inside the transaction you opened. Nothing is proxied, and Workhorse never opens a transaction
on your behalf.
So every page here answers the same four questions, and the entry below it repeats the last two so you can compare without opening anything:
- What it is — the one line that says what the integration converts or decides.
- The boundary — where it stops, stated before you depend on it.
- A sample you can run — verified against the source, not written from memory.
- What proves it — the tested version for a verified integration, or the date a person last checked a documented one.
The catalog
ORMs and query builders
How do I enqueue inside the transaction my ORM already opened?
Adapts Drizzle databases and caller-owned transactions.
Workhorse stays outside your Drizzle migration graph and keeps its own schema lifecycle.
Tested against drizzle-orm ^0.45.2 on every change · supports >=0.45.0 <1
Adapts Prisma clients and interactive transactions.
Workhorse keeps its schema lifecycle outside Prisma migrations.
Tested against @prisma/client 6.19.3 on every change · supports >=6 <7
Adapts TypeORM data sources and transactional entity managers.
Workhorse keeps its schema lifecycle outside TypeORM migrations.
Tested against typeorm 0.3.31 on every change · supports >=0.3 <2
Adapts Kysely databases and transaction executors.
Workhorse keeps its schema lifecycle outside Kysely migrations.
Tested against kysely 0.29.5 on every change · supports >=0.29 <0.30
Runtimes
Can my platform enqueue, and where does the worker run?
Decides where a serverless platform can enqueue and where its worker must run.
No platform hosts a worker from a request invocation, and an edge runtime may not connect at all.
Checked by hand on 2026-08-18
Application frameworks
I already have a web framework. What changes?
Wires Workhorse into an application that already has a web framework.
Workhorse publishes no framework package, and a web process never owns a worker.
Checked by hand on 2026-09-02
Operator surfaces
How do I give my operators a view of the queue?
Embeds the operator interface in a TypeScript, Python, or Go HTTP server.
The dashboard reads PostgreSQL through the versioned dashboard contract and owns no authorization of its own.
Tested against react ^19.1.1 on every change · supports >=19 <20
Adding an integration
An integration is one MDX file under site/content/docs and one entry in site/integrations.json.
The entry decides the sidebar order, the tier, the category, and the landing page copy; nothing
else needs editing, and a test fails if a page and an entry disagree. Version numbers are not
written by hand anywhere: a verified entry names the package it adapts, and the build reads the
supported range and the tested version out of the package.json files that already declare them.
Next
- Compatibility — the runtime and database matrix, and what "supported" proves
- Transactional enqueue — the guarantee every ORM adapter exists to preserve
- Limitations — the boundaries no integration removes
Exact peer requirements and package inventory: compatibility reference.