Summary and recommendation
Spree Commerce user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Spree Commerce is a self-hosted, open-source e-commerce platform built on Ruby on Rails.
It ships with no native SSO or SCIM support, so every app in your stack that needs provisioning must be handled independently.
User management lives at /admin/users and covers two built-in roles: Admin (full panel access) and Customer (storefront only).
Quick facts
| Admin console path | /admin/users |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Open Source / Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full access to all Spree admin panel sections: orders, products, promotions, reports, configurations, and user management. | No documented restrictions within the admin panel for this role. | Admin role is assigned per user account; there is no documented limit on the number of admin accounts in the open-source version. | ||
| Customer (end user) | Can place orders, manage their own account details, view order history via the storefront. | Cannot access the /admin panel or any administrative functions. | Customer accounts are created via storefront registration or manually by an admin. They are distinct from admin accounts. |
Permission model
- Model type: role-based
- Description: Spree uses a role-based access control system. Default roles are 'admin' and 'user' (customer). Roles are stored in the spree_roles table and assigned via spree_roles_users. Custom roles can be defined in code via Spree::RoleConfiguration, but there is no built-in admin UI for creating arbitrary custom roles in the standard open-source release.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Role-level only in the default admin UI. Granular per-permission customization requires code-level configuration via Spree::PermittedAttributes or CanCan ability classes.
How to add users
- Log in to the Spree admin panel.
- Navigate to /admin/users.
- Click the 'New User' button.
- Enter the required fields: Email and Password.
- Optionally assign the 'Admin' role by checking the 'Admin' checkbox.
- Click 'Create' to save the new user.
Required fields: Email, Password
Watch out for:
- The admin checkbox on the user form grants full admin access; there is no intermediate role selectable via the default UI.
- Password is set by the admin at creation; the user does not receive an automated invitation email by default unless a custom mailer is configured.
- Spree is self-hosted; the admin URL depends on the deployment's domain.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | No | Not documented |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Spree's admin panel includes a delete action for user accounts accessible from /admin/users. The official docs describe a 'Delete' option on the user list and user detail pages. There is no documented native 'deactivate/suspend' toggle in the default open-source admin UI; removal is via deletion.
- Log in to the Spree admin panel.
- Navigate to /admin/users.
- Open the target user record or use the delete action from the users list.
- Confirm deletion; the default admin UI does not document a separate deactivate or suspend state.
| Data impact | Behavior |
|---|---|
| Owned records | Orders and other records associated with a deleted user account may be retained in the database with a null or orphaned user reference, depending on the application's database constraints and any custom callbacks. Official docs do not explicitly specify cascading delete behavior. |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Spree is open source and self-hosted; there are no per-seat licenses to free upon user deletion. |
Watch out for:
- Deletion is permanent in the default implementation; there is no documented undo or soft-delete in the standard open-source admin UI.
- Admins should verify database foreign key constraints and any custom callbacks before deleting users with associated order history.
- No native deactivation/suspension feature exists in the default admin UI; blocking access requires deletion or a custom code-level implementation.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Open-source self-hosted | No per-seat licensing for admin or customer accounts in the standard MIT-licensed Spree distribution. | $0 software license |
| Managed hosting / enterprise support | Commercial support or hosting negotiated separately with Spree Commerce or partners. | Custom |
- Where to check usage: Not documented
- How to identify unused seats: Not documented
- Billing notes: Spree Commerce is open source (MIT license) and self-hosted. There are no per-seat or per-user licensing fees in the open-source version. Enterprise support or managed hosting arrangements are available via Spree Commerce or partners at custom pricing, but seat-based billing is not a documented feature of those arrangements in publicly available sources.
The cost of manual management
Because Spree is open source and self-hosted, there are no per-seat licensing fees to track or reclaim. The operational cost of manual provisioning is time and error risk: the admin UI offers no invitation email flow by default, so new admin accounts require a separate communication step to hand off credentials.
There is also no deactivation toggle - removing access means permanent deletion, which carries risk for accounts tied to order history.
The decision
Manual management is viable for small teams with infrequent user changes, given the straightforward /admin/users interface. It becomes a liability at scale: every app requiring admin access must be provisioned individually, deletion is irreversible by default, and role changes require code-level work for anything beyond the binary admin/customer split.
Teams running Spree alongside an IdP or HR system should evaluate whether a custom SCIM layer or API-based provisioning is worth the build investment.
Bottom line
Spree's admin panel gives you a functional but minimal user management experience. The binary role model, lack of native deactivation, and absent invitation flow mean that every app-level access change carries more manual overhead than comparable SaaS platforms.
For low-volume admin teams this is manageable; for organizations with compliance requirements or frequent onboarding cycles, the gaps in the default UI will require custom development to close.
Automate Spree Commerce workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
