> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# 0049 — The Kubernetes Site Runtime as the `pharos-site-runtime` service

Status: Proposed. Applies [0040](/reference/docs/decisions/0040-platform-layout.md) and [0041](/reference/docs/decisions/0041-gitlab-waldur-services.md)
to the Instantiate and Run epic's Kubernetes Site Runtime (subtask 5B).
Date: 22 October 2026.

## Context

The Kubernetes Site Runtime pulls its Site's commands from the Site API over HTTPS
and creates Jobs, Deployments and InferenceServices in Project namespaces on behalf
of their members. Its identity is a projected ServiceAccount token, which the Site
API verifies through TokenReview and maps to the `k8s` stream. It holds no platform
database or broker credentials, so it must not share a namespace with services that
do. Until now, only the isolated test installations rendered its templates.

## Decision

1. **The Runtime is one Argo CD service, `pharos-site-runtime`,** in its own namespace
   under the `services` project: `gitops/apps/base/pharos-site-runtime.yaml` and
   `gitops/manifests/pharos-site-runtime/overlays/devbox`, built on its `base` with the
   templates' default names. Its account,
   `runtime-k8s`, is the subject the installed Site API already grants. The namespace,
   its Pod Security labels and the controller's Role stay in the Ansible bootstrap,
   and the project gains no kind.
2. **It syncs on wave 2, before `pharos`.** Its namespace grants the platform
   namespace's credentials Job one Role, to create ConfigMaps and read
   `site-api-trust`. The Job copies the Site API's CA there once and never replaces it.
3. **It installs paused.** Its production entry refuses to start until Project
   provisioning and the GitLab integration are connected.
   `scripts/check_platform_gitops.py` requires zero replicas, no platform credentials
   and a default deny in its namespace.
4. **Project namespaces and cluster-wide rules are not part of this service.**
   Project provisioning renders each Project's member and Runtime grants. The
   bootstrap or later Applications install the admission policies and KServe.

## Consequences

**Positive:** the Runtime's namespace, identity, storage, trust and network boundary
install and update with every dev box.

**Negative:** before it can run, the Runtime needs per-Project grants from Project
provisioning and its provider connections. The
in-cluster build supplies its Metallo and batch image digests, an installation hook
initialises its journals once, the bootstrap installs its admission policies and a
liveness probe watches its worker.

**Neutral:** the isolated test installations still render the same templates with
their own namespaces and names.

Update, 3 November 2026: <a href="/source/gitops/manifests/kserve/README.md.txt">KServe is a default platform dependency</a>,
with bootstrap-managed prerequisites and architecture-specific CPU serving.
The native qualification lanes reuse that managed installation.

<details class="page-source"><summary>Page source</summary>

<a href="/source/docs/decisions/0049-site-runtime-service.md.txt">Source snapshot</a> · Revision `f928834c8`.

</details>