Cake Overlays

Prev Next

Overview

Cake manages infrastructure using Infrastructure as Code (IaC) principles, with a GitOps-based deployment model. This ensures reproducibility, auditability, and secure, automated workflows for infrastructure and application delivery.

All changes to the infrastructure are driven by version-controlled configuration updates committed to a customer's Git repository. Deployments to production are then orchestrated via:

  • Terraform, run through GitHub Actions, for infrastructure provisioning.

  • ArgoCD, deployed in the customer’s Kubernetes cluster, for application-level deployments.

GitOps Workflow

1. Git as the Source of Truth

All configurations live in a Git repository. Any update to infrastructure or application manifests must be made through code checked into Git. The structure follows:

/platform/deploys/<environment-name>/

Each Cake environment (e.g., staging, prod) has its own directory and corresponding base configurations.

2. Automation with Terraform & GitHub Actions

When changes are committed to the repository:

  • Terraform is triggered via GitHub Actions to provision or update cloud resources (e.g., networks, databases, IAM roles).

  • Each change can be reviewed and approved through Pull Requests before merging.

3. Continuous Delivery via ArgoCD

ArgoCD watches the Git repository and synchronizes the declared state with the live Kubernetes cluster.

  • Changes to Kubernetes manifests are automatically deployed once committed.

  • Drift detection ensures clusters remain aligned with Git.

Custom Overlays

To enable customization for individual customers or environments, Cake supports a robust overlay system called Custom Overlays. This allows users to tailor deployments without modifying core shared components.

Overlay Structure

Custom overlays reside under:

/platform/deploys/<environment-name>/overlays/

This path mirrors the base structure, ensuring a predictable organization. Overlays can modify:

  • Helm values (for Helm-managed resources)

  • Kustomize patches (for native Kubernetes YAML customization)

Example Structure

/platform/deploys/prod/

├── aiapp/

│   ├── values.yaml

│   └── kustomization.yaml

└── overlays/

   └── aiapp/

       ├── values.yaml

       └── kustomization.yaml

Note: The current overlay location is deprecated. The overlay location will be broken out from current deploys location and changed in a near term release

Types of Custom Overlays

1. Helm Value Overrides

If your component is defined using Helm, you can supply a custom values.yaml file to override the defaults. This is ideal for:

  • Changing image tags

  • Enabling or disabling feature flags

  • Adjusting resource limits, replicas, etc.

Example:

# /platform/deploys/prod/overlays/aiapp/values.yaml

aiapp:
  replicas: 3
  featureX: true

2. Kustomize Patches

For non-Helm deployments or fine-grained patching, Kustomize overlays allow you to override resources like ConfigMaps, Deployments, and Services.

Example:

# /platform/deploys/prod/aiapp/main.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4

Your kustomization.yaml could include:

resources:
  - ../../aiapp
patchesStrategicMerge:
  - patch-deployment.yaml

Applying Overlays

Once you create or update overlays:

  1. Commit the overlay files to your Git repository. NOTE: We suggest you limit who can make changes to repo and implement a PR review strategy to ensure changes make sense

  2. Terraform or ArgoCD will apply the changes:

    • For infrastructure (e.g., new DNS, IAM): Terraform handles it.

    • For Kubernetes resources (e.g., app deployments, services): ArgoCD syncs the overlay.

Make sure your overlay path is included in the kustomization.yaml in the root of the environment directory, or is referenced properly in the ArgoCD Application spec.

Best Practices

  • Avoid modifying base components directly. Use overlays to extend or modify behavior.

  • Keep overlays minimal. Only override what you need to change.

  • Use PRs for review. Always review overlay changes via pull requests.

  • Test in staging first. Validate overlays in non-production environments before promoting.

Summary

Cake's GitOps framework provides a powerful, automated, and auditable mechanism to manage infrastructure. With custom overlays, you can tailor deployments per customer or environment without disrupting shared infrastructure code. This design promotes reuse, maintainability, and safer iteration.

If you have any questions or need help designing an overlay, contact the Cake Platform team.