Storecraft: a headless commerce backend you wire up in JavaScript

The assembly model: an app object built from adapters

Storecraft's central idea is visible in the README's first code sample. There is no framework import list and no configuration file. You construct an App, hand it a set of adapters, and start it:

const app = new App({
  auth_admins_emails: ['[email protected]'],
  general_store_name: 'Wush Wush Games',
  // ... MORE Mandatory CONFIG
})

Each adapter answers one question. NodePlatform decides where the code runs, LibSQL decides where the data lives, NodeLocalStorage decides where files go, Resend handles email, and the payment gateways object decides how money moves. Extensions come next, then the AI block with a model, then a vector store with an embedder, then the auth providers.

That is a different shape from a conventional commerce framework. Most arrive with a database schema, an admin interface and a configuration file, and you adapt your business to them. Storecraft gives you a wiring layer and a set of contracts, and the composition happens in code where a type checker can see it. The README calls the project extensible and modular and points to an extensions overview for the details.

The chain of with... calls also reads as the project's dependency story. Each adapter names an external service you will eventually have to pay for, and the whole object is constructed before the server ever listens.

Where it runs and where the data lives

Storecraft separates the runtime from the storage, and both are wide.

On the runtime side, the README states that it runs on any JavaScript platform and lists the platform packages: Node, Deno, Bun, Cloudflare Workers, AWS Lambda, Azure Functions and Google Functions. The same code can run on your laptop and on an edge function, serverless or serverful, because the platform adapter is what knows about the request and response objects. That is the practical payoff of the adapter pattern here, and it is a real one for teams that deploy to more than one place.

On the data side, the database list is MongoDB, libsql, SQLite, Postgres, MySQL, Neon, Turso, D1 and PlanetScale. The README links SQLite as the default-looking option and the code sample uses LibSQL. Neon, Turso, D1 and PlanetScale are hosted variants of the same SQL family, so in practice you choose between a document store and a relational one, with several hosting options on the relational side.

Storage follows the same pattern, with local, R2, S3 compatible and Google among the options. The README's badge row shows the test matrix that the project maintains: separate workflows for the core package, for MongoDB, for SQLite and Postgres and MySQL, and for S3 compatible storage. That badge set is the most informative line in the README, because it says which combinations are actually exercised on every commit rather than merely claimed.

The repository is organised as a mono-repo with npm workspaces. Each directory under packages is published to npm, and the workspace globs in package.json cover core, databases, storage, mailers, payments, extensions and SDKs.

Getting started with the CLI and the first server

The README is unusually direct about the entry point. There is a single command:

npx storecraft create

The claim next to it is that this is all the code you need to get started with your own app. What the CLI produces is a server, and the screenshot the README shows is a terminal banner rather than a browser page.

The full sample it generates wires the pieces together and then starts an HTTP server on port 8000:

http
.createServer(app.handler)
.listen(
  8000,
  () => {
    app.print_banner('http://localhost:8000');
  }
); 

Two steps before the listen call are easy to miss and easy to get wrong. There is a migration call, await migrateToLatest(app._.db, false), and a vector index creation, await app._.vector_store?.createVectorIndex(). Both are optional-chained or explicitly invoked, which tells you the vector store is not required but the database migration is part of a normal start.

The event hook is the other piece worth reading. The chain ends with an on call for the event name order/checkout/complete, with a handler that would send a team message. Events are how the rest of your application learns that something happened, and the README lists event based architecture as one of the project's characteristics, with a dedicated events page.

For the endpoint map, the README gives four locations. The AI agent lives at /chat. The dashboard lives at /dashboard. The API reference lives at /api, served by Scalar. And the README notes the REST API documentation can also be found at the /api/reference endpoint.

What the AI parts actually add

The AI story is the project's headline feature, and the README describes it as AI first, agentic, with a chat endpoint and similarity search that can serve customers and your team.

Two pieces are configured separately. The model comes from a withAI call taking an OpenAI instance with a model name, and the README says most of the popular LLMs are supported. The similarity search comes from a withVectorStore call taking a vector store plus an embedder, and here the embedder is a separate object, so the store and the model that produces embeddings are independent choices.

The agent at /chat is described as serving customers with carts, checkouts and more, with PayPal, Stripe and RazorPay for payments. So the AI surface is not a search box bolted onto a catalogue. It is an agent that can drive a checkout.

There is a limit worth stating. The README does not document how the agent decides what it is allowed to do, how prompt injection from product data is handled, or what happens when the model hallucinates a price. The vector store is described as supporting similarity search and the model as one of the popular LLMs, but the guardrail story is absent from the documentation. For a shopping agent that can complete a transaction, that gap matters more than it would for a chatbot.

The other omission is equally concrete. There is no mention of caching, rate limiting, cost controls or token budgets for the agent endpoint, and no mention of how many LLM calls a single checkout costs.

VQL and the programmable API surface

Beyond the REST API, Storecraft adds a query layer called VQL, the Virtual Query Language, which the README lists alongside similarity search as a way to query the data. The core package includes core VQL types and logic alongside the core API, core types, database types, crypto types, storage types, mailer types, payments types and platform types, plus a REST API controller.

The significance is that a headless commerce backend has to answer the same kinds of questions a storefront asks, and those questions are rarely plain CRUD. Which products are in these collections, which orders are in this state, which customers have this tag. In a hand-rolled setup that turns into a pile of endpoint-specific logic; in a framework with a query language it turns into a query you can express once.

The same reasoning applies to the programmable API claim in the README. The resources covered are products, collections, orders, customers, auth and emails, and the API is described as programmable in code as well as available over REST.

The documentation is the other part of this. The README calls the REST API well documented and points to the docs site, and the /api endpoint serves a Scalar reference that is generated from the running instance. The practical consequence is that a reader can start the server and read the exact schema of the API it exposes, which is a better onboarding experience than a static document that drifts from the code.

Limits: the schema is the framework's, and the licence is unclear

Two limits deserve emphasis, and neither is about code quality.

The first is that the data model is not yours. Storecraft provides products, collections, orders, customers, auth and emails with a fixed shape, and the migrations in the repository run against that shape. A commerce backend where you do not control the schema is a strong starting point and a poor long-term home if your business has unusual requirements. The README's own framing, rapidly build, is honest about this: it is aimed at getting a working backend quickly rather than at modelling commerce your way.

The second is the licence, and it needs care. GitHub records the licence as a custom one that it cannot classify, with a pointer to the LICENSE file, and the tree contains LICENSE.md at the root. Meanwhile the root package.json declares the licence field as ISC. Those two statements are not the same thing. The package.json field is metadata for npm and for tooling; LICENSE.md is the actual text. Read the file before you rely on either, because for a commerce backend that may handle customer data and payments, the licence question gets asked during procurement rather than after launch.

A third limit is quieter. The repository has no GitHub releases, and the last push was on 2026-05-02. Development is therefore current relative to the six month window, but there are no tagged versions to pin, no changelog entries in the README, and no visible release notes for the packages under packages/. You are tracking a moving branch, and the version in the root package.json, 1.4.2, describes the mono-repo rather than the published packages you actually install.

Storecraft against building on a bare API framework and against a hosted platform

The realistic comparison is not with another commerce framework but with the two alternatives most teams actually pick between.

The first is building on a bare web framework. Express, Hono or a similar handler library gives you a running server in an afternoon and nothing else: no product model, no order lifecycle, no payment integration, no vector search, no admin dashboard. You write the commerce domain yourself, which is a large amount of work that is not the interesting part of your product. Storecraft's contribution is precisely that layer, and the README's own list of what the core package contains is a specification of what you would otherwise write.

The second is a hosted commerce platform with its own SDK. Those give you a working backend faster than Storecraft, and they run it for you. The difference in approach is ownership of the data and the runtime. A hosted platform owns the database, the request path and the deployment, and it bills per operation. Storecraft runs in your account against a database you chose, on a runtime you chose, with the adapter as the only place the platform matters.

The honest comparison is that Storecraft sits between the two. It gives you the domain layer of a hosted platform without the hosting, and it asks you to own the deployment, the schema migrations and the operations that a hosted platform would have handled. For a team with an existing cloud setup and a need for AI features in the checkout path, that trade is often right. For a team that wants the fastest possible launch with nobody operating infrastructure, it is the wrong choice.

Editorial conclusion

Adopt Storecraft when you want a working commerce API quickly, on a runtime of your choice, with an AI shopping agent and similarity search wired in from the start rather than bolted on later. Do not adopt it if you need to own the data model outright, since the schema is the framework's, or if a proprietary licence without an SPDX identifier is a problem for your legal review. Verify first which database driver and platform adapter you will deploy, then read LICENSE.md, because the repository's package.json declares ISC while the top-level LICENSE.md is a file GitHub could not classify.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. store-craft/storecraft on GitHub