Stallora is a working multi-vendor marketplace, and a production-shaped Spring Boot microservices reference implementation. Several independent shops sell through one storefront; a basket can hold items from all of them; at checkout the order splits into one delivery per shop; each shop fulfills its own slice and is settled separately with commission taken. You get the whole thing — six services, a server-rendered storefront, two web consoles and a Flutter app for iOS and Android — as source.

Before you buy: this is six JVMs, Kafka and PostgreSQL. It requires a VPS with at least 6 GB of RAM (8 GB recommended) and Docker. Measured peak on a cold start is 3.35 GB across all thirteen containers. It will not run on shared hosting or cPanel, which cannot run Docker or a JVM at all. Payments are deliberately mocked — one interface to implement, documented step by step.

Many shops, one basket, separate payouts - thirteen containers, one docker compose up

One checkout, one delivery per shop

This is the signature interaction. A basket can hold items from any number of shops. At checkout the order splits into one sub-order per shop — each with its own subtotal, its own fulfillment status and its own settlement. Paying moves all of them at once. Stock is reserved synchronously, so overselling is impossible, and refunds are per shop inside that shop’s return window.

One checkout splitting into one delivery per shop, with the refund window open after delivery

What makes it different from a shop template

Real service boundaries. auth, catalog, inventory, order and settlement are separate Spring Boot services behind a Spring Cloud Gateway, each with its own PostgreSQL database. No service reads another’s tables.
Cross-shop consistency done properly. Stock is reserved synchronously with a conditional update, so overselling is impossible; cancellation and timeout compensate through a Saga over a transactional outbox on Kafka — at-least-once, with idempotent consumers. No distributed transaction coordinator.
Money that survives an argument. Commission resolves most-specific-first (shop, then category, then default) and is frozen onto the bill when it is created. Payouts are two-step: a seller’s request locks the bills, an admin approves. Refunded sub-orders are excluded before billing rather than clawed back. Double-layer reconciliation parks any drift for a human instead of losing it.
Self-service seller onboarding. A buyer applies from the storefront, an admin approves, and the shop is created and bound to that account in one step.
One command proves it. deploy/verify-m4.sh builds the jars, cold starts all thirteen containers and walks the entire product path with 32 assertions.

Six services, one gateway, one database each

Every client — the Flutter app, the storefront and both consoles — goes through one Spring Cloud Gateway that validates the JWT, rate limits and denies internal routes at the edge. Behind it, six services each own their own PostgreSQL database; no service reaches into another’s tables. Consistency is events plus compensation over a transactional outbox on Kafka, not a distributed transaction coordinator. One Jaeger trace crosses the gateway, the services and the queue.

Six Spring Boot services behind one gateway, one PostgreSQL database each, outbox to Kafka

Each shop settled separately

A delivered sub-order becomes billable when its return window closes — never when it was paid. Commission is resolved most-specific-first and frozen onto the bill, so changing a rule later never rewrites history you already settled. The seller requests a payout, which locks those bills so nothing is paid twice, and an admin approves before money leaves. Refunded sub-orders are excluded before billing rather than clawed back afterwards, which is why the return window and the settlement window are the same number.

The money path: delivered, return window closes, bill created, payout requested, admin approves

Who is this for

Backend and full-stack developers who want a service-boundary, Saga and outbox reference they can read, run and break — on a real domain rather than a toy example.
Teams starting a marketplace who would otherwise spend months on the parts that are easy to get wrong: cross-shop splitting, stock reservation, commission and payouts.
Agencies and studios that need a running system to demonstrate to a client this week, with the source to shape afterwards.
Developers moving from a monolith who want to see what per-service databases, idempotent consumers and compensation actually look like in working code.
Not for you if you are on shared hosting or cPanel, if you need it running on a 2 GB box, or if you want a single-vendor shop template — a much cheaper monolith will serve you better, and this one will not run at all in the first two cases.

What you get

Source for all of it — nothing is a compiled black box:

Flutter app (Dart) — one codebase for iOS and Android, no web view. Riverpod state, persisted session and cart, search, infinite scroll, per-shop order tracking, refund requests. Plus a demo mode: one build flag and the app runs the entire buyer journey with no backend at all — which is also the live preview on this page.
Six Spring Boot services (Java 21) — gateway, auth (RS256 + JWKS), catalog (PostgreSQL full-text search, image uploads), inventory, order, settlement. Flyway migrations, springdoc, Jaeger tracing across every hop including the queue.
Next.js 15 storefront — server-rendered product and shop pages, sitemap and robots.txt, search and filters, buyer sign-up, cart and checkout.
Two Refine consoles — an admin console for the platform (applications, catalog, orders, commission, bills, payouts) and a vendor portal where a seller runs their own shop and never sees anyone else’s rows.
Deployment — docker-compose for all thirteen containers, health checks, and a 16-section buyer handbook covering VPS setup, TLS, secrets, backups, database work without the command line, and swapping the mock payment gateway for a real one.

Source for all of it: Flutter app, six services, storefront, two consoles, compose, handbook

Server-rendered, so Google can read it

The storefront is Next.js 15 with product and shop pages rendered on the server, plus a sitemap and robots.txt out of the box, search, category filters and paging. Buyers can sign up on the storefront or in the app — it is the same account either way.

Server-rendered Next.js 15 storefront with sitemap, robots.txt, search and filters

The buyer app, built on the same API

One codebase, both platforms, no web view. Riverpod state, persisted session and cart, infinite scroll, and a demo mode that needs no server. Sign in, storefront, product detail, shop page and account are all finished screens, not placeholders — and every one of them calls the same gateway the web surfaces call.

Flutter buyer app: sign in, storefront, product detail, shop page and account

Sellers run their own shop

A seller manages their own products, their own stock and their own orders to ship, decides refund requests themselves, sees earnings as gross, commission taken and net owed, and requests payouts for the platform to approve. Every request takes its shop from the token, so a seller cannot ask for another shop’s rows — and the answer is 404, not 403, because a 403 would confirm the row exists.

Vendor portal: a seller's own products, stock, sub-orders, refund requests, bills and payouts

The platform side

The admin console approves or rejects seller applications, sets commission rules per shop, per category or as a default, reviews bills per shop and approves payouts, and shows parked failures so nothing is lost silently. Approving an application creates the shop and binds it to that account in one step.

Admin console: vendor applications, commission rules, bills, payouts and parked failures

Try it before you buy

Use the Live Preview button on this page to open the buyer app in your browser and click through the real screens. It is the Flutter app in demo mode — the same code that ships in the package, running the whole buyer journey with no backend behind it. Signing in, browsing across shops, a basket that spans two shops, and a split order are all live.

Get it running

1. Unzip the package
2. docker compose -f deploy/docker-compose.yml up -d
3. Wait for the health checks, then run deploy/verify-m4.sh
4. Open documentation/index.html for the 16-section handbook

Step 3 is the same gate used before release: it builds the jars, cold starts all thirteen containers and walks the entire product path with 32 assertions, so you know the whole system is healthy before you touch a single file. The database is seeded with demo shops, products and accounts, so the storefront and both consoles have real rows in them on the first boot rather than empty tables. The handbook covers VPS setup, TLS, secrets, backups, doing database work without the command line, and replacing the mock payment gateway.

Requirements

A VPS with at least 6 GB RAM (8 GB recommended) and Docker. Not shared hosting.
To build: JDK 21, Maven 3.9+, Flutter 3.29. Node is only needed if you change the web surfaces — the Docker build handles it otherwise.
Xcode 15+ / Android compileSdk 36 to ship the app to a store.

Honest limits

Payments are mocked. PaymentGateway is the seam; the handbook covers implementing it, including webhook idempotency. No processor keys ship with the item.
Single currency. Amounts are integer cents in one currency throughout; multi-currency is real work, not a setting.
No email. No SMTP, so no password reset or order emails. The hooks are obvious and documented.
Running this costs money you pay to someone else: a VPS and a domain. The item price does not include hosting, and no hosting is provided.

Support and updates

Questions go through the Comments tab on this page or my Envato profile contact form.
I aim to reply within 2 to 3 business days on working days.
Support covers bugs in the code as shipped, questions about how the included code works, and getting the documented deploy path to run.
Support does not cover custom feature development, administering your VPS or domain, implementing a real payment processor for you, or third-party integration work — the handbook documents those seams, but the work itself is a separate project.
Please read the 16-section handbook first: it already answers most deployment questions, and deploy/verify-m4.sh will tell you exactly which container is unhealthy.
Bug fixes and dependency updates are free for existing buyers.

Changelog

Version 1.0.0 — initial release.

Stallora | Flutter Multi-Vendor E-Commerce Platform with Spring Boot Microservices