If you want payment infrastructure you can inspect and run yourself, Zoneless is worth a look.

It is not another hosted checkout SaaS. It is an open-source payments stack for stablecoins, with checkout, subscriptions, marketplace accounts, and payouts exposed through a familiar Stripe-style API.

Zoneless lets you accept payments, manage subscriptions, and pay sellers globally in USDC from infrastructure you control.

That makes the project interesting for self-hosters, marketplace builders, and teams experimenting with stablecoin payment rails.

What is Zoneless?

Zoneless is an Apache-2.0 open-source payments platform for USDC and stablecoin workflows.

The project includes:

  • Hosted checkout for USDC payments.
  • Payment links for productized one-off payments.
  • Subscriptions with recurring billing concepts.
  • Marketplace accounts for seller onboarding.
  • Payouts and transfers for moving funds to connected accounts.
  • KYC / identity verification flows for seller review, including hosted verification sessions and Didit webhook support.
  • Webhook endpoints and events for integrations.
  • A dashboard for managing accounts, payments, products, subscriptions, balances, and settings.

The API is intentionally familiar if you have worked with Stripe before. Resources include checkout sessions, customers, products, prices, subscriptions, accounts, transfers, payouts, invoices, charges, and webhook endpoints.

Why Self-Host Zoneless?

  • Control the payment stack: Run the API, dashboard, and database on infrastructure you manage.
  • Use stablecoin rails: Test or operate USDC-based checkout and payouts instead of card-network-only flows.
  • Inspect the code: The API, dashboard, Docker setup, schemas, and operational docs are in the repository.
  • Keep a familiar API shape: Stripe-like resource names make the model easier for developers to understand.
  • Avoid black-box payout logic: Marketplace payout infrastructure is visible, auditable, and modifiable.

Zoneless vs Angular Zoneless

One important search-result gotcha: “zoneless” can also refer to Angular zoneless change detection.

This post is about zonelessdev/zoneless , the self-hosted payments platform. It does use Angular in the dashboard, and the Angular app enables provideZonelessChangeDetection(), but the project itself is payment infrastructure.

Tech Overview of Zoneless

Zoneless is a TypeScript Nx monorepo.

The main applications are:

  • apps/api: Express API backend.
  • apps/web: Angular dashboard, checkout, payment link, onboarding, and setup UI.
  • apps/cli: CLI for humans and agent-oriented workflows.
  • libs/shared-schemas: Zod schemas for shared resource validation.
  • libs/shared-types: TypeScript interfaces shared across the workspace.

The backend uses Express, Mongoose, JWTs, API keys, idempotency middleware, request context middleware, rate limiting, and Solana libraries. MongoDB is the primary database.

The frontend is an Angular 20 app served by Nginx in production. Nginx also proxies /v1/ and /api/ requests to the API container, so a single-domain deployment can serve both the UI and backend.

Key Technologies

  • Language: TypeScript.
  • Backend: Express on Node.js 20.
  • Frontend: Angular 20.
  • Database: MongoDB 7.
  • Validation: Zod shared schemas.
  • Blockchain libraries: Solana SDK packages.
  • Deployment: Docker Compose with separate API and web Dockerfiles.
  • License: Apache-2.0.

Self-Hosting Zoneless with Docker

Zoneless ships a root docker-compose.yml that starts MongoDB, the API, the dashboard, and a development MongoDB admin UI.

Pre-Requisites - Docker

Install Docker on your system before proceeding:

Verify installation: docker --version && docker compose version

Safe Deployment Note

I did not run the upstream docker-compose.yml exactly as-is on this server.

The reason is practical: the upstream Compose file uses fixed container names and common host ports:

  • zoneless-mongodb on 27017.
  • zoneless-mongo-express on 8082.
  • zoneless-api on 3333.
  • zoneless-web on 80.

On a shared homelab server, those defaults can collide with existing containers or services. For this field test, I used an isolated Compose project and modified a couple of ports so the test would not affect existing containers.

The safe test exposed the dashboard on 8423, the API on 3423, kept MongoDB internal to the Compose network, and omitted the development mongo-express service.

After starting the safe stack, access the setup UI at:

http://localhost:8423/setup

If you are connecting from another machine on the same LAN, use the server IP:

http://SERVER_IP:8423/setup

Quick Start from Upstream

The upstream quick-start path is:

git clone https://github.com/zonelessdev/zoneless.git
cd zoneless
docker compose up -d

Then open:

http://localhost/setup

From there you create the platform account, generate an API key, and connect or create a Solana wallet.

For local testing, Zoneless defaults to simulated settlement unless you configure on-chain settlement. That is the right place to start before any live USDC workflow.

Setup Flow and Solana Wallet

The setup wizard has four steps: welcome, business details, Solana wallet, and completion.

The wallet step gives you two options:

  • Generate a new Solana wallet: The keypair is generated in the browser. The UI warns that the secret key is shown once and must be saved securely.
  • Use an existing wallet: You enter an existing Solana wallet address while keeping the secret key yourself.

The setup screen describes this as self-custody by default: your secret key is not sent to Zoneless. For production, treat that wallet and any server-side signing keys as payment infrastructure secrets.

KYC and Identity Verification

Zoneless includes identity verification support for marketplace-style seller review.

The code exposes /v1/identity/verification_sessions for creating and managing verification sessions. The shared schema supports document, ID number, address, and verification-flow session types. The account settings schema includes Didit provider configuration, including API key, workflow IDs, KYB workflow ID, and webhook secret.

There are also identity rules for payout-volume thresholds, including country-specific overrides. That means a platform can require extra identity verification once sellers cross configured payout thresholds.

In practical terms: yes, Zoneless has KYC/KYB-oriented building blocks. You still need to configure the identity provider correctly and understand the compliance obligations for your use case.

Production Environment Checklist

Before putting Zoneless on the public internet, create a production env file and treat it like payment infrastructure, not a casual dashboard.

Important variables include:

DASHBOARD_URL=https://pay.example.com
APP_SECRET=replace-with-openssl-rand-hex-64
SINGLE_TENANT=true
LIVEMODE=true
SOLANA_RPC_URL=https://your-solana-rpc-provider.example

Generate the app secret locally:

openssl rand -hex 64

For production, also decide whether to use the built-in MongoDB container or a managed MongoDB service. If you keep MongoDB on the same host, enable authentication, restrict network exposure, and take backups.

Production Variables Worth Reviewing
  • DASHBOARD_URL: Public HTTPS URL for the dashboard.
  • CHECKOUT_URL: Optional dedicated checkout origin.
  • PAYMENT_LINK_URL: Optional dedicated payment-link origin.
  • MONGODB_URI: Managed or self-hosted MongoDB connection string.
  • APP_SECRET: Root secret used to derive JWT and encryption keys.
  • SINGLE_TENANT: Keep true for a normal self-hosted instance.
  • OPERATOR_API_KEY: Enables managed-hosting operator mode; leave unset for ordinary self-hosting.
  • SOLANA_RPC_URL: Required for live or on-chain settlement.
  • LIVEMODE: Set true only when ready for real USDC.
  • SETTLEMENT_RAIL: simulated or onchain in test mode; live mode is always on-chain.
  • SUBSCRIPTION_OPERATOR_KEY: Required for recurring subscription plans.
  • TRANSACTION_FEE_PAYER_KEY: Optional fee sponsor key for checkout transactions.
  • ZONELESS_TELEMETRY: Use 0 to force-disable telemetry.

Reverse Proxy Notes

The web container already uses Nginx to serve the Angular app and proxy API requests internally.

For public hosting, put the deployment behind a real HTTPS entrypoint such as Caddy, Traefik, Nginx Proxy Manager, Cloudflare Tunnel, or a VPS-level reverse proxy.

Use a single public domain first unless you have a clear reason to split dashboard, checkout, and payment links:

https://pay.example.com
https://pay.example.com/c/:checkoutSessionId
https://pay.example.com/b/:paymentLinkId

If you use separate origins for checkout and payment links, configure CHECKOUT_URL and PAYMENT_LINK_URL explicitly.

API Surface

Zoneless mounts versioned API routes under /v1.

Representative endpoint groups include:

  • /v1/accounts
  • /v1/account_links
  • /v1/customers
  • /v1/products
  • /v1/prices
  • /v1/checkout/sessions
  • /v1/payment_links
  • /v1/payment_intents
  • /v1/charges
  • /v1/subscriptions
  • /v1/invoices
  • /v1/transfers
  • /v1/payouts
  • /v1/balance
  • /v1/balance_transactions
  • /v1/webhook_endpoints
  • /v1/events
  • /v1/identity/verification_sessions
  • /v1/reporting/metrics

There is also a health check at:

/api/health

Authenticated routes are protected by API-key middleware. Payment resource routes also pass through usage tracking and idempotency middleware, which matters for retry-safe payment operations.

Local Field Note: Safe Compose Test

For this review, I cloned and inspected the repository, Docker files, Compose file, environment examples, API routes, Angular routes, shared schemas, security policy, telemetry notes, and package metadata.

I also started Zoneless with a safe Compose variant so it would not collide with existing homelab containers. The test used project name zoneless-ui-safe, container names prefixed with zoneless-safe-, and non-default host ports.

What worked:

  • The web UI loaded at http://localhost:8423/setup.
  • The API health check worked through Nginx at http://localhost:8423/api/health.
  • MongoDB became healthy inside the Compose network.
  • Setup status returned needs_setup: true.
  • The Angular web image and Express API image both built successfully.
  • Manual browser testing confirmed the setup UI worked correctly after the safe port changes.

Side note: this was not a verbatim run of the upstream Compose file. I only changed the test wiring needed for safe homelab isolation, mainly ports/container naming and excluding mongo-express.

Security and Telemetry

Zoneless includes a SECURITY.md with self-hosting recommendations:

  • Set a strong APP_SECRET.
  • Enable MongoDB authentication.
  • Use HTTPS with a reverse proxy.
  • Never commit .env files.
  • Rotate API keys periodically.

The repository also includes TELEMETRY.md. Telemetry is opt-in and off by default for self-hosted instances. It sends aggregate usage heartbeats only when enabled and LIVEMODE=true.

The telemetry document says it does not send emails, business names, domains, API keys, wallet addresses, customer PII, exact dollar amounts, request bodies, logs, or IP addresses.

Pick Zoneless If

Zoneless is most interesting if you are building:

  • A marketplace that needs seller onboarding and payouts.
  • A SaaS product that wants USDC checkout or subscriptions.
  • A developer tool that needs a Stripe-like API shape without fully outsourcing the payment stack.
  • A regional or cross-border payment experiment where stablecoins make operational sense.
  • A self-hosted payment lab where inspectability matters.

It is probably not the right first choice if you only need a simple donation button, a static crypto address, or card payments with mature chargeback handling.

Conclusion

Zoneless brings a serious self-hosting angle to stablecoin payments.

The architecture is understandable: TypeScript monorepo, Express API, Angular dashboard, MongoDB database, Docker Compose deployment, and Stripe-like resource modeling. The operational stakes are higher than a normal web app because this touches payment flows, wallets, secrets, and live USDC settlement.

Start in test mode. Keep MongoDB private. Put it behind HTTPS. Treat .env as sensitive. Back up the database. Only switch to LIVEMODE=true after you understand the full checkout, subscription, payout, and recovery path.

For a source-first look, start with the Zoneless GitHub repository and the official self-hosting docs .

FAQ

Is Zoneless a Stripe alternative?

It uses familiar Stripe-style resources and API patterns, especially around checkout sessions, customers, products, prices, subscriptions, accounts, transfers, payouts, events, and webhooks.

It is not a card processor clone. Its focus is stablecoin payment infrastructure, especially USDC checkout and payouts.

Can I self-host Zoneless with Docker?

Yes. The repository includes a root docker-compose.yml plus separate Dockerfiles for the API and web dashboard.

Review ports, container names, MongoDB security, secrets, and reverse proxy settings before running it on a server that already hosts other services.

Does Zoneless require MongoDB?

Yes. The analyzed deployment uses MongoDB as the primary database, with Mongoose in the API code and a MongoDB 7 service in Docker Compose.

For production, either secure the included MongoDB container properly or use a managed MongoDB service.

Does Zoneless use real money by default?

Local and test-mode usage defaults to simulated settlement unless configured otherwise.

LIVEMODE=true is the switch that moves the deployment toward real USDC settlement. Do not enable it until secrets, RPC configuration, wallets, backups, HTTPS, and operational recovery are ready.

Is this related to Angular zoneless change detection?

Only indirectly.

This project is a payments platform named Zoneless. Its dashboard is built with Angular and does enable Angular zoneless change detection, but the main project category is self-hosted stablecoin payment infrastructure.