Convex Backend: a self-hostable reactive database written in Rust and TypeScript

What Convex backend replaces in a typical web app stack

The README describes Convex as an open-source reactive database designed for web app developers, and the pitch is narrower than 'a backend'. It bundles three things that are usually separate: a database, a place to write your server functions, and client libraries. The claim is that you fetch data and perform business logic with strong consistency by writing pure TypeScript. That combination is the product. If you already have a database you like and a function host you like, Convex is asking you to give both up in exchange for one runtime where a query is a TypeScript function and the result is pushed to clients as it changes.

The audience is web app developers building dynamic, live-updating interfaces, and the README explicitly includes LLMs in that audience. The second audience is people who want the same system without the hosted service: the self-hosted product includes most features of the cloud product, including the dashboard and CLI. That last detail matters. Many open-source backends ship a server and leave the dashboard, CLI and admin tooling proprietary. Here the README states the dashboard and CLI are part of the self-hosted offering, which is the difference between a usable local instance and a bare API.

How the Rust serving edge and the TypeScript function runtime fit together

The repository layout answers the architecture question more directly than the README prose does. Rust code lives under crates/. The main binary is local_backend/, described as an application server on top of the Runtime and as the serving edge for the Convex cloud. So the HTTP and WebSocket surface, the part clients talk to, is Rust, not Node.

TypeScript lives under npm-packages/, split between public and internal packages. Two internal ones are named in the layout: udf-runtime/ sets up the user-defined functions JS environment for queries and mutations, and system-udfs/ contains functions used by the Convex system, for example the CLI. That is the data flow in outline: a client request reaches the Rust serving edge, which hands query and mutation execution to the JS environment that udf-runtime prepares, and system-level operations such as those the CLI performs go through system-udfs. The workspace Cargo.toml confirms the shape at the dependency level, with crates/ as workspace members and a long list of shared dependencies including axum with the ws feature, which is consistent with a WebSocket-serving edge.

The consequence for anyone evaluating it: your business logic is TypeScript, but the process you deploy, tune and monitor is a Rust binary. Debugging a slow query means reading logs from a Rust application server, not a Node process. That is a real operational difference from the Node-centric backends most JavaScript teams are used to.

Self-hosting Convex with Docker or a prebuilt binary

The README gives two supported paths: Docker, which it recommends, or a prebuilt binary. Detailed instructions are not in the README itself; it points to the self-hosting guide in self-hosted/README.md. Community support is in the #self-hosted channel on Discord, which tells you the maintainers treat self-hosting as a supported-but-community-assisted path rather than a commercial product.

The README does not reproduce the Docker command, so the honest first step is to read self-hosted/README.md before running anything. What the README does commit to is the shape of the self-hosted product: most cloud features, including the dashboard and CLI, and compatibility with Neon, Fly.io, Vercel, Netlify, RDS, Sqlite, Postgres and others. Note that this is a list of tools it works well with, not a statement that Postgres is the storage engine.

A demo application exists at demo/, with an .env file and a Vite config, and it is the closest thing in the repository to a runnable starting point. The demo package.json and README are the files that define its scripts, so check them there before assuming a command name.

Before exposing any of this beyond localhost, the README's disclaimer is explicit: if you build from source, change your instance secret and admin key from the defaults in the repo. Those defaults are in the repository, which means an instance left on them is not protected by obscurity.

One more default deserves attention. Self-hosted builds contain a beacon that reports a random deployment identifier, the database migration version, the backend git revision and uptime. The README says the data is minimal and anonymous, that the messages print in the log, and that you can turn it off with the --disable-beacon flag on the backend binary. That flag is the only concrete backend binary invocation the README gives, and it is worth knowing before you first start the process, because the log output is otherwise easy to mistake for telemetry from something else.

Where the self-hosted Convex backend is the wrong choice

The README is unusually direct about platform coverage: Convex is battle tested most thoroughly on Linux and Mac, and on Windows it has less experience. If your team develops on Windows, that is a stated gap, not an inference. The remedy offered is Discord, not a support contract.

The second limitation is testing. The README calls Convex well tested, with several test frameworks including randomized testing, and then states plainly that those tests are not provided as part of the open source offering. You get the source and the prebuilt binaries; you do not get the harness the maintainers use to gain confidence in it. For a database, that is a meaningful asymmetry. You can read the code, but you cannot reproduce the maintainers' verification story on your own machine.

The third is contribution scope. Development is led by the Convex team, and the README welcomes small bug fixes rather than feature work. The repository is synced with internal development within a handful of days, so the public tree trails the internal one. If your plan is to fork and steer the project, the README is signalling that this is not the intended relationship. And if anonymous telemetry is a hard no for your organisation, the beacon exists in self-hosted builds and must be disabled deliberately; the README treats disabling it as an exception, not a supported default.

Convex versus Supabase: functions-and-reactivity against Postgres-and-tooling

The comparison people reach for is Supabase, and the difference is not one of quality but of what the system is built around. Supabase is organised around Postgres: you get a real SQL database, and the surrounding pieces (auth, storage, realtime) sit next to it. Convex is organised around a TypeScript function runtime and a reactive query model, with the database underneath serving that model. The README's own framing, 'fetch data and perform business logic with strong consistency by writing pure TypeScript', is a statement about where the developer writes logic, not about which query language you get.

That changes what you can carry over. With a Postgres-centric stack, existing SQL, migrations and database tooling generally transfer. With Convex, the unit of work is a TypeScript function, and the client libraries are part of the deal. The self-hosting story is also differently shaped: Convex self-hosted is described as including the dashboard and CLI, while the README lists Neon, Fly.io, Vercel, Netlify, RDS, Sqlite and Postgres among the tools it works well with, which reads as integration surface rather than as a claim of database parity. If your team's skills and existing schema are in SQL, the migration cost is the deciding factor, and the README does not attempt to argue it away.

Maintenance cadence, licensing and the cost of staying current

The repository is not archived and the last push was on 2026-09-19. Releases in the days before that are tagged precompiled-2026-09-19-b7cce5a, precompiled-2026-09-19-0a4aadf and precompiled-2026-09-18-cf8398b. The naming is informative: these are precompiled builds, which is the artefact the README's prebuilt-binary self-hosting path consumes. A team running self-hosted Convex is therefore tracking a stream of dated build tags rather than semantic version numbers, and the version string you pin is a date plus a commit prefix. Plan your upgrade process around that, because there is no major.minor.patch signal to tell you whether a given build is a routine sync or something riskier.

The README states the public repository is kept synced with internal development within a handful of days. That is a commitment about lag, not about backwards compatibility, and it means the diff you review when upgrading can include work you never saw discussed publicly.

Licensing is the open question. The repository's licence is reported as NOASSERTION, and LICENSE.md is the file that settles it. The README's contribution terms are separate and worth reading on their own: by submitting pull requests, you confirm that Convex can use, modify, copy and redistribute the contribution under the terms of its choice. That is a broad grant on inbound contributions. Nothing here is legal advice; read LICENSE.md and, if you are embedding Convex in a product, have counsel read it too. The practical point is that you cannot infer the licence from the README's open-source framing.

Editorial conclusion

Adopt Convex if you want TypeScript functions and live-updating queries in one system and are willing to run it on Linux or macOS, following the self-hosted guide rather than improvising. Do not adopt it if you need Windows as a first-class target, if you expect the internal test frameworks to ship with the source, or if an anonymous usage beacon is unacceptable. Before committing, verify the default instance secret and admin key are changed, confirm the licence terms in LICENSE.md, and check the self-hosted README for the deployment path you intend to use.

Frequently asked questions

Official sources

1. get-convex/convex-backend on GitHub
2. Issues
3. Project website
4. README
5. Releases