Kubernetes Setup

Deploy ABAXUS inside your Kubernetes cluster using Helm.

Prerequisites

Before deploying ABAXUS:

  • Kubernetes 1.27 or later
  • Helm 3.12 or later
  • A PostgreSQL 14+ database (managed or self-hosted)
  • Stripe or Adyen credentials (configured after initial deployment)
  • At least 2 CPU cores and 2Gi memory available in your cluster

Installing with Helm

Add the ABAXUS Helm repository:

1
2
helm repo add abaxus https://charts.abaxus.dev
helm repo update

Create a values file for your environment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# abaxus-values.yaml
global:
  postgresql:
    url: "postgresql://abaxus:yourpassword@postgres.internal:5432/abaxus_production"

api:
  replicaCount: 2
  resources:
    requests:
      memory: "512Mi"
      cpu: "500m"
    limits:
      memory: "1Gi"
      cpu: "1000m"

worker:
  replicaCount: 1
  resources:
    requests:
      memory: "256Mi"
      cpu: "250m"
    limits:
      memory: "512Mi"
      cpu: "500m"

ingress:
  enabled: true
  host: "billing.your-company.internal"
  tls:
    secretName: "billing-tls-secret"

Install:

1
2
3
4
5
6
helm upgrade --install abaxus abaxus/abaxus \
  --namespace billing \
  --create-namespace \
  --values abaxus-values.yaml \
  --set secrets.databaseUrl="postgresql://abaxus:yourpassword@postgres.internal:5432/abaxus_production" \
  --set secrets.apiMasterKey="$(openssl rand -hex 32)"

Environment Variables

The Helm chart creates a Kubernetes Secret and mounts all sensitive values as environment variables. You can also manage these manually if you prefer external secret management (External Secrets Operator, Vault Agent, AWS Secrets Manager):

VariableRequiredDescription
DATABASE_URLYesPostgreSQL connection string
API_MASTER_KEYYes32+ character random string used to derive API keys
STRIPE_SECRET_KEYConditionalStripe secret key (required if using Stripe)
STRIPE_WEBHOOK_SECRETConditionalStripe webhook signing secret
ADYEN_API_KEYConditionalAdyen API key (required if using Adyen)
ADYEN_MERCHANT_ACCOUNTConditionalAdyen merchant account name
REDIS_URLNoRedis connection string for response caching
LOG_LEVELNodebug, info, warn, error (default: info)
PORTNoHTTP port (default: 8080)

See the Configuration Reference for the complete list.


Health Checks and Readiness Probes

ABAXUS exposes health endpoints for Kubernetes probes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# In your Deployment spec (the Helm chart configures these automatically)
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 30
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3
  • /healthz — returns 200 if the process is alive and can handle requests. Returns 503 if the database connection is lost.
  • /readyz — returns 200 if the server is ready to accept traffic, including if all startup migrations have completed. Returns 503 during the initial startup migration phase.

ABAXUS runs database migrations automatically on startup. The readiness probe ensures no traffic is routed to a pod until migrations complete.


Database Migrations

Migrations run automatically when the API server starts. They are safe to run concurrently — ABAXUS uses advisory locks to ensure only one migration runner proceeds at a time, even if multiple replicas start simultaneously.

To run migrations manually (e.g., in a CI pipeline before deploying a new version):

1
2
3
4
kubectl run abaxus-migrate --rm -it --restart=Never \
  --image=ghcr.io/abaxus/abaxus:latest \
  --env="DATABASE_URL=postgresql://..." \
  -- /app/abaxus migrate up

The Operator Pattern (CRDs)

For teams that prefer GitOps-style infrastructure management, ABAXUS supports a Kubernetes Operator with Custom Resource Definitions (CRDs) for billing configuration. This lets you manage metrics, price plans, and other ABAXUS configuration as Kubernetes manifests in your Git repository.

Install the operator:

1
2
helm upgrade --install abaxus-operator abaxus/abaxus-operator \
  --namespace billing

Create a metric via CRD:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
apiVersion: billing.abaxus.dev/v1
kind: Metric
metadata:
  name: api-calls
  namespace: billing
spec:
  key: api_calls
  name: "API Calls"
  aggregation: sum
  unitLabel: calls

Apply it:

1
kubectl apply -f metric-api-calls.yaml

The operator syncs CRD state to the ABAXUS API automatically. Changes to the CRD are reflected in ABAXUS within seconds. This approach is particularly useful for teams that already manage infrastructure as code and want billing configuration in the same workflow.