Skip to main content

Application Platform Folder Anatomy

The application repository's .platform structure is important because the .platform repository references the environmental overlays when deploying with ArgoCD.

This page is the reference for the finished layout — the folder tree and what each file is for. To build that layout up one file at a time, with a bring-your-own ConfigMap as the worked example, follow the Walkthrough.

What You'll Learn​

  • The required folder structure for .platform/kubernetes/
  • What each file does — and where the walkthrough builds it

The Folder at a Glance​

.platform
└── kubernetes
    ├── base                    # Base configuration for all environments
    │   ├── application_customizations.yaml
    │   ├── application.yaml
    │   └── kustomization.yaml
    ├── dev                     # Development environment
    │   ├── application_patch.yaml
    │   └── kustomization.yaml
    ├── stg                     # Staging environment
    │   ├── application_patch.yaml
    │   └── kustomization.yaml
    └── prd                     # Production environment
        ├── application_patch.yaml
        └── kustomization.yaml
note

The application repository's .platform structure is important because the .platform repository references the environmental overlays when deploying with ArgoCD.

What Each File Does​

Base (base/) — shared by every environment

  • kustomization.yaml — the orchestrator; lists the base resources and points at application_customizations.yaml. → Walkthrough Step 1
  • application.yaml — your main PlatformApplication manifest, holding the configuration common to every environment (deployment spec, config, secrets). → Walkthrough Step 2
  • application_customizations.yaml — tells Kustomize which field holds the container image, so CI image-tag updates land in the right place. → Walkthrough Step 2

Environment overlays (dev/, stg/, prd/)

  • kustomization.yaml — references ../base and applies that environment's patches. → Walkthrough Step 4
  • application_patch.yaml — the per-environment overrides strategic-merged onto the base PlatformApplication. → Walkthrough Step 4
Bring your own resources

The same pattern works for any Kubernetes resource you manage yourself — a ConfigMap, Secret, Service, and so on: author it in base/, add it to the kustomization, and patch it per environment. The Walkthrough works through it with a ConfigMap — shipping config files rather than a handful of environment variables — but the mechanics are identical for other resource types.