SACTL Deployment Guide

The four deployment paths, side by side

Pick by team size, ops capacity, and compliance posture. One-liner: solo / small teams go Managed; medium / large teams go K8s Helm; teams with hard isolation requirements go Self-Hosted; overseas projects go Edge.

Self-Hosted (Docker Compose)

Fits: PoC, internal testing, single-tenant private deployment, development environments. One Linux server (4 vCPU / 8GB RAM minimum) runs the full stack.

One-shot bring-up

git clone https://github.com/sactl/sactl-api.git
cd sactl-api

# Copy the env template, fill upstream key + OAuth + SMTP
cp .env.example .env
vim .env

docker compose up -d

Components

• gateway-sidecar (Go) — hot-path data plane: auth + rate limit + billing + forwarding
• admin-api (Go) — management plane: tenant / VK / billing queries
• console (React) — admin UI
• Portkey OSS — upstream routing + Key Pool
• PostgreSQL 16 — primary store
• Redis — GCRA rate limiting + billing cache
• Vault — secrets (Provider key encryption)
• MinIO — Files API binary storage
• Nginx — TLS termination + reverse proxy

First-time initialisation

make init  # does four things:
  # 1. vault operator init + unseal (5 keys, threshold 3)
  # 2. run goose migrate
  # 3. create default tenant + admin user
  # 4. generate the first Virtual Key, printed once (sk-xa-prod-***)

Upgrade and backup

• Upgrade: docker compose pull && docker compose up -d. Goose schema migrations run automatically.
• Backup: monthly pg_dump full + Vault operator snapshot, uploaded to S3 / MinIO.
• Rolling restart: docker compose restart gateway-sidecar (transparent to the hot path because Nginx fronts it).

Managed Cloud

Fits: small / medium teams, those who don't want to operate infrastructure, and customers who prefer monthly billing. SACTL hosts the full stack (PostgreSQL, Redis, Vault, MinIO, monitoring, alerting); you only integrate with the API.

Onboarding flow

1. Message Telegram support with tenant name, contact, and monthly budget cap.
2. Support provisions the tenant within 5 minutes and sends the admin portal URL plus the initial sk-xa-* Virtual Key.
3. Log in to the portal; create more VKs, set monthly budget caps, IP allowlists, allowed_models lists.
4. Point your client base_url at https://api.sactl.ai. Done.

What's different vs. Self-Hosted

• You don't need to run Vault / Postgres / Redis / MinIO yourself — SACTL handles those.
• Billing is per-token (Claude × 0.30, GPT as low as 1/30 of official) with no monthly service fee on top.
• SLA: Managed standard 99.5%; large customers can negotiate annual frame deals at 99.9%.
• Compliance: runs on the SACTL compliance stack (log allowlist, no PII at rest, HMAC VKs). If you have hard data-residency requirements, choose Self-Hosted or K8s.

Discuss specific arrangements via Telegram; pricing is volume-based.

Kubernetes (Helm)

Fits: medium / large customers, multi-AZ high-availability requirements, teams that want to reuse existing RDS / ElastiCache / Vault middleware, and HPA auto-scaling.

values.prod.yaml snippet

gatewaySidecar:
  replicas: 6
  resources:
    requests: {cpu: "500m", memory: "512Mi"}
    limits: {cpu: "2", memory: "2Gi"}
  hpa:
    enabled: true
    minReplicas: 3
    maxReplicas: 30
    targetCPUUtilizationPercentage: 60

postgres:
  external: true
  dsn: "postgres://sactl:***@rds.internal:5432/sactl?sslmode=require"

redis:
  external: true
  addr: "elasticache.internal:6379"

minio:
  external: true
  endpoint: "s3.amazonaws.com"  # or use AWS S3 directly

vault:
  external: true
  addr: "https://vault.internal:8200"
  approle: {role_id: "...", secret_id: "..."}

Install / upgrade

# Add repo
helm repo add sactl https://charts.sactl.ai
helm repo update

# First install
helm install sactl sactl/sactl-gateway \
  -f values.prod.yaml \
  -n sactl --create-namespace

# Upgrade to a specific version
helm upgrade sactl sactl/sactl-gateway \
  -f values.prod.yaml --version=N

# Rollback
helm rollback sactl PREVIOUS

External managed components

• RDS Postgres 16: db.r6g.large minimum recommended; enable PITR.
• ElastiCache Redis: cluster mode disabled; m6g.large is enough.
• Vault: self-hosted or HashiCorp Cloud. Use AppRole; inject role_id / secret_id via ExternalSecret.
• S3 / MinIO: any S3-compatible storage. Files have a 30-day lifecycle auto-purge.

Cloudflare Workers Edge Proxy

Fits: overseas projects, users distributed across 200+ countries, or teams sensitive to international acceleration. Push auth, rate limiting, and upstream routing onto Cloudflare's edge to cut cross-region latency.

Where it lives

Repository subdirectory deploy/edge-proxy/cloudflare-workers/. Contains the Worker code, a wrangler.toml template, KV namespace definitions, and CF Rate Limiting Rules config.

Capabilities

• Rate limiting: CF Rate Limiting Rules + Worker KV for lightweight GCRA
• Authentication: validate the sk-xa-* prefix and forward to the self-hosted backend for HMAC verification
• Routing: edge nodes pick the nearest SACTL self-hosted origin (Tokyo / Frankfurt / Virginia)
• Caching: prompt / response bodies are not cached (consistent with the pass-through service rule); only metadata like /v1/models is cached

Deploy

cd deploy/edge-proxy/cloudflare-workers
wrangler login

# Edit wrangler.toml: account_id / kv_namespaces.id / routes
vim wrangler.toml

# Set secrets
wrangler secret put SACTL_UPSTREAM_URL
wrangler secret put SACTL_VAULT_TOKEN

# Deploy
wrangler deploy

# Canary: cut 5% first, observe for 24h
# CF Dashboard → Workers Routes → set traffic percentage