Skip to content

ADR-0015: Adopt Kubernetes, Artifact Registry, and Automated Env Stages for Ecosystem Knowledge Persistence

Status: accepted Deciders: User, Architecture Team, The Architect Date: 2026-03-26 Technical Story: New requirement to persist and share technical knowledge across teams.

Context and Problem Statement

As the Agentic CI ecosystem grows, the technical knowledge generated (ADRs, skills, artifacts, agents' telemetry) must be persisted and made consumable for other teams. Currently, there is no standardized artifact storage or deployment topology across the cookiecutter projects to host and serve this knowledge, which leads to siloed learning. How can we standardize the deployment and distribution of agentic knowledge across DeAcero?

Decision Drivers

  • Need for cross-team visibility and consumption of technical knowledge.
  • Consistency between local development, staging, and production environments.
  • Standardization of the deployment lifecycle across all new cookiecutter projects.
  • Native integration with GCP (Plataforma Moderna).

Considered Options

  • Option 1: Kubernetes (GKE) + Artifact Registry with Kustomize for Dev/Stg/Prod.
  • Option 2: Cloud Run + Artifact Registry with terraform workspaces.
  • Option 3: VMs with Docker Compose and local volumes.

Decision Outcome

Chosen option: "Option 1: Kubernetes (GKE) + Artifact Registry with Kustomize for Dev/Stg/Prod", because it provides a robust, scalable structure to host knowledge services, integrates natively with GCP Artifact Registry to share images/artifacts, and maps perfectly to the required automated dev/staging/production environment stages. This normalizes future projects at generation time via the cookiecutter template.

Positive Consequences

  • Future projects will have CI/CD out-of-the-box for Kubernetes covering 3 stages.
  • Artifact Registry provides a central source of truth for agent images and knowledge artifacts.
  • Dev, staging, and prod stages ensure safe rollouts and testing areas for agents.

Negative Consequences

  • Increased operational complexity for teams not familiar with Kubernetes.
  • Higher baseline infrastructure cost for new projects due to minimum cluster node requirements.

Pros and Cons of the Options

Option 1: Kubernetes (GKE) + Artifact Registry with Kustomize for Dev/Stg/Prod

  • Good, because it provides complete control over environments using Namespaces.
  • Good, because it aligns with standard enterprise practices for CI/CD separation.
  • Bad, because it requires K8s maintenance and specialized knowledge.

Option 2: Cloud Run + Artifact Registry

  • Good, because it is serverless, simpler to manage, and scales to zero.
  • Bad, because it offers less flexibility for complex stateful cross-service persistence meshes compared to Kubernetes.

Option 3: VMs with Docker Compose

  • Good, because it is extremely simple and already used for Observability.
  • Bad, because it does not scale well and lacks native staging/prod rollout orchestration.