How CoreAI Builds On Runtime
How CoreAI consumes the Runtime foundation.
CoreAI does not replace Runtime. It depends on Runtime to provide the secure and operational foundation on which AI application services run.
Runtime Capabilities Used By CoreAI
| Runtime capability | How CoreAI uses it |
|---|---|
| Networking and exposure | Publish the portal, APIs, MLflow, and other user-facing services |
| Identity and access | Authenticate users and services through Keycloak and related access controls |
| Secrets and certificates | Protect service credentials, client secrets, and TLS configuration |
| Inference | Run installed models through services such as KubeAI and vLLM |
| Data and storage | Persist operational state in PostgreSQL and objects in MinIO |
| Workflows | Support automation and event-driven patterns where needed |
| Observability | Collect metrics, logs, and traces from CoreAI services |
| GitOps and delivery | Deploy and update CoreAI services through Argo CD and the platform delivery chain |
Practical Boundary
- Runtime provides the shared operational platform
- CoreAI provides reusable AI application capabilities
- ProAI and business use cases consume both
Example
When a team uses CoreAI to publish a GenAI assistant, Runtime still handles ingress, certificates, storage, and inference operations. CoreAI adds the portal, APIs, model lifecycle, vector workflows, and LLM observability that make the assistant usable.