Deployment Overview

Spree is open source and self-hosted: you own the entire stack, end to end. There is no proprietary software in the runtime, no required third-party service, and no per-order fees. The same application runs on a $10 VPS, a managed cloud platform, a Kubernetes cluster, or a server in your own data center — and moving between them is a redeploy, not a migration.

​

Run It Anywhere

Spree ships as a standard Docker image, which means it runs wherever containers run:

• Public cloud — AWS, Google Cloud, Azure, or any provider with container hosting
• Platform-as-a-Service — Render, Railway, Fly.io, and similar platforms; deploy from your repository with a Blueprint or a few clicks
• VPS or bare metal — a single machine with Docker installed is a complete production environment
• Kubernetes — the image is stateless and horizontally scalable, so it drops into any cluster
• On-premise and intranet — Spree has no phone-home dependencies, so it runs in private networks and air-gapped environments where SaaS commerce platforms simply can’t

The minimum footprint is deliberately small: one application container and one database. Background jobs, caching, and real-time updates all run inside that container and store their data in the database — no Redis, no message broker, no extra services to provision or monitor. A store starts comfortably on 1 GB of RAM. When you need more, every piece scales independently: add web instances behind a load balancer, split job processing into dedicated workers, add a read replica, swap the cache to Redis or Valkey, add Meilisearch for search. Each step is configuration, not rearchitecting.

​

Any Database

Spree runs on all major relational databases, including the managed and serverless flavors cloud providers offer: See Database Configuration for details.

​

Web and Worker

A Spree deployment has two kinds of work: serving requests (the web process) and everything that happens in the background — sending emails, processing images, delivering webhooks, importing catalogs (the worker). You can run them in two modes:

• Combined (the default) — the web container also processes background jobs. One container is the whole application. This is how every fresh deployment starts, and it comfortably serves most stores.
• Split — when job volume grows, move background processing into a dedicated worker service. It’s the same docker image with a different start command and one environment variable (SOLID_QUEUE_IN_PUMA=false on web) — no rebuild, no code changes. Recommended for high volume retailers, multi-tenant apps and marketplaces with a lot of vendors using our Shopify sync.

Jobs live in the database, so scaling to multiple web instances or multiple workers is safe by default — they coordinate through it. For demanding workloads, you can also swap the job backend to Sidekiq on Redis or Valkey. See Background Jobs for the full picture.

​

Single-Node vs Distributed

Spree is API-first, which gives you a real choice of shape: Single-node — one container serves the API, the admin dashboard, and background jobs, with one database behind it. Simplest to operate, cheapest to run, and what create-spree-app projects deploy by default. For headless setups with a mobile app or a custom frontend, this is often all the infrastructure you ever need. Distributed — because the storefront and admin talk to Spree exclusively through its APIs, each surface can be deployed and scaled on its own:

• The API scales horizontally behind a load balancer
• The admin dashboard is a static React app that can be served from the API container or any static host
• Workers scale independently of web traffic
• The storefront (Next.js) deploys to Vercel or any Node.js host, rendering at the edge close to your customers

You don’t choose upfront. Start single-node, and split surfaces out when traffic or team structure calls for it — the API boundary is already there. Storefront is fully optional, you can use our Next.js reference implementation, or build your own with any framework, build a mobile app, or even a native desktop app. Spree is the backend for all of them.

​

Storefront Deployment

The Next.js storefront is a separate application with its own deployment lifecycle — typically on Vercel, but any Node.js host or Docker environment works. It connects to your Spree API with a publishable key and can be redeployed independently of the backend. See Storefront Deployment for the full guide.

​

Provider Guides

Step-by-step guides for specific platforms: For any other platform, the Docker guide covers building and running your project’s image — which is all any container host needs.