GPTibo: a self-hosted digital goods storefront with two backends

A shop, an admin panel and a partner console

GPTibo is described as a self-hosted digital goods marketplace that includes a customer front end, an administration backend and a partner workspace. The original site has stopped operating and the project is now open source under the MIT licence.

The README groups the capabilities into five modules, and the grouping tells you the shape of the system.

The customer store handles product and package display, ordering, payment status, order lookup, after sales requests, a Chinese and English interface, and light and dark themes. The administration backend covers product pricing, order and customer management, refunds, partner management, settlement and notification configuration. The partner workspace gives each partner its own store, branding, custom domain, product management, order statistics and management of sub partners.

The business backend is the part that actually moves money: authentication, payment callbacks, procurement adapters, asynchronous tasks, email notifications and transaction state management. The last module, development and deployment, covers database migrations, Docker Compose, automated tests, GitHub Actions and source security scanning.

That last line about procurement is the detail that shapes everything else. The public version contains the store side supplier adapters, and the README states plainly that it does not include the independent supply platform and the supplier execution system. So what you get is the shop without the warehouse.

One front end, two interchangeable backends

The front end is React 19 with TypeScript, Vite and Tailwind CSS. The backend comes in two implementations, and the README presents the choice as depending on your deployment environment.

The first is Go with Gin and PostgreSQL, where the API and the business worker run as separate processes. That separation is the interesting design choice: long running work such as order fulfilment and notifications runs in the worker, and the API stays responsive, which is the usual reason to split a Go service in two.

The second is Cloudflare Workers with D1, the hosted database, driven by Wrangler for local development and deployment. The advantage is that there is no server to run, and the disadvantage is that the two implementations are not identical in capability, since D1 and a PostgreSQL server are different databases with different constraints.

Email is handled with React Email, which means the templates are React components compiled into HTML, and the project has a dedicated build script for them plus a preview mode running an email development server.

The verification stack is the last row of the table: the Node.js test runner for the front end and worker business tests, Go test for the backend, and Gitleaks for scanning the source for secrets. Having all three in one project is a deliberate statement about what the maintainers check on every change.

Running the Go and PostgreSQL path

The prerequisites are Node.js 24, npm, Git and Python 3, plus Docker Compose for the Go backend, or Go 1.26 and PostgreSQL for native development.

The clone and install is standard.

git clone https://github.com/CoolkHz/gptibo.git
cd gptibo
npm ci

The Go backend lives in a subdirectory, and the sequence there initialises the local secrets, the database and the runtime roles.

cd services/storefront
python3 scripts/init-secrets.py
cp .env.example .env
docker compose config --quiet
docker compose build api
docker compose up -d --wait postgres
docker compose --profile maintenance run --rm maintenance migrate
docker compose --profile maintenance run --rm maintenance grant-runtime
docker compose up -d --wait api worker

Two details in that sequence show how carefully the project is set up. The migrate and grant-runtime steps run under a maintenance profile, so the privileged operations are separated from the long running services. And the up commands use the wait flag, so the command does not return until Postgres, and then the API and worker, are actually up rather than merely started.

The front end is then started from the repository root with a Vite command that points at the backend configuration file, and the README says the shop is then reachable on port 5175, with the front end proxying API calls to the Go API on port 8093.

Windows users have a PowerShell version of the secrets script in the backend directory.

The Cloudflare path and the local configuration files

The Workers and D1 route is shorter, because there is no database server to bring up.

cp .dev.vars.example .dev.vars
npx wrangler d1 migrations apply gptibo-local --local
npm run preview:worker

The default address is port 8787, and for hot reload of the front end you run the dev script in another terminal and use port 5173, with API requests forwarded to the local worker.

The .dev.vars file holds local configuration and the README says it should not be committed, and for a remote deployment you create your own Cloudflare resources and replace the placeholder configuration in the wrangler configuration file.

That last point is the general shape of this project. There are four example configuration files, and the README lists what each is for: the .env.example in the backend directory for the base runtime configuration, the .env.integrations.example for payment, procurement and notification integrations, the .dev.vars.example for the Cloudflare local configuration, and the wrangler configuration for the worker and D1 resources.

Two of those exist to keep secrets out of the repository, and the project ships a .gitleaks.toml and a security scan script to enforce that. The README also asks contributors not to submit real credentials, user data, production logs or databases, and points security issues at a separate policy file.

Anonymous adapters and what you must supply yourself

This is the part of the README that deserves careful reading, and it is where the limits of the open source release are stated.

The payment and supplier integrations use anonymous adapters, and you need to configure your own service before they work. The adapter names are generic on purpose: recharge, account supplier, delivery supplier and a gift related name for the supplier side, plus two anonymised aggregated payment adapters. The README instructs you to check the address, the signature, the product mapping, the amount and the callback against your own service agreement before enabling any of them.

Three further statements define what you do not get. The real merchant identity, keys, account credentials and production data are not provided with the source. The reserved example.invalid domain cannot be used for a real integration, and the sample products and amounts exist only for demonstration. And you should install into a new database, because the anonymised migrations are not compatible with the original production database.

The default configuration also does not give you a working administrator account, and you have to configure your own administrator identity, TOTP and email verification service before logging in to the admin panel. No real payments, procurement or notifications are triggered out of the box.

That is an honest design for a release of this kind. The alternative, shipping a storefront that can charge real money with the original credentials still in the configuration, would be a security problem rather than a feature.

Verification, layout and maintenance

The checks are grouped in the README by where you run them.

The four commands are npm test for the front end and worker business tests, npm run lint for the static checks, npm run build for the type checking, the email templates and the front end build, and npm run security:scan for the public source scan.

The npm test script compiles the email templates first and then runs the Node test runner over the test files, the lint script runs oxlint, and the build script runs the type check across the several tsconfig projects, builds the emails and then the front end. The security scan runs a Python script that scans the public source, which is the automated counterpart to Gitleaks.

The Go backend has its own pair of commands, the test runner across all packages and go vet.

The integration tests need a database, and the README says you set an environment variable pointing at a local database whose name ends in _test, and that the integration tests are skipped when it is not configured. The automated tests never connect to real payment or supplier services, and the README is explicit that before a production deployment you have to verify the complete transaction flow in your own environment.

The repository layout separates the front end, the two backends, the migrations, the email templates, the tests and the scripts, with continuous integration in the workflows directory and design material in a design directory. The project also carries an open source review document and an agents file.

The releases are v0.1.0 and v0.1.1, both on 2026-10-13, the second described as a fully verified open source version, and the last push was on 2026-10-14. A version 0.1 release of a system that handles payments and orders should be read for what it is: a young codebase with a wide surface, released early.

Editorial conclusion

GPTibo is worth studying if you want to run a digital goods shop on your own infrastructure with an open source codebase, since it gives you the storefront, the admin panel, the partner console and both backend options, and it does the unglamorous parts such as migrations, roles, email templates and CI. It is the wrong choice if you need it to work the moment you install it, because every payment and supplier adapter is anonymous and unconfigured, and the wrong choice if you need the original production data. Verify first that you can obtain the payment and supplier services the adapters expect, that you are comfortable with a Go and PostgreSQL or a Workers and D1 deployment, and that the anonymised migrations will not collide with any data you already hold.

Frequently asked questions

Official sources

1. CoolkHz/gptibo on GitHub
2. Issues
3. License: MIT
4. README
5. Releases