GoCommerce provides the backend foundation for ecommerce applications, including commerce APIs, PostgreSQL persistence and an admin experience. It is a standalone project that pairs naturally with Svelte Commerce, and runs perfectly well without it.
GoCommerce
Catalog, carts, checkout, orders, payments, inventory, fulfillment
Svelte admin compiled into the same binary
pgx
PostgreSQL
Your database, on your infrastructure
Commerce logic as ordinary Go packages, against PostgreSQL, with an admin panel in the same binary. No proprietary control plane sits between you and your orders.
Ordinary packages, interfaces and modules. “Go to definition” works on every part of your store, including the parts you did not write.
Your server, your database, your backups. Nothing phones home, and there is no hosted tier to graduate to.
44 modules exist and a store installs the ones it needs. With none installed the engine still sells: cash on delivery and manual fulfillment are built in, because they need no third party.
The Svelte admin compiles into the binary. One artifact to build, ship and roll back.
342 operations across the engine and its modules, every one in a published OpenAPI document. The admin is a client of that contract, not an exception to it.
Money is integer minor units plus a currency code, never a float and never a formatted string. Migrations are append-only. The schema is one you could read and query yourself.
The Svelte admin is compiled directly into the GoCommerce executable, so the commerce API and the admin run from one Go process. Start with Go and PostgreSQL; add Redis, search, object storage or queues only when a real requirement asks for them.
gocommerce
├── Commerce API 238 operations
├── Embedded Svelte admin 61 screens
├── Payments
├── Orders and fulfillment
├── Inventory
├── Events and outbox
└── Installed modules 104 operations
│
▼
PostgreSQLgithub.com/jackc/pgx/v5, the Postgres driver. That is the entire require block that is not marked indirect.Real captures from a seeded instance — 64 products, 260 orders across 150 days, generated by the project’s own demo seeder with a fixed random seed. Each screen is labelled with the route it calls; every one of those routes is in the same OpenAPI document your integrations read.
Net sales for the period, orders awaiting shipment, a sales chart by day and best sellers ranked by revenue or units. The numbers come from the same reporting routes an integration can call.
Revenue, orders, products, customers — one query each
Status, variant count, price and available stock on one row, so the list answers most questions without opening a product. Sixty-four here, from the seeder.
Products, variants, per-location stock
Payment state and fulfillment state are separate columns because they are separate facts: an order can be paid and unshipped, or shipped and awaiting settlement. The list does not collapse them.
Orders, payment state, fulfillment state, totals in minor units
Stock is held per location, so a store with two warehouses does not have to fake it with one number. Low-stock is a query, not a flag somebody remembers to set.
Inventory levels, locations, low-stock query
Only the modules compiled into this build appear. There is no marketplace to browse and nothing downloaded at runtime — a module you did not import is not in your binary.
44 modules, installed by import
Nine payment modules exist; this screen shows the ones the running binary was built with. Cash on delivery is built into the engine and needs no module at all.
Stripe, Razorpay, Adyen, Paddle and five more
Zones and rates are engine concepts, so manual fulfillment works before a carrier module is installed. Add Shiprocket or USPS when you need labels, not to get started.
Zones, rates, 11 carrier modules
The admin calls 142 documented admin endpoints, and every one is in the same OpenAPI document your integrations read. There is no undocumented channel the panel uses and you cannot — those endpoints are privileged, not private.
These are engine capabilities, not customer stories — this project is too new to have the second kind, and inventing them is the fastest way to lose a developer’s trust. Each one names the primitive that does the work.
The default. Guest checkout, cash on delivery and manual fulfillment are built in, so a store sells with no modules installed at all.
Carts, checkout, orders, inventory
Pricing resolves by who is buying and how many. Customer groups share a price list, and quantity breaks apply underneath the same one-price-at-a-time rule the cart already enforces.
Customer groups, price lists, quantity pricing
Vendors are sellers on your store, not brands. New sellers arrive pending, because a marketplace that lists whoever signs up is not moderating, it is hosting whatever turns up.
Vendors, vendor offers, moderation states
Channels are storefronts over one catalogue, differing in what is published to each. A store that never creates one pays nothing for the feature.
Channels, per-channel publishing
44 modules live in the GoCommerce repository. Every one is an ordinary Go package: import it, pass it a config struct, and it is installed. Leave it out and none of its code is in your binary.
Installing a module is a slice entry, not a plugin registry
import (
"github.com/itswadesh/gocommerce/core"
stripe "github.com/itswadesh/gocommerce/ext/payments-stripe"
shiprocket "github.com/itswadesh/gocommerce/ext/fulfill-shiprocket"
meilisearch "github.com/itswadesh/gocommerce/ext/search-meilisearch"
)
modules := []gocommerce.Module{
stripe.New(stripe.Config{}),
shiprocket.New(shiprocket.Config{}),
meilisearch.New(meilisearch.Config{}),
}
app, err := gocommerce.New(gocommerce.Config{
DBURL: os.Getenv("DATABASE_URL"),
Addr: ":8080",
Currency: "USD",
AdminTokens: []string{os.Getenv("GOCOMMERCE_ADMIN_TOKEN")},
}, modules...)Adapted from examples/store/main.go. Install with go get github.com/itswadesh/gocommerce@latest.
The alternative to a commerce platform is usually months of building one, then months of finding the bugs that only appear once real money moves. This is the other option: a working backend you clone, rename and modify — with a coding agent doing much of the modifying.
One production dependency and a flat package layout, so the graph an agent has to understand is small. Comments explain why, because the code already says what.
AGENTS.md carries 18 architectural rules and skills/ carries 16 task guides — load the one that matches the job instead of reading the whole repository. Cursor, Claude, Codex and Antigravity all read these the same way.
1,036 tests. This is the part that makes agent-assisted change safe rather than fast: a wrong edit fails here instead of in a customer’s checkout.
342 operations in OpenAPI, and gocommerce doctor -json for diagnostics an agent can parse rather than screen-scrape.
The MCP module exposes the store over the Model Context Protocol. Every tool calls the same service a REST request would, so there is one place an order becomes paid, whether a person, an app or an agent asked. ReadOnly withholds every mutating tool while you are still deciding how much to trust it.
Rename it, restyle it, sell what you build with it. There is no hosted control plane to depend on and no plan to outgrow.
No cloud account, no hosted control plane, no signup. You need Go 1.27 and a PostgreSQL you can reach — or skip both with the one-command Docker stack.
Clone it, point it at a database, run it
# 1 — get the source
git clone https://github.com/itswadesh/gocommerce
cd gocommerce
# 2 — a database for it to own
createdb mystore
# 3 — where it lives, and who may administer it
export DATABASE_URL=postgres://localhost/mystore
export GOCOMMERCE_ADMIN_TOKEN=$(openssl rand -hex 32)
export GOCOMMERCE_ADMIN_EMAIL=you@example.com
export GOCOMMERCE_ADMIN_PASSWORD='a password you choose'
# 4 — migrations run on boot, then it serves
go run ./cmd/gocommerce serveAdmin panel
localhost:8080
Sign in with the email and password you just set.
API documentation
localhost:8080/docs
The OpenAPI contract this build actually serves.
The catalog
localhost:8080/api/products
Public and unauthenticated — the route a storefront calls.
./cmd/gocommerce is the reference binary and installs 39 of the 44 modules — all but cart-recovery, import-shopify, indexnow, mcp and translations — which makes it useful for reading the API contract. A real store is its own small main() that installs only what it needs — that is examples/store.
What exists in the repository today, and what is designed but not built. Every line says which. Nothing below is a separate product — these are GoCommerce capabilities, shipped or planned.
Shipped — in the repository, tested, running
Early — published, not yet proven in production
Planned — designed, not built
Commerce events — 17 of them, written through a transactional outbox in the same transaction as the state change, so an event cannot be lost or invented.
Abandoned-cart recovery — the engine records and announces cart.abandoned; the module owns the schedule, so the first sweep after install does not mail every stale basket at once.
Email and SMS — Resend, SendGrid, Twilio, MSG91. The store owns the sending account.
Order notifications — paid, shipped, delivered, refunded and returned, wired into delivery by the engine itself.
Klaviyo, newsletter, reviews, wishlists — installable modules.
Product feeds, sitemaps, IndexNow — discovery for Google and Meta.
Webhooks — so anything not on this list can be built outside the engine today.
Svelte Commerce connector — early (0.1.0). @misiki/gocommerce-connector maps this API onto the storefront’s data layer, from a shelf to a placed order; customer accounts and a search index are not covered. Connector status.
Behavioural events — product viewed, search performed, checkout started, payment failed. The engine emits order and catalog events only, so the intent half of a customer profile has no source yet.
Unified customer profile — visits, searches, carts, orders and messages on one timeline.
Dynamic segments — at risk, dormant, high value, computed rather than listed.
Automation builder — trigger, condition, wait, action, measured against revenue.
Browse abandonment and personalisation — both need the behavioural events above.
WhatsApp — no WhatsApp module exists today.
Retargeting sync, attribution, loyalty and next-best-action suggestions.
Benchmarks — none are published, which is why this site claims nothing measured about speed.
Consent, frequency caps and quiet hours are part of that design rather than an afterthought: a messaging feature that cannot be told to stop is a liability, not a feature.
The engine carries 1,036 tests and a documented contract for every route, so a pull request has something to prove itself against.
View open issues Join the DiscordFAQ
Direct answers, including the unflattering ones. If a question here has a bad answer, that is the answer.
It is 1.0, so the exported API and the HTTP contract are stable and breaking either takes a major version. The engine carries 1,036 tests and a documented contract for every route. What 1.0 does not supply is production mileage: no store we know of is running it yet. Treat it as something to build on deliberately.
One Go binary and one PostgreSQL database. The Svelte admin is compiled into the binary, so there is no Node.js server, no Redis, no message broker and no second deployment to keep in step. Add infrastructure later if a real requirement asks for it.
No. GoCommerce is a standalone backend. It serves 342 documented operations over REST, published as OpenAPI, so any storefront or application that can call HTTP can drive it. Svelte Commerce is one option in front of it, not a requirement.
Yes. GoCommerce is MIT. Rename it, restyle the admin, cut what you do not need, and ship it under your own name and domain. Nothing phones home and there is no plan to outgrow.
The repository is written for it: AGENTS.md holds 18 architectural rules for anyone changing the code, human or agent, and skills/ holds 16 task guides so an agent loads the one matching its job instead of reading everything. There is one production dependency, so the graph an agent must understand is small, and 1,036 tests to catch a wrong edit. Separately, the MCP module lets an agent operate a running store through the same domain services a REST call uses — never the database directly.
No benchmark figures are published, so this page does not quote one. Architecturally: a single compiled binary, one production dependency, the API and admin in one process, no runtime plugin loading, and integer arithmetic for money. Benchmarking is on the contribution list.
Both have engine support. B2B pricing resolves by customer group and quantity through price lists. Marketplaces have vendors as first-class sellers with pending, approved and suspended states. Neither is as deep as a dedicated platform; read core/pricing.go and core/vendors.go before committing to one.
The import-shopify module brings a whole Shopify catalogue across and matches on Shopify’s own product id, so re-running it updates rather than duplicates (titles, descriptions, status and tags; not variants, prices or stock). An Amazon importer exists for single listings and creates a new product each time. There is also an order importer that takes a created_at, fires no events unless asked and moves no stock, because loading history should not send two hundred confirmation emails.
No. There is no hosted offering, no paid tier and nothing to buy. It is MIT source you run yourself.
A Go backend and a Svelte admin, in one binary, against one database. Yours under MIT.