Kubernetes & OpenShift

For production workloads, Alquimia Platform runs as a Kubernetes workload with separate master and worker deployments. This separates request intake from execution, lets you scale each role independently, and supports Vault-backed dynamic credentials and SPIFFE workload identity.

Deployment topology

                         Ingress / Load balancer
                                  │
                                  ▼
              ┌─────────────────────────────────────┐
              │  alquimia-runtime master replicas   │
              │  (HTTP API + registry management)   │
              └─────────────────┬───────────────────┘
                                │ CloudEvents
                                ▼
              ┌─────────────────────────────────────┐
              │  Kafka / event bus                    │
              └─────────────────┬───────────────────┘
                                │ CloudEvents
                                ▼
              ┌─────────────────────────────────────┐
              │  alquimia-runtime worker replicas   │
              │  (agent execution via alquimia-core)│
              └─────────────────┬───────────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        ▼                       ▼                       ▼
   PostgreSQL                Redis                   Qdrant
  (persistence)           (state/cache)          (vectors/RAG)

Roles

Role	Responsibility	Scaling driver
Master	Accepts HTTP requests, manages registry, publishes events	API request rate
Worker	Consumes events and executes agents	Inference throughput

Workers are stateless. You can add replicas to increase throughput without changing the master deployment.

Deployment overlays

The runtime repository provides overlays for different environments:

Overlay	Use
Development	Vanilla Kubernetes without admission policies.
Production	Hardened overlay with image signature verification and pod security policies.
OpenShift / ROSA	Uses OpenShift’s built-in security constraints.

Choose the overlay that matches your cluster’s tooling and compliance needs.

Security considerations

• Use projected service-account tokens and the Kubernetes Vault auth method for runtime services.
• Use SPIFFE/SPIRE and the JWT Vault auth method for per-agentspace agent identities.
• Enable image signature verification in production overlays.
• Store sensitive values in Vault, not in ConfigMaps or environment variables.

Before deploying

1. Provision a PostgreSQL database, Redis cache, Qdrant vector store, Kafka cluster, and object store.
2. Set up Vault with the required auth methods, policies, and secrets.
3. Prepare image-signing verification if using the production overlay.
4. Create namespace, service accounts, and network policies.
5. Configure ingress or load balancer for the master API.

Tip

For exact manifests, secret setup, and Vault configuration, see the Runtime configuration reference.

Next steps

• Configuration — configure the runtime for your cluster.
• Scaling & production — tune throughput and reliability.
• Vault policies — set up Vault for dynamic credentials.