Shuup

Last reviewed Sep 13, 2026 · 840 words

Shuup is for a Django developer building a marketplace, and for nobody else. If you want to sell your own products from a self-hosted store, WooCommerce, Saleor or Medusa will get you live faster with a larger community behind each. If you are building a platform where many sellers list products under one storefront, and your team already writes Python, Shuup's data model gives you shops, suppliers, and per-vendor orders on day one, which none of the mainstream open-source stores do without heavy customisation. It has 2,397 stars, an AGPL-3.0 licence, and a commit history that has slowed since its 2016 launch, and that last fact shapes everything below.

The multi-vendor model is the reason it exists

Most e-commerce platforms model one shop with one owner. Shuup models a shop with many suppliers, each supplier owning their own products, stock and fulfilment, with the storefront and checkout unified. Orders split by supplier automatically. A vendor dashboard lets each seller manage their own catalogue without seeing anyone else's. Pricing, taxes and shipping are pluggable per supplier. If your product is "Etsy for a niche" or a B2B procurement portal with multiple wholesalers, that is 6 months of custom development handed to you.

It is also a proper Django project rather than a black box. Products, orders and customers are Django models, the admin is the Django admin extended with Shuup's own screens, and every extension point is a Python class you subclass. A developer who knows Django is productive in a day. A developer who does not is going to be miserable, because there is no app store and no theme marketplace to click through.

The add-on situation needs checking before you commit

The catalogue lists an addon system and it is real: Shuup is structured as a core plus installable Django apps for campaigns, discounts, wishlists, reviews, and so on. The complication is that Shuup the company sold some add-ons commercially, including parts of the more advanced multi-vendor tooling, and the company's focus has shifted over the years. Some of those packages are on PyPI, some are in the GitHub organisation with sparse maintenance, and some are effectively gone. Before you design around a feature, find its package, check its last release date, and confirm it installs against the current core.

The core itself is maintained but slowly. Django version support lags, releases are months apart, and issues can wait. For a marketplace that is going to be someone's business, that means budgeting developer time for keeping dependencies current yourself, which is the honest cost of picking a smaller project over a large one.

Deployment: standard Django, standard demands

There is a Docker setup in the repository and a shuup_workbench project for getting a development instance running with SQLite. For anything real you want PostgreSQL, a Redis cache, Gunicorn behind a reverse proxy, and a media volume for product images. Memory sits around the catalogue's 1 GB for a small store once Postgres and a few workers are counted; a marketplace with thousands of products and image thumbnailing wants 2 GB and a fast disk.

python -m venv venv && . venv/bin/activate
pip install shuup
python -m shuup_workbench migrate
python -m shuup_workbench shuup_init
python -m shuup_workbench createsuperuser
python -m shuup_workbench runserver

That gives you a development store at port 8000 with the sample theme. Production is the usual Django deployment work: collectstatic, a WSGI server, ALLOWED_HOSTS, a real SECRET_KEY, and a settings module of your own that imports Shuup's. Payment gateways are add-ons, and you should expect to write or adapt the one for your provider. Search is database-backed by default; large catalogues want a proper search backend.

What to run instead for a plain store

WooCommerce if you or your client will manage the shop from an admin panel and want the largest plugin ecosystem in existence. Saleor if you want a modern Python and GraphQL headless platform with an active company behind it; it is Django underneath as well, so it is the closest cousin and the stronger bet for a single-vendor build. Medusa if your team is JavaScript. All three have larger communities and faster release cycles than Shuup, and the ecommerce category and the Shopify alternatives page cover the rest of the field.

What I'd do

Build on Shuup only if the multi-vendor model is the product and the team is Django-native, and go in knowing you will maintain some of it yourself: pin every package, fork the add-ons you depend on into your own organisation, and write the payment integration as your own app from the start. For a single-vendor shop, pick Saleor and never look back. The gap between "we need suppliers as a first-class concept" and "we need a shop" is the entire decision, and most people asking about Shuup are on the second side of it.