Self-Hosted Commerce Backend

Ecommerce

A commerce backend: an admin interface for products and orders, an API for a storefront or mobile app to call, and background jobs; there is no storefront for customers to browse, so you build your own. You bring it up on your own machine with Docker Compose, the passwords for the administrator and the background-jobs panel are generated at random by a script, and mail the system sends goes only to a local inbox by default. Derived from a frozen snapshot of an open-source e-commerce starter project under the MIT licence; the delivery adds a Dockerfile that builds the image from source, an orchestration file for three services, a script that generates the keys and passwords, and a quick-start guide in Traditional Chinese.

Subscribe & download See how to start

SubscriptionUS$49 per month

Last run2026-11-02

In practice

Readiness4 / 5

What you need

Few changes needed4 / 5

Who it is for

Developers and small merchants who want to hold their own product, order and customer data and plan to build their own customer storefront or mobile app.

How to start

$ sh scripts/quickstart/init-env.sh
$ docker compose up -d --build

Browse the files

Files in the product repository at the pinned commit. A few house files are left out of the zip.

File overview391 paths

▸app8

assets/
controllers/
helpers/
jobs/
mailers/
models/

▸bin9

brakeman
bundle
dev
docker-entrypoint
jobs
rails
rake
rubocop
setup

▸config22

application.rb
boot.rb
cable.yml
database.yml
environment.rb
environments/
initializers/
locales/
puma.rb
queue.yml
…

▸db310

migrate/
schema.rb
seeds.rb

▸lib1

tasks/

▸log1

.keep

▸scripts1

quickstart/

▸spec7

models/
rails_helper.rb
requests/
spec_helper.rb
support/

▸storage1

.keep

▸tmp2

.keep
pids/

▸vendor1

.keep

▫AGENTS.md

▫ATTRIBUTION.md

▫Brewfile

▫CLAUDE.md

▫Dockerfile

▫Gemfile

▫Gemfile.lock

▫LICENSE-99LL.md

▫LICENSE.md

▫PRODUCT.md

▫QUICKSTART.md

▫README.md

▫Rakefile

▫SECURITY.md

▫config.ru

▫delivery-manifest.txt

▫docker-compose.yml

▫Config and hidden files 11

Latest passing run

Clone → Checkout → Toolchain → Build images → Admin panel and jobs login

Pre-purchase Disclosure

What you are buying

A self-hosted commerce backend system: an admin interface for products and orders, an API for a storefront or mobile app to call, and background jobs. There is no storefront for customers to browse; you build your own. You bring it up with Docker Compose.

Derived from an open-source e-commerce starter project under the MIT licence, and not the original project itself. Our work: a Dockerfile that builds the image from source, an orchestration file for three services, a password generation script and a quick-start guide in Traditional Chinese.

Delivery is a frozen snapshot: one zip, taken from the product repository at revision 292495b.

Known limitations

The commerce core is a pre-release version that has not been formally released
There is no storefront for customers to browse; you build your own
No keys are filled in for any payment or shipping service, and there is no search or cloud file storage
The service serves plain HTTP on port 3000 of the local machine; TLS and a reverse proxy are yours to bring
Before opening it to the outside, the domain and https settings must be changed to your own values
Mail the system sends goes only to the local inbox by default and is not sent to real mailboxes
To send real mail, fill in your own mail service in .env
The admin interface may contain preview pages for enterprise features that link to the upstream website
The three data-encryption keys and the database password cannot be changed after the first start
Sample data is loaded by you, and product images are downloaded over the network
The database backup command does not include uploaded files
The data lives in Docker named volumes, and docker compose down -v deletes all of it
The first start builds the image from source, fetching from registries, apt and package repositories during that time
Pinned to the delivered snapshot; it does not follow upstream.

The liability cap, the scope of what is promised and the statutory floor are governed by the Terms of Service.

Vetting record

Everything below was checked against the pinned commit ad64e17. Every verdict carries its full reasoning, an evidence link and the checker; failures are published, not hidden — do not take our word for it, verify it yourself.

5 PASS0 WARN0 FAIL

Source ReviewPASS

Execution surface of the delivery reviewed item by item. Our own additions were read line by line: docker-compose.yml (the published port is bound to 127.0.0.1 only; the database opens no port; it refuses to start when any key, the database password or the administrator credentials are missing; the database and uploads use named volumes; mail the system sends goes to the local inbox by default) and scripts/quickstart/init-env.sh (openssl generates random values, .env is mode 600, an existing .env is not overwritten). The Dockerfile is upstream’s own file with only the base images pinned by digest and the admin-interface template version pinned, and was also read line by line. The upstream Ruby and front-end sources were not read file by file; the basis is the MIT licence and container isolation.

Script SafetyPASS

The scripts on the buyer’s delivery path were each inspected: init-env.sh is ours (read line by line); the build goes through the Dockerfile (read line by line: Ruby packages installed from the lock file, the admin-interface template taken with npm pack at a pinned version and unpacked for use, system packages from apt, with no download piped straight into a shell); the container start goes through upstream’s bin/docker-entrypoint (seven lines, read: it prepares the database before the web server starts).

RecencyPASS

This product is a frozen snapshot and does not follow upstream: the upstream source is pinned to the main-line revision taken on the day the product repository was created (see the evidence link), and the product repository is that snapshot plus our own commits.

LicensePASS

SPDX:LicenseRef-99LL-Product

Upstream LICENSE was checked word for word (the evidence link points at the file itself at the pinned version and matches the copy inside the product repository): the standard MIT text, copyright holders Vendo Connect Inc. and Vendo Sp. z o.o. It allows commercial use, modification, derivative works, redistribution and sale; the duty is to keep the copyright notice and licence text (LICENSE.md and ATTRIBUTION.md ship in the zip); upstream has no NOTICE file. The decision does not rest on GitHub’s licence field. For the product as a whole the 99LL product licence template is attached: upstream’s licence file is kept as it is and LICENSE-99LL.md is added as the sale and liability terms for the part we built, with spdx recorded as LicenseRef-99LL-Product.

Dependency LicensesPASS

This records the declared side, not a scan result: the Ruby dependencies are declared in the Gemfile and locked by Gemfile.lock, the front-end dependencies of the admin-interface template are declared by the template’s own package.json, and the packages themselves are fetched from their own repositories when the buyer builds; the base images and system packages come from a registry and apt. These dependency trees were not scanned package by package for licences. Upstream has no submodule and no third-party dataset was copied in (see ATTRIBUTION.md).