Self-hosted billing
Self-hosted payment layer
Run one small payment layer for all your side projects while Stripe or Polar keeps handling checkout, invoices, taxes, and payment methods.
What self-hosting buys you
A self-hosted payment layer lets you keep the app-facing billing state close to your projects. You still outsource payment complexity to Stripe or Polar, but you own the bridge between provider events and product access.
- Use your own domain for dashboard, API, pay routes, and registry files.
- Keep provider keys encrypted in your deployment.
- Share one deployment across many small tools.
- Inspect the data model and operational behavior directly.
What vantezzen/pay runs
vantezzen/pay is a small billing service, not a payment processor. It runs the dashboard, public API, checkout creation, webhook ingestion, wallet ledger, product catalog, and shadcn registry.
- Dashboard pages for projects, providers, products, prices, orders, wallets, and webhooks.
- Public client APIs for wallets, checkout, credits, and feature access.
- Webhook routes for Stripe and Polar provider accounts.
- Registry files for installing app-side components.
Recommended deployment model
Use a boring deployment. The product sits in the payment path, so predictable infrastructure matters more than novelty.
- Deploy the Next.js app to a platform that can run server routes.
- Use managed Postgres from a provider you already trust.
- Set a stable public URL before configuring provider webhooks.
- Monitor webhook failures and keep provider dashboards as the money source of truth.
The app integration stays small
Each project only needs its publishable key, allowed origins, installed components, and the paid actions that call vantezzen/pay. The provider wiring stays inside the shared payment layer.
npx shadcn@latest add https://pay.example.com/r/pay-client.json
npx shadcn@latest add https://pay.example.com/r/pay-provider.json
npx shadcn@latest add https://pay.example.com/r/pay-credits.jsonFAQ
Does self-hosting mean I handle card data?
No. Checkout still happens with Stripe or Polar. vantezzen/pay stores app-facing billing state and provider references, not card details.
Can one vantezzen/pay deployment power multiple projects?
Yes. A project maps to one app and has its own API keys, products, prices, and allowed origins.
Do I need a dedicated Stripe or Polar account?
A dedicated provider account is recommended when possible because vantezzen/pay manages catalog objects and webhooks for the connected account.
Run billing once, reuse it everywhere
Deploy vantezzen/pay on your domain, connect a provider, then plug each new side project into the same payment layer.
Related