Deployment

This section describes how tenant subdomains are created and served in production, hosting considerations, and the third-party integrations the platform depends on. It contains no secrets or environment-specific addresses.

Subdomain provisioning

Tenant subdomains are served through a single wildcard configuration rather than per-tenant DNS entries.

One-time configuration

1. Wildcard DNS. A wildcard A record (*.<base-domain>) and the apex record point to the application server. Every tenant subdomain, including those not yet created, then resolves.
2. Wildcard TLS certificate. A single certificate for *.<base-domain> is issued through the DNS-01 challenge and renewed automatically. A wildcard certificate avoids per-certificate issuance limits that would otherwise be reached as the tenant count grows.
3. DNS-based multitenancy. Frappe is configured for DNS multitenancy so the web server routes each request to the site whose name matches the request host.

Per-tenant steps (automated during provisioning)

bench new-site {slug}.<base-domain> ...
bench setup nginx
systemctl reload nginx

Because DNS and TLS are covered by the wildcard configuration, no per-tenant DNS or certificate action is required. The tenant address becomes reachable immediately after the site is created and the web server is reloaded.

The platform service is granted a narrowly scoped privilege to reload the web server only, rather than broad administrative access.

Hosting

ERPNext is memory-intensive; each tenant maintains its own database while sharing the bench worker processes. A single mid-sized virtual server (for example, 8 vCPU and 16 GB of memory) is sufficient for the platform service, the metadata database, and an initial set of tenants. The system scales first by increasing server capacity, then by separating the database onto a dedicated host and moving provisioning to background workers.

Provider selection balances cost, latency to the target market, and data residency. Providers with an African region offer lower latency and local data residency, which can be a customer requirement, at a higher cost than value-oriented European or North American providers.

Production readiness checklist

• Point the platform database at PostgreSQL and apply migrations.
• Enable real provisioning on the host that runs the bench.
• Configure strong platform secret and API keys, and a restricted list of allowed origins.
• Configure webhook signing secrets and any callback IP allowlists.
• Run provisioning on background workers and back the rate limiter with a shared store.
• Complete the wildcard DNS, wildcard certificate, DNS multitenancy, and scoped web-server reload configuration.

Third-party integrations

Integration	Purpose	Notes
M-Pesa (Daraja)	Primary payment method for the target market	Provides sandbox and production environments. Production access requires a registered short code and provider approval.
Stripe	International card payments	Provides test and live modes.
Transactional email	Sign-up verification, welcome messages, receipts	Requires sender-domain authentication (SPF and DKIM).

All integration credentials are supplied through environment variables or a secrets manager and are never committed to a repository.