Deployment options

Choose where the graph and the API run.

RushDB supports managed cloud, BYOC, and self-hosted deployment models. Choose the operational boundary that matches your application.

Start free View docs

Infrastructure requirements change as applications mature.

A fast prototype may value managed operations. A production workload may need data residency, raw Cypher access, a chosen cloud region, or full control of the RushDB service.

Before

Adopt one fixed hosting topology
Treat data location and API location as the same choice
Rebuild application code when infrastructure changes
Discover operational trade-offs late

With RushDB

Use managed RushDB Cloud for the quickest start
Use BYOC to keep graph data in your Neo4j or Aura instance
Self-host the API, graph store, and metadata database when needed
Keep the same REST API surface across deployment models

What it enables

Start simple, keep an exit path.

The deployment docs draw a practical line between managed cloud, BYOC, and self-hosting. The value is keeping the RushDB API stable while operational responsibility changes.

Managed for speed

Use RushDB Cloud when the priority is getting a project live without operating Neo4j or the RushDB service.

BYOC for data control

Keep graph data in your own Neo4j or Aura instance while the RushDB API layer remains managed.

Self-host for full control

Run the API, metadata database, graph store, and embedding configuration yourself when infrastructure policy requires it.

How it works

Start with the smallest useful path.

Start with the operational constraint

Choose managed cloud for minimal operations, BYOC for your own graph data store, or self-hosting for full infrastructure control.

Configure the graph store

BYOC and self-hosted deployments connect RushDB to your Neo4j or Aura instance.

Keep the application surface stable

Use the RushDB API and SDKs from your application while the deployment topology changes behind that boundary.

Flow

Choose by operational boundary

Pick the model by who operates RushDB and where graph data lives, not by rewriting application code.

Prototype

Managed Cloud

BYOC

Self-hosted

Same API

Implementation sketch

Start a self-hosted stack with Docker Compose.

The deployment guide includes the full Compose file, required environment variables, BYOC setup, and production hardening checklist.

# After configuring docker-compose.yml:
docker compose up -d

# Open the RushDB dashboard:
open http://localhost:3000

Know the operational boundary.

BYOC and self-hosting are different

With BYOC, RushDB Cloud runs the API while your Neo4j or Aura instance stores graph data. With self-hosting, you operate the RushDB service too.

Compare deployment models

Semantic search has an optional provider dependency

A self-hosted deployment can configure an OpenAI-compatible embeddings endpoint when semantic search is required.

Read the self-hosting guide