Velobase Harness: the monetization half of turning an AI demo into a paid product

One local command brings up Postgres, Redis and the app

The project offers two local routes and the shorter one is the developer default. You need Node.js, pnpm and Docker running, then one command.

pnpm install && pnpm dev:local

That runs the web app and the worker natively on your machine with Fast Refresh, and uses Docker only for PostgreSQL and Redis. You then open the app, choose Sign in, and pick Explore as local administrator, which needs no external service account. The first run prepares the original schema and the seed data, and later starts need only the same command. The longer route is the full stack in one line.

pnpm install && (test -f .env || cp .env.example .env) && pnpm docker:db:up && pnpm db:push && pnpm db:seed && pnpm dev:all

That copies the environment template if there is no .env, brings up the database containers, pushes the Prisma schema, seeds it and starts everything, and the app is then at http://localhost:3000 with sign-in, billing data, credits, workers, admin surfaces and a place to build your own module. A container-only preview also exists for people who do not want to edit source, using docker compose -f compose.demo.yml up --build, with the native application stopped first so port 3003 is free.

Ports and services are named so you can reason about the deployment

The environment template documents the runtime topology, which is worth reading before you deploy anything. SERVICE_MODE selects which processes start, and the options are web,worker, all, web, api, worker, web,api and web,api,worker, with the default being web and worker. The listeners are then fixed by role: the web app on port 3000, the worker on 3001 and an optional API service on 3002, with a separate API_PORT for the last one. The API service is described as an optional Hono based service. The package manifest shows the matching scripts, with dev and prod variants for the API and the worker, and a standalone script that starts web and worker together. The compose file is deliberately plain, with postgres:16 and redis:7 services, both with named volumes, and the ports overridable through POSTGRES_PORT and REDIS_PORT. That is a small enough setup to understand before you extend it.

Modules can be off, auto or on, so you switch on only what you need

The .env template describes optional module modes with the values off, auto and on, and auto is the interesting one. A module enabled in auto mode turns on when its required configuration and dependencies are present, and on means the system fails fast when something required is missing. That is a design with real operational value, because a billing and attribution system that starts up with half its modules silently disabled is hard to reason about, and one that refuses to start is at least loud. The application variables are validated by src/env.js, and the tooling and infrastructure section is described as holding the few intentional exceptions to that validation. The template also carries the branding variables, the public app URL used for payment callbacks, webhooks and referral links, and the password login list, which is empty by default so that a password field only appears for accounts that were deliberately provisioned.

Payments run through Stripe, and there is a local webhook forwarder

The compose file carries a third service, the Stripe CLI in a profile named stripe, which is how a developer gets webhook events without a public URL. It listens and forwards to the webhooks path on the host at port 3000, with verification skipped for local use, and it reaches the host through the host.docker.internal alias with an extra_hosts entry mapping that name to the host gateway. The package scripts docker:up and docker:down bring the stripe profile in and out, and the rest of the compose file is started without that profile. The database service is a separate concern, with the schema pushed through Prisma using db:push for the fast local path, db:migrate for deploying migrations, db:generate for the client and db:seed to load the seed file, with prisma studio available for looking at the data. The project is explicit that real payments require their own connection, so nothing here pretends the local flow is the production flow.

The Dockerfile is one image with a SERVICE_MODE switch

The build is designed so you do not need a separate image per service. The Dockerfile header says it is a unified file supporting all SERVICE_MODE values, and the comment above the build stage explains the reasoning: Next.js is built inside Docker, so no pre-built output directory is required on the host, and that also makes the build work on Windows by avoiding symlink issues. The build stage installs openssl and the CA certificates, enables pnpm through corepack, copies the lock file, workspace file, patches, packages and prisma directory first so the dependency layer is cached and only re-runs when the lock file changes, installs with a frozen lockfile and ignores scripts, then runs prisma generate explicitly. The runtime stage is a node:20-slim image with the system libraries Prisma, Sharp and the fonts need. The run examples map the modes to ports directly, with web and worker on 3000 and 3001, and all adding 3002.

The framework boundary is the part a product team should read

The project describes itself in two registers. For an indie builder with an AI demo, the readme points at running it locally and getting auth, billing, credits, payments, AI chat, admin, workers, analytics and anti-abuse in one repository. For a product team adding AI features, it points at a separate FRAMEWORK_GUIDE.md, described as a production boundary for modules, services, events, queues and third-party integrations, with a Chinese version alongside. The module catalog and composition documents in the docs directory continue that thread, covering how modules are administered and how code is composed. The stated target users are AI content tools, AI agent products, usage-based apps, credit-based products, indie AI products, internal AI tools that need production infrastructure, and teams adding monetization to an existing app. The stated non-targets are just as useful, since a no-code app builder, a hosted-only platform and a finished vertical product are all named as things Harness is not.

Two releases, an MIT licence and a repository that reads as a working product

The release history is short and tells you where the project is. v0.1.0, from 2026-05-26, is described as going from code to cash, open-sourced, and v0.2.0, from 2026-09-11, adds module controls and a refreshed admin. The last push to the repository was on 2026-10-15, and the repository is not archived. The licence is MIT, and the README links to a LICENSE file. The stack is stated in the badges, Next.js 15, React 19, TypeScript 5 and pnpm 10, with Tailwind and shadcn/ui in the topic list, Prisma for the data layer, tRPC in the topics, and Stripe for payments. The contributor surface is unusually complete for a project of this age, with AGENTS.md and a Chinese counterpart, CLAUDE.md, CONTRIBUTING.md, an eslint config, a playwright directory, a Makefile, a prisma.config.ts and separate Dockerfiles for the web, worker, api and demo targets, plus one for the demo dockerignore.

Editorial conclusion

Velobase Harness fits a builder or small team that already has a working AI prototype and now needs accounts, metering, credits, payments and lifecycle operations without rebuilding them, and it fits a team willing to read FRAMEWORK_GUIDE.md before writing a product module. It does not fit a team that wants a no-code builder, a hosted platform, or a finished vertical product, since the project states that plainly, and it does not fit a team unwilling to own its own authentication in production. Before you build on it, run the local stack and use the Explore as local administrator path to see the whole system, decide which modules you will actually switch on because each module can be off, auto or on, and replace the development-only password login and loopback-only local experience before anything faces a real user.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. velobase/velobase-harness on GitHub