I just started working with Spree Commerce and I want to build something similar to how Shopify works. The idea is that users can register and create their own individual shops. Each shop owner should have complete control over their store but cannot access or modify other people’s stores.
I’m looking for advice on the best approach to implement this multi-tenant architecture. Here are two options I’ve been considering:
Option 1: Use separate databases for each shop and route connections based on the subdomain or domain name
Option 2: Add an owner_id field to all database tables, though this might require extensive code modifications
What would be the most practical way to achieve this? Are there any other approaches I should consider for building this kind of multi-store setup?
Just use Spree’s built-in multi-store features - don’t reinvent the wheel. I did this two years ago by taking the existing Store model and adding proper tenant boundaries. Here’s the thing: Spree already handles domain-based store routing, so work with it instead of against it. I built a custom auth layer that locks store owners to their specific store using role-based permissions on the Store model. This keeps things simple - no separate databases needed, but tenants stay isolated. The auth middleware checks store ownership on every request and it’s been rock solid in production. Plus you get shared product catalogs and payment processors when you want them, since it’s all one Spree instance with proper access controls.
honestly, i’d pick option 2 but use a gem like apartment or acts_as_tenant to handle the heavy lifting. adding owner_id manually is a pain, but these gems automate the scoping so u don’t have to modify every query. apartment works especially well with spree - just set it up to switch tenants based on subdomain and ur good to go. way easier than managing separate databases imo.
I built something like this last year using a hybrid approach that worked great. Skip pure database separation or adding owner_id everywhere - instead, use Spree’s multi-store functionality and extend it with proper tenant isolation. Here’s what worked: Spree’s Store model already handles domain-based routing. I extended this by creating a Tenant model as parent to Store, then modified controllers to scope queries through current tenant context. You get shared infrastructure benefits without managing multiple databases. Option 1 becomes a maintenance nightmare when deploying updates or running migrations across hundreds of stores. Option 2 means touching too much core code. The multi-store extension keeps most of Spree’s functionality intact while achieving proper isolation. Performance’s been solid with proper database indexing on tenant scoping fields.
Both approaches suck, but here’s what I’ve learned dealing with this stuff at scale.
Manual tenant scoping gets messy fast with complex business logic. Database per tenant sounds clean but turns into a nightmare when you need analytics across stores or shared resources.
What actually works? Automate everything from day one. I built workflows that handle tenant creation, subdomain routing, and data isolation automatically. New store registers? System spins up their environment, configures domains, sets up data - zero manual work.
Automation handles the annoying stuff too - tenant switching based on request context, keeping queries scoped right. Plus you can automate onboarding emails, store setup, even basic product imports.
You get cleaner separation than manual scoping and way less maintenance than separate databases. Once you automate it right, the whole multi-tenant thing runs itself.
I built multi-tenancy into Spree about 6 months ago and ran into the same stuff you’re dealing with. Here’s what worked for me: I used ActsAsTenant but added a Tenant model that sits on top of everything and handles scoping through middleware instead of touching individual models. Turns out Spree already has pretty good store separation - you just need to lock down isolation at the request level. I handle tenant detection through subdomains in custom middleware that sets the context right when the request comes in. You skip the headache of separate databases while keeping code changes minimal. Performance has been solid and spinning up new tenants is easy since they all share the same codebase and infrastructure.
Hello everyone, please I’d love your feedback and recommendations.
I’m planning to build a modular multi-tenant SaaS platform where users can sign up and choose which services or modules they want to include in their instance under a subdomain or their own custom domain .
The initial modules I plan to offer are:
Fully featured e-commerce – physical and digital products .
Bills Payment – electricity, cable TV
Gift Card Trading – buy/sell/trade gift cards.
Over time, I plan to add more service modules, depending on adoption. I plan to use postgres and leverage it’s RLS (Row Level Security).
modules should be plug-and-play — easy to add or remove new offerings in the future
Per-tenant customization and minor feature adjustments or integrations upon request without breaking shared codebase.
Tenants should be able to select from several varieties of themes for their frontend (Nuxt/Next.js) look.
I haven’t built something of this nature before or written a line of ruby before, but have decent working knowledge of TS/Node but I am open to working with any stack that offers the most advantage for my use case.
I did some research online and found 3 likely suitable candidates for frameworks that could help me do the heavy lifting: Directus, medusa.js, spree commerce
I’m looking for:
Suggestions for the best tech stack/ commerce framework that can handle or has :
Multi-tenancy
Modular features
Custom Domain / Subdomain Support
admin dashboard that everything can be managed from and can as well be customized (possibly via RBAC) as each tenant’s admin dashboard without having to build one from scratch
Advice from those who have built or managed SaaS or multi-tenant apps — particularly on: