Solidus

Last reviewed Sep 13, 2026 · 783 words

There is no docker compose up that gives you a Solidus shop. Solidus (5,300 stars, BSD-3-Clause, Ruby, first released 2015) is a set of Rails engines you add to a Rails application you own; the application is your store, and you build, host, and upgrade it like any other Rails app. For a developer who already lives in Rails and needs a store that will still be sane at 100,000 orders, that is exactly the point. For anyone who wants to sell things this month without writing Ruby, it is the wrong project, and the honest recommendation is further down.

What you are actually deploying

A Solidus store is a Rails monolith with Postgres, a Redis-backed job queue for emails and imports, and file storage for product images. The solidus gem pulls in solidus_core (products, orders, promotions, taxes, shipping), solidus_api (a REST API), solidus_backend (the classic admin) and, since the recent rewrite, solidus_admin for the new interface. The storefront is yours: either the solidus_starter_frontend templates generated into your app, or a headless front end in whatever framework you like, talking to the API. Getting to a running skeleton is roughly:

rails new shop --database=postgresql
cd shop
bundle add solidus
bin/rails generate solidus:install
bin/rails server

The installer asks which frontend and admin you want and seeds sample data. Plan on 1 GB of RAM for the app process plus Postgres, and more for Sidekiq under load. Deployment is the standard Rails picture: a container image built from your repo, or Kamal, or a PaaS, with a Postgres you back up properly. Nothing here is Solidus-specific; that is its strength and the reason the difficulty rating is "hard" for non-Rails people.

The Spree fork that chose stability

Solidus forked from Spree in 2015 when Spree's direction became uncertain, and the two have diverged since. Spree has moved faster on its own storefront and admin and has a company behind it selling hosting and enterprise features. Solidus is governed by a community foundation, keeps a deliberate release cadence, publishes upgrade guides for every minor version, and treats backwards compatibility as a feature. Stores that have been running for 8 years tend to be on Solidus; stores launched for a pitch deck tend to be on Spree. If you are choosing between them today, the questions are whether you want a vendor to call and whether your team values a predictable upgrade path over new features.

Customisation is the whole product

Everything in a Solidus store is a Rails model or a service object you can override or decorate: promotion rules, tax calculators, shipping methods, order state machines, the checkout flow itself. Payments are extensions, with solidus_stripe and solidus_paypal_commerce_platform maintained by the core team. This is why agencies pick it for stores with unusual rules (B2B pricing tiers, configurable products, multi-warehouse fulfilment) that a hosted platform would need apps and workarounds for. It is also why there is no click-to-install path: the customisation surface is code.

That has consequences for operations. Upgrades are a developer task (run the generators, read the changelog, fix deprecations, run the test suite). Security fixes land in supported release lines and you apply them by bumping a gem. A store with nobody who can read Ruby will fall behind within a year.

Who should look elsewhere

If your requirement is a small shop with standard products and a checkout, WooCommerce on WordPress gets you there in an afternoon and has hosting everywhere. If you want headless commerce but your team is JavaScript-first, Medusa is the Node equivalent of what Solidus is for Rails, with a bigger current momentum. If you are Python-first, Saleor plays the same role with GraphQL. And if you are leaving Shopify because of fees, run the numbers before committing: the developer time to run a Solidus store is not free either, and the e-commerce category has options at every point on that curve.

What I'd do

If I had a Rails team and a store with real complexity, I would pick Solidus over Spree for the governance and the upgrade discipline, generate the starter frontend, wire solidus_stripe, and deploy it as a container next to a managed or well-backed-up Postgres. I would budget a developer-day per quarter for upgrades and treat that as the cost of owning the store. If I had no Rails team, I would not install it at all; WooCommerce for the simple case and Medusa for the headless case will each cost less to run than learning Rails to keep a shop patched.