decisionshared last reviewed 2026-05-20

All LLM / vision / OCR traffic egresses via Aspire LLM Gateway only

Context

Before 2026-05-09, Aspire apps (Postiz, KO worker-ocr, Zac landing, agents) each held their own provider keys: Anthropic OAuth, cloud-first.ai LiteLLM, OpenAI SDK, etc. Result: scattered credentials, no central budget, no spend ledger, no ability to swap providers without per-app code changes, security incidents on any one Coolify host would expose multiple provider keys.

Detail

Options considered

OptionProsCons
A โ€” Single Aspire LiteLLM proxy at llm.aspiredigital.group/v1One central budget, one set of upstream creds, OpenAI-compat clients drop in trivially, per-app virtual keys with budget capsOne more piece of infra to keep healthy
B โ€” Keep per-app provider SDKsMaximum flexibilityCredential sprawl, no central spend visibility, swap = code change
C โ€” Use cloud-first.ai as-is (single vendor)Already partially adoptedSingle-vendor lock-in; doesn't cover Claude Max OAuth or ChatGPT Pro use

Decision

We chose: Aspire LLM Gateway (option A). Self-hosted LiteLLM proxy at https://llm.aspiredigital.group/v1, deployed on Coolify, unifying Claude Max OAuth + cloud-first.ai Qwen + (future) ChatGPT Pro behind one OpenAI-compatible endpoint.

Rationale

Constraints we accepted

Revisit trigger

Gateway downtime exceeds 1 hour/month (SLA breach), OR a regulatory requirement forces per-app provider isolation (e.g., HIPAA-style separation).

Actions

Related

๐Ÿ”— Relationships

graph LR aspire_llm_gateway_only_egress["aspire-llm-gateway-only-egress"]:::self aspire_llm_gateway_only_egress --> aspire_llm_gateway["aspire-llm-gateway"] aspire_llm_gateway_only_egress --> knowledge_os_stage_1["knowledge-os-stage-1"] classDef self fill:#715EE3,color:#fff,stroke:#291F50;