# How CoreAI Builds On Runtime (/docs/coreai/how-coreai-builds-on-runtime)



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-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 [#practical-boundary]

* Runtime provides the shared operational platform
* CoreAI provides reusable AI application capabilities
* ProAI and business use cases consume both

Example [#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.