Skip to content

Adapters

An adapter is a protocol front door. Your client speaks the wire protocol it already knows — Convex, Firestore, Cloud Functions, MongoDB, DynamoDB, or the native API — and Nimbus serves it from the same engine, storage layer, and tenant boundary as every other surface. Picking a door changes the shape of your calls, not where your data lives or how it is isolated. The design and its limits are explained in the adapter boundary.

Every server serves these surfaces by default. The Convex-compatible surface, the Firestore routes, and the native API share the main listener; MongoDB and DynamoDB each bind their own conventional port (127.0.0.1:27017 and 127.0.0.1:8000).

nimbus dev wires your app automatically, and it treats two kinds of surface differently.

One app adapter. The adapter that owns your app’s wiring, codegen, and watch loop is singular — exactly one is chosen:

Nimbus seesApp adapter
a convex/ directoryConvex
a firebase dependencyFirestore
a firebase.jsonCloud Functions

Any number of wire surfaces. These are a set, and they compose with any app adapter — a Convex app that also installs mongodb keeps its Convex dev loop and gets the MongoDB listener:

Runtime dependencyWire surface
mongodb or mongooseMongoDB — writes NIMBUS_MONGODB_URL to .env.local
@aws-sdk/client-dynamodb or @aws-sdk/lib-dynamodbDynamoDB — writes NIMBUS_DYNAMODB_* to .env.local
@aws-sdk/client-s3 or @aws-sdk/lib-storageS3

Wire-surface detection reads only the runtime dependencies in your package.json — not devDependencies, optionalDependencies, or peerDependencies — because enabling one starts a listener, generates credentials, and writes .env.local. A bare aws-sdk (v2) dependency is too broad to imply DynamoDB or S3, so it only produces a banner hint and never enables a surface.

The Firestore, MongoDB, DynamoDB, and S3 surfaces can each be switched off with nimbus start flags (--no-firestore, --no-mongodb, --no-dynamodb, --no-s3); the Convex-compatible surface and the native API are always on. Under nimbus dev a wire surface is enabled by its runtime dependency (above) rather than a flag — remove the dependency to leave it off. Flags, ports, and credentials are in configuration.

SurfaceReach for it whenYou write againstMigration guide
Convexyou want the full function model — queries, mutations, actions, and reactive subscriptionsconvex/ functions and the Convex clientsYes
Firestoreyou have a Firebase app, or want Firestore’s document SDKsthe stock firebase/firestore SDKYes
Cloud Functionsyou are porting Cloud Functions for Firebase workloadsfirebase-functions v2 handlersYes
MongoDByou already have code on the official MongoDB driversyour existing MongoDB driver
DynamoDByou already have code on the AWS SDK@aws-sdk/client-dynamodb
Native APIyou want any language, with no SDKplain HTTP and WebSocket

The ported-source surfaces (Convex, Firestore, Cloud Functions) carry a migration guide because you are moving existing source onto Nimbus. The driver surfaces (MongoDB, DynamoDB) and the native API need no migration — you point an existing client at a Nimbus endpoint and keep your code.

Every surface ships runnable examples: Convex, Firestore, Cloud Functions, MongoDB, DynamoDB, and Native API.

Surfaces are not interchangeable: each translates a different slice of the engine. Adapter capabilities puts all six side by side — CRUD, queries, indexes, subscriptions, transactions, schema validation, auth, tenant binding, and default ports — with links into each per-surface reference. The full per-surface compatibility matrices live in the Reference section.

Nimbus serves protocol surfaces that are not app front doors and have no guides in this section: an S3 API (wired by nimbus dev when you declare an AWS S3 client, as above), a Cloudflare-compatible Workers KV plane, and a RESP (Redis) listener started with nimbus kv. Each is documented in the Reference section with its own maturity caveat.