Deployment Overview

Why Self-Hosted Matters

The decision to self-host your billing engine is fundamentally about data sovereignty. Your billing data — customer records, usage events, invoice history, payment method references — is among the most sensitive data your company holds. It’s the data subject to GDPR, SOC 2, HIPAA, and PCI-DSS audit requirements. It’s also the data your customers trust you to protect.

With ABAXUS, that data lives in your PostgreSQL database, in your Kubernetes cluster, inside your VPC. No ABAXUS servers ever touch it. Your billing engine calls Stripe or Adyen (to create charges), but the underlying event data, customer records, and invoice history never leave your environment. For companies with regulatory commitments, data residency requirements, or simply strong opinions about vendor access to sensitive data, this is the only acceptable deployment model.

The Components

ABAXUS has a deliberately minimal set of components to keep operations simple:

API Server

The main HTTP server that handles all API requests. Stateless and horizontally scalable. A single replica is sufficient for most teams; you can run multiple replicas behind a load balancer for high availability. Health endpoint at /healthz for readiness and liveness probes.

Background Worker

A separate process (can run as a sidecar or a separate Deployment) that handles asynchronous work:

• Applying subscription amendments when their effective time arrives
• Processing the event ingestion queue
• Running bulk invoice generation jobs

Uses PostgreSQL’s SKIP LOCKED for safe concurrent operation. Run at least one worker; multiple workers are safe due to the locking mechanism.

PostgreSQL

The only required datastore. ABAXUS uses PostgreSQL for all data: events, customers, subscriptions, invoices, metrics, and the job queue. Requires PostgreSQL 14 or later. Use your existing managed PostgreSQL (RDS, Cloud SQL, Azure Database for PostgreSQL) or deploy a dedicated instance. No special extensions required beyond the standard set.

Optional: Redis

Redis is optional and used exclusively for API response caching — specifically for the entitlement check endpoint when you want sub-millisecond p99 response times at high read volume. Without Redis, ABAXUS falls back to PostgreSQL reads for all requests, which is fast enough for most teams (< 20ms).

The Key Architectural Principle

Billing data never leaves your environment.

ABAXUS’s API server calls outbound to exactly two categories of external services:

1. Stripe or Adyen — when you trigger a charge (POST /v1/invoices/:id/charge), ABAXUS creates a PaymentIntent in Stripe or initiates a payment in Adyen using the credentials you’ve configured. Only the payment amount and your Stripe customer/payment method IDs cross this boundary — never raw event data.
2. Email provider — if you’ve configured email delivery integration, ABAXUS sends invoice notification emails via your configured SMTP or API-based email provider.

No usage events, customer records, pricing configurations, or invoice data is ever sent to ABAXUS’s own servers. The ABAXUS binary is software you run — it does not contact any ABAXUS-operated infrastructure at runtime.

Deployment Sizing

For a starting point:

ABAXUS’s memory footprint is low because heavy computation (billing calculations) is performed on demand rather than cached in memory. The main scaling bottleneck is PostgreSQL — specifically the events table as volume grows. Index your events table on (customer_id, metric_key, timestamp) for optimal query performance.

Networking Requirements

ABAXUS requires outbound HTTPS access to:

• api.stripe.com (if using Stripe)
• *.adyen.com (if using Adyen)
• Your configured email provider’s API endpoint

No inbound connections from external sources are required or made by ABAXUS itself. Your application services make inbound API calls to the ABAXUS API server within your VPC.