Coming from Convex

Nimbus implements a Convex-compatible backend: the same function model (queries, mutations, actions, HTTP actions), the same convex/ project layout, schema and validators, task scheduling, and reactive subscriptions — self-hosted in a single binary.

What carries over

• Authoring. convex/ directory, defineSchema/defineTable, the v validator builder, query/mutation/action/httpAction, internal functions, and "use node" actions on the Node compatibility runtime.
• Clients. The Convex-compatible npm surface (convex/react hooks, browser and HTTP clients) pointed at your local deployment URL.
• Workflow. nimbus dev watches, runs codegen, and serves reactive updates the way npx convex dev does — entirely locally.

Pick your route

• Starting fresh? Follow the 5-minute quickstart to scaffold a new Convex app on Nimbus and get reactive queries running.
• Have an existing Convex project? Follow Migrate from Convex to point its convex/ directory at Nimbus and rewire the convex dependency to the provisioned drop-in package.

What differs

Compatibility is per-surface: some are complete, some are bounded.

• Node-runtime coverage is per-version and bounded. "use node" actions run on the Node compatibility runtime, whose support is documented per Node major — see current capabilities.
• A deployment is a single process today. There is no clustering layer; one Nimbus binary serves the workload — see Scaling.
• Not every Convex surface is translated. Cron jobs (cronJobs) do not carry over — use task scheduling (ctx.scheduler) instead. The migration guide walks the remaining gaps, and the compatibility matrix is the source of truth.

The Convex compatibility matrix is the source of truth for what is supported today.

Next steps

• Developer quickstart — the five-minute path.
• Developers — per-feature guides as you build.
• Concepts — how Nimbus's engine differs under the hood.