SKU.io storefront kit

A self-contained e-commerce platform for coding agents to build stores on: an Astro site with its own SQL database, a store core that owns catalog, checkout, orders, payments and the buyer portal, and a Store API so an operations system (SKU.io first) can pull orders and push inventory, fulfilments and products. Payments and mail are adapters. Think WooCommerce without WordPress, and without being tied to any processor or any host: it deploys to Cloudflare Workers + D1 by default, or to any Node server with a SQLite file (STORE_HOST=node).

npx @skuio/cli create my-store
cd my-store && npm install
npx wrangler d1 create my-store           # paste the id into wrangler.jsonc
npm run db:migrate:local && npm run seed  # schema + demo catalog into the local D1
cp .dev.vars.example .dev.vars            # manual payments + console mail work with no keys
npm run dev

Not on Cloudflare? Any Node host works the same way, with the database in one SQLite file:

export STORE_HOST=node DATABASE_PATH=data/store.db
npm run seed:sqlite                       # schema + demo catalog into the SQLite file
npm run dev                               # or: npm run build:node && npm run start:node

Then open CLAUDE.md in the new store. It explains the shape of the project to whatever agent you point at it, and names the one test that has to stay green.

Built with the kit

The stores built with the kit, with screenshots, are in the portfolio on sku.io/storefront.

How it fits together

flowchart TB
  subgraph KIT["skuio/storefront — this repo, the framework"]
    direction LR
    SDK["<b>@skuio/storefront</b> SDK<br/>store core · Store API<br/>payment + mail adapters"]
    REG["<b>registry/</b> blocks<br/>+ reference template"]
    CLI["<b>@skuio/cli</b><br/>create · add"]
  end

  subgraph SITE["A store — its own private repo, e.g. basicsolominer.com · any host: Cloudflare Workers + D1, or Node + SQLite"]
    direction LR
    subgraph FACES["Pages the store owns (copied blocks, redesigned freely)"]
      direction TB
      SHOP["Shop + checkout"]
      BUY["/account<br/>buyer portal"]
      PART["/partners<br/>affiliate dashboard"]
      OWN["/admin<br/>owner admin (light)"]
    end
    CORE[("Store core from the SDK<br/>catalog · orders · customers<br/>in the store's database")]
    API["Store API<br/>/api/skuio/v1"]
    FACES --> CORE
    API --> CORE
  end

  REG -- "copy-and-own (skuio add)" --> FACES
  SDK -- "npm dependency (npm update)" --> CORE
  CLI -. "scaffolds a new store" .-> SITE

  BUYER(["Buyer"]) --> SHOP
  BUYER --> BUY
  AFF(["Affiliate"]) --> PART
  OWNER(["Store owner"]) --> OWN

  PAY["Payment processors<br/>Stripe · PayPal · BTCPay · on-chain"]
  CORE <-- "hosted payment · webhooks" --> PAY

  ERP["<b>SKU.io</b> (or another ERP)<br/>inventory · purchasing · fulfilment<br/>returns · accounting · B2B"]
  ERP -- "pulls orders<br/>pushes stock, shipments, products" --> API
  TEAM(["Seller's operations team"]) --> ERP

The kit is this repo. A store is a separate private repo that depends on the SDK from npm and owns copies of the blocks, so a store has no git relationship to the kit. SKU.io never runs inside the store. It connects from outside as a client of the Store API: the owner approves the connection at /admin/connect, SKU.io polls new orders, stamps its own order number back, and pushes stock, shipments (the store emails tracking) and, if it owns the catalog, products and categories.

Who uses what

Person	Where	What they do
Buyer	/account (emailed sign-in link), /account/order-lookup (guest)	Order history, tracking, reorder
Partner / affiliate	/partners (emailed sign-in link)	Traffic, funnel, sources, link builder, commission owed
Store owner	/admin (password)	Orders and payments at a glance, partners and commissions, approve or revoke the connections that may use the Store API. Read-only on purpose
Seller's operations team	SKU.io, not the store	Inventory, purchasing, fulfilment and shipping, returns, accounting, B2B. Everything that changes stock or ships a box

The seller side is deliberately split. The store's /admin is just enough to run a shop that has no operations system yet and to see that orders are flowing. Real operations live in the ERP, and the ERP pushes the results back into the store.

Portability: your ERP, your host, your data

A store built on the kit is not locked to SKU.io, to a host, or to the kit.

Any ERP or OMS. The store talks to operations systems only through the Store API, a versioned contract (docs/store-api.md, OpenAPI in docs/api/) served at /api/store/v1 (and at /api/skuio/v1, the same API at the path SKU.io calls). SKU.io is one client of it, with no private hooks. Another system needs a connector that does five things:

Step	Call
Read new orders	GET /orders?updated_since=…
Write its own order number back	PATCH /orders/{id} with external_reference
Send shipments and tracking (the store emails the buyer)	POST /orders/{id}/fulfillments
Send stock levels	PUT /inventory
Optionally own the catalog	PUT /products, PUT /categories

Against any ERP with a usable API (NetSuite, Odoo, Cin7, QuickBooks Commerce…) that is days of work, not weeks, and an integration platform such as n8n can do it without code. The owner approves each system once at /admin/connect (any client_id; SKU.io's is skuio), and each gets its own revocable key, so an old and a new ERP can run side by side during a switch.

Any host. Cloudflare Workers + D1 or any Node server with SQLite (see "How a store works" above); moving between them is copying the database.

This is the beginning of the README. Read the rest at the original. Read the full README ↗