Spree Commerce

Last reviewed Aug 26, 2026 · 829 words

Spree is a set of Ruby gems you mount inside a Rails application, so the first thing you deploy is a Rails app that you own and are responsible for. That is the fact that sorts prospective users: a developer who already writes Ruby gets a mature, modular commerce core with 18 years of production history and a BSD-3-Clause licence; a shop owner who wants to click "install" and start listing products should look at WooCommerce or Bagisto instead and never touch a Gemfile. The catalogue's "Ruby expertise needed" is not a footnote, it is the entry requirement.

What is actually running when Spree is up

A production Spree deployment is 4 or 5 processes. The Rails web process (Puma) serves the storefront, the admin panel, and the JSON API. Sidekiq runs background jobs for emails, image processing, and search indexing, and needs Redis. PostgreSQL holds orders, products, and users. Active Storage handles product images, which means either local disk or an S3-compatible bucket, and a libvips or ImageMagick binary for variants. The project's starter repository ships a Docker Compose file that wires these together, and it is the fastest way to see a working shop in an afternoon:

services:
  web:
    build: .
    command: bundle exec rails server -b 0.0.0.0
    environment:
      - DATABASE_URL=postgres://spree:spree@db/spree
      - REDIS_URL=redis://redis:6379/0
      - RAILS_ENV=production
    ports:
      - "3000:3000"
    depends_on: [db, redis]
  worker:
    build: .
    command: bundle exec sidekiq
    environment:
      - DATABASE_URL=postgres://spree:spree@db/spree
      - REDIS_URL=redis://redis:6379/0
  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=spree
      - POSTGRES_PASSWORD=spree
    volumes: [./pgdata:/var/lib/postgresql/data]
  redis:
    image: redis:7

The listed 1,024 MB minimum is honest for a demo and optimistic for a real shop: a Rails process with the Spree engines loaded sits at a few hundred megabytes, Sidekiq the same again, and Postgres wants room to cache. Plan 2 GB and you will not be swapping during a sale.

Multi-store and multi-vendor are real features, not add-ons

Spree's data model has supported multiple stores in one database for years, with per-store currencies, domains, and catalogues, and the marketplace features let vendors manage their own products and fulfil their own orders. Both come out of the box rather than as paid extensions, and that is the concrete advantage over the WordPress route, where each of those is a separate plugin with a separate licence. Payments arrive via gateway gems; Stripe is the maintained first-party integration and covers most shops. Tax, shipping calculators, promotions with rule engines, and stock across multiple locations are all in core.

Headless, bundled storefront, or both

The API is the part of Spree that has been stable longest and it is why the platform survived the shift to headless commerce. You can use the bundled storefront (server-rendered Rails views you can theme with Tailwind), or ignore it and drive a Next.js or mobile front end through the REST API with the admin panel as your back office. Mixed is common: Rails storefront at launch, a custom front end when the design team demands it. Compare that with Medusa, which is headless-only and Node, and Saleor, which is headless-only and Python with GraphQL; Spree is the one of the three that gives you a working shop page before you write any front-end code.

Customising means writing Ruby, and upgrades follow

Spree is deliberately built as Rails engines so you override behaviour with decorators and swap views by copying them into your app. That flexibility is why agencies like it and why upgrades need planning: each major release moves internals, and every decorator you wrote is a place a migration can break. Keep customisations in a small number of files, cover checkout with request specs, and read the upgrade guide before bumping a major version. Postgres is the only database I would run it on, for the reasons in Postgres for everything.

Who should not pick it

A one-person shop selling 50 SKUs, with no developer on call. A team whose stack is PHP or Node with nobody willing to learn Rails. Anyone whose requirement list is dominated by a specific page builder or theme marketplace. For those, the Shopify alternatives rundown points at simpler tools, and the wider e-commerce category has several that install from a single container.

What I'd do

If you have a Rails developer and expect to customise checkout, run multiple storefronts, or build a marketplace: Spree, on Postgres 16, Sidekiq on Redis, images in an S3-compatible bucket, 2 GB of RAM, and a staging environment from day one because major upgrades are real work. Start with the bundled storefront and go headless only when a designer forces it. If you have none of those needs, use WooCommerce and spend the Ruby time elsewhere.