Convex Self-Hosted
IntermediateWeb AppSelf-host the Convex reactive backend on your own server, with SQLite as the default store and PostgreSQL or managed Neon behind it when a single node isn't enough.
Published 27 September 2026
About Convex Self-Hosted
Convex Self-Hosted runs the open-source Convex reactive backend on a VPS you control, with SQLite as the default embedded store. This is the simplest self-hosting configuration for Convex: a single Docker container runs the backend with its data in SQLite files, requiring no separate database process to configure or maintain. The same backend can instead write to self-run PostgreSQL or a managed Neon database when the deployment outgrows the single-node default.
The SQLite-backed configuration is well-suited for lower-traffic applications, personal projects, or initial deployments where simplicity is more valuable than PostgreSQL's concurrency handling. All Convex features (reactive queries, TypeScript server functions, schema validation, real-time updates) work identically whichever store sits underneath, and identically to Convex Cloud.
Start on SQLite and migrate later: move to a PostgreSQL-backed store when write volume grows beyond what SQLite can handle concurrently. For typical CRUD application workloads with moderate traffic, SQLite is entirely adequate and dramatically simpler to set up.
Key Features
- ✓Convex's reactive queries, mutations, and actions on your own server
- ✓SQLite by default, with self-run PostgreSQL or managed Neon as alternatives
- ✓TypeScript server functions with end-to-end type safety and schema validation
- ✓The self-hosted dashboard for data, logs, and function runs
- ✓npx convex export and import to move data between self-hosted and Convex Cloud
- ✓One backend container plus the dashboard, on any Docker-capable host
When to Use Convex Self-Hosted
- →Personal projects and side apps where minimal infrastructure matters
- →Apps whose data-residency rules rule out a third-party backend
- →Development and staging environments for Convex Cloud production apps
- →Low-traffic web apps that want Convex's developer experience without cloud billing
- →Teams evaluating Convex self-hosting before choosing a production store
Pros
- One backend container with an embedded store gets Convex running
- No database to administer on the default SQLite store
- The same reactive model, client libraries, and CLI as Convex Cloud
- Moving to PostgreSQL or Neon is a store change, not an app rewrite
Cons
- Single-node by design: scaling out means modifying the open-source backend
- No paid edition or official support plan for self-hosting
- Storage-layer migrations on upgrade mean pinning versions and exporting first
- SQLite suits moderate write volume; heavier workloads move to PostgreSQL
Database Options for Convex Self-Hosted
Convex Self-Hosted with SQLite
Convex's own documented default for self-hosting: the backend's internal storage lives in SQLite files with no separate database process to run. Keep those files on a dedicated volume. The lighter starting point; move to PostgreSQL when write volume or data size outgrows it.
Convex Self-Hosted with PostgreSQL
Swaps Convex's internal backing store to PostgreSQL for heavier deployments: more headroom for data volume and concurrent writes, at the cost of operating a second container alongside the Convex backend. Standard pg_dump backups then cover all of Convex's state.
Convex Self-Hosted with Neon
A managed serverless Postgres backing store, named in Convex's own self-hosting write-up: the backend keeps running on your VPS while Neon handles the database layer, so there's no second container to operate and backups, patching, and scaling are Neon's problem rather than yours. The scope of self-hosting narrows, though. Your data lives on Neon's infrastructure instead of your own server, so keep the store local when full data control is the reason you're self-hosting.
These are highlighted picks. To see all the tools, check the Databases category.
Hosting Options for Convex Self-Hosted
Deploy Convex Self-Hosted on Hetzner
A flat-rate root VPS from around €4-5/mo whose entry instance has 4 GB of memory, enough for the backend under sustained load with the dashboard beside it. Keep the SQLite data on its own volume, as Convex's docs advise, so a snapshot of that volume is a complete backup.
Deploy Convex Self-Hosted on Railway
Convex's self-hosting docs include a Railway guide, and Railway hosts a template with the backend, dashboard, and PostgreSQL provisioned together. Railway gives each service its own HTTPS domain, which maps neatly onto Convex's separate API, HTTP-actions, and dashboard URLs, so the reverse proxy or PaaS choice doesn't apply. The $5/mo Hobby plan plus usage is the starting point.
Deploy Convex Self-Hosted on Fly.io
Convex's self-hosting docs include a Fly.io guide: the backend runs as a Fly machine with a volume for its data, deployed with flyctl. A 1 GB machine costs about $6/mo and fits a low-traffic app, and Fly terminates TLS at its edge, so the reverse proxy or PaaS choice doesn't apply.
Deploy Convex Self-Hosted on DigitalOcean
A root Droplet with snapshots and a cloud firewall in the panel: about $12/mo for 2 GB, comfortable for a low-traffic backend, or $24/mo for 4 GB under sustained load. Spaces can take Convex's file storage through its S3 support, which keeps uploaded files off the Droplet's disk.
Deploy Convex Self-Hosted on Hostinger
The budget VPS in the list: the entry KVM plan (about $6.50/mo on a two-year term) has 4 GB of memory, the row's figure for sustained load, so the backend has headroom from day one. Fewer regions than the larger providers, and volume backups are yours to set up.
Deploy Convex Self-Hosted on Amazon Web Services
An EC2 instance at roughly $15-30/mo for 2-4 GB, next to the rest of an AWS-hosted product. S3 can hold Convex's file storage, RDS can host the PostgreSQL store, and an Application Load Balancer with AWS Certificate Manager can route the API, HTTP-actions, and dashboard hostnames instead of the reverse proxy.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for Convex Self-Hosted
Convex Self-Hosted with Traefik
Routes three hostnames from Docker labels, the API to port 3210, HTTP actions to 3211, and the dashboard to 6791, and renews their certificates on its own. Set CONVEX_CLOUD_ORIGIN, CONVEX_SITE_ORIGIN, and the dashboard's deployment URL to the public HTTPS addresses, or clients connect to the internal ones.
Convex Self-Hosted with Caddy
Automatic HTTPS for Convex's three hostnames in a short config, one site block each for the API, HTTP actions, and the dashboard. Caddy passes WebSocket upgrades by default, which Convex's reactive sync depends on, so live queries work without extra directives.
Convex Self-Hosted with NGINX
The most familiar proxy, with TLS through Certbot. Add the HTTP/1.1 upgrade headers on the API hostname, since Convex clients hold a WebSocket open for live queries, and raise proxy timeouts so idle subscriptions aren't dropped.
Self-Hosted PaaS Options for Convex Self-Hosted
Convex Self-Hosted with Coolify
Free and self-hosted, running Convex's Compose file behind its bundled proxy with HTTPS for each hostname. Assign the API, HTTP-actions, and dashboard domains to their ports in the service, then generate the admin key from the backend container to sign in to the dashboard.
Convex Self-Hosted with Dokploy
Free and self-hosted, deploying Convex's Compose file behind its bundled Traefik with a domain per port. Mount the SQLite data directory as a named volume and include it in Dokploy's backups, since that directory is the whole of the app's state.
Convex Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
Convex Self-Hosted with Cloudflare Tunnel
Makes a Convex backend on a home server or private network reachable over HTTPS through outbound-only connections, with no inbound ports. Publish the API, HTTP-actions, and dashboard hostnames as separate tunnel routes, and set the origin variables to match.
Convex Self-Hosted with ngrok
The quicker-start tunnel for exposing a local Convex backend's HTTP actions to a webhook sender during development. Its free-tier limits suit that kind of testing rather than a production backend.
Frequently Asked Questions about Convex Self-Hosted
Why self-host Convex instead of using Convex Cloud?
Convex Cloud's free Hobby tier is generous and its Pro tier is $25/mo, so cost alone rarely forces the move. The reasons to self-host are data residency rules that prohibit a third-party backend, and usage patterns (very high read/write volume, large storage) where Cloud pricing compounds faster than a VPS. The self-hosted backend is the same open-source code Convex runs, so functionality parity is close, but you take on upgrades and operational care of the reactive backend and its database yourself.
SQLite or PostgreSQL behind the self-hosted Convex backend?
SQLite is the documented default for self-hosting: the backend's internal state lives in SQLite files with no second database process, which keeps the stack at its minimal footprint. PostgreSQL becomes the right choice when data volume outgrows a single node or you want to run multiple backend instances, at the cost of operating another container. Start on SQLite and move when you have a concrete reason; the backend abstracts the store either way.
What kind of server does a self-hosted Convex backend need?
Convex publishes no hardware floors for self-hosting. The prebuilt image is a single-node Rust binary and SQLite is embedded, so the default setup is one modest process with no separate database to feed: a 1-2 GB RAM VPS runs a low-traffic app comfortably, which matches the cheapest tier at any provider. Pointing the backend at PostgreSQL adds a database container on the same machine, and pointing it at managed Neon moves that load off the VPS entirely. The real ceiling is architectural rather than hardware: the self-hosted backend is single-node by design, so scaling out means modifying the open-source backend, not buying a bigger server.
What needs backing up?
All durable state lives in the store you picked, so that is the whole backup problem. With SQLite it is a single file per instance, and the official guidance is to keep it on its own volume: a snapshot or file copy taken with the container stopped restores everything. With PostgreSQL, use standard pg_dump or volume snapshots against the database container, or lean on the managed provider's backups if you went with Neon. The backend and dashboard containers hold nothing precious and rebuild from their images, and npx convex export / npx convex import move data between self-hosted and Convex Cloud if you ever need to cross that boundary.
How do upgrades and licensing work?
Pin the Docker image to a specific backend version rather than floating on latest: each new backend version can bring a migration of the underlying storage layer (the SQL schema Convex keeps its own state in, not your app's tables), which the backend runs itself as it comes up and reports in the logs with a completion line per migration. Take a backup export beforehand, wait for that final completion line, and if an in-place upgrade ever misbehaves, the documented fallback is exporting and re-importing onto the fresh version with npx convex export and npx convex import. The license is FSL-1.1-Apache-2.0, a fair-source license: running and modifying the backend for your own use is free, the one carve-out is building a hosted service that competes with Convex Cloud, and each release converts to plain Apache-2.0 two years after publication. There is no paid edition and no official support plan for self-hosting; the #self-hosted Discord channel is the community venue.
Stacks Related to Convex Self-Hosted
Grafana Self-Hosted
Infrastructure
Self-hosted Grafana and Prometheus: metrics dashboards and alerting on a server you run.
Strapi Self-Hosted
Infrastructure
Self-hosted Strapi: an open-source headless CMS with PostgreSQL, on a server you control.
Airflow Self-Hosted
Infrastructure
Self-hosted Apache Airflow: the standard data-pipeline scheduler on your infrastructure.
n8n Self-Hosted
Infrastructure
Self-hosted n8n on your own server, with full control over the database, the host, and how it's exposed to the internet.
Scores
Popularity2/5
Convex is rising quickly in React and TypeScript circles since open-sourcing its backend; outside that ecosystem the name still draws blanks.
Learning Curve3/5
Convex's reactive-function model is a genuinely different way to write a backend and usually asks for some unlearning; operating the self-hosted backend adds Docker on top.
Flexibility3/5
Reactive queries, scheduled functions, and file storage in one model, but everything is written the Convex way; it is not a general-purpose app server.
Performance3/5
The reactive engine streams updates efficiently by design, and the default single-node SQLite deployment serves its workload well.
Portability3/5
The deployment moves freely, but an application written against Convex's reactive model doesn't — leaving Convex means rewriting the data layer, with only the raw data exporting cleanly.
Tools in the Convex Self-Hosted Stack
Convex Self-Hosted Pricing
Convex's open-source backend self-hosts free with SQLite as its default store, leaving the server as the only cost. The managed alternative, Convex Cloud, is free on its Hobby tier and $25/mo at Pro scale with usage-based limits in between.
1 GB to 2 GB of RAM runs a low-traffic backend on SQLite; 4 GB covers sustained load or PostgreSQL on the same server.
The self-hosted backend and the self-run stores (SQLite, PostgreSQL) cost nothing; managed Neon bills its own usage-based pricing instead.
Convex Self-Hosted System Requirements
- CPU
- 1 vCPU
- RAM
- 1 GB to 2 GB for low traffic, 4 GB under sustained load
- Disk
- 20 GB SSD; the data volume sets the ceiling
- OS
- Any Linux with Docker
No official requirements published — tekyous guidance based on the bundle's services.
Tracks measured self-hosted deployments, where the backend idles under 200 MB and reaches roughly 750 MB under load, and a VPS vendor guide converging on 2 GB minimum / 4 GB production; budget headroom, as memory growth after exports has been reported.