`.proxifai/config.yaml` schema

.proxifai/config.yaml is a tiny metadata file that lives at the root of every deployed repo. It tells ProxifAI where the K8s manifests are and how to build the image. That’s it. The actual deploy config lives in standard Kubernetes manifests under the path it points at (default: k8s/).

Why so small

The platform’s design principle is “real K8s underneath.” We deliberately avoid inventing a richer DSL because the K8s manifests in your repo are already the source of truth for what runs. .proxifai/config.yaml only carries cross-cutting platform concerns (build strategy, manifest path) that don’t fit naturally into a K8s object.

Schema

# .proxifai/config.yaml — minimal example (auto-generated)
manifests: ./k8s
build:
  type: dockerfile
  dockerfile: Dockerfile

Top-level keys

Field	Type	Default	Description
`manifests`	string	`./k8s`	Path within the repo where the Kustomize tree lives. ProxifAI runs `kustomize build <manifests>/overlays/<env>` to render.
`build`	object	required	How to turn source code into a container image.

`build`

Two strategies are supported:

Dockerfile

build:
  type: dockerfile
  dockerfile: Dockerfile        # optional, defaults to "Dockerfile"
  context: .                    # optional, defaults to "."

Used when the repo has a Dockerfile. The path is relative to the build context.

Buildpack

build:
  type: buildpack
  builder: paketobuildpacks/builder-jammy-base
  runtime: node                 # informational; auto-detected by the buildpack

Used when no Dockerfile is present and a recognized project file is detected (package.json, go.mod, requirements.txt, pyproject.toml, Cargo.toml, Gemfile, pom.xml, build.gradle, build.gradle.kts).

What’s NOT here

The platform deliberately keeps these out of .proxifai/config.yaml:

Replica count → goes in k8s/overlays/<env>/replicas-patch.yaml
Domains → k8s/base/ingress.yaml spec.rules[].host
Env vars → k8s/base/deployment.yaml spec.template.spec.containers[0].env
Secrets → kind: Secret or kind: SealedSecret referenced by the Deployment
Cron jobs → kind: CronJob in k8s/base/
Persistent volumes → kind: PersistentVolumeClaim + volumeMounts on the container

If you find yourself wanting to put something in .proxifai/config.yaml that has a perfectly good Kubernetes object for it, the answer is “use the K8s object.” That keeps the platform thin and your deploy portable to any K8s cluster.

Build pipeline details

The build runs as a Kubernetes Job in the proxifai-builds namespace:

Init container: shallow git clone of the repo at the merge commit SHA into /workspace.
BuildKit container: buildctl-daemonless.sh build with --frontend=dockerfile.v0 (Dockerfile mode) or buildpack mode, pushing to the internal registry.
Image tagged as <registry>/<owner>/<repo>:<short-sha> plus a moving <registry>/<owner>/<repo>:latest.

Cache layer is mounted from a per-org PVC at /cache. First builds take 1–3 min; subsequent builds with cache hits typically complete in 15–30s.

Integration with the rest of the platform

Push to main → forge webhook → reconciler reads latest commit SHA → submits a Build Job → image lands in registry → existing app deployment rolls to the new image
Open a PR → preview env created in pr-<N>-<repo> namespace with overlay applied
Edit in UI → proxifai-bot opens a forge PR with a Kustomize patch

The .proxifai/config.yaml itself rarely changes after the initial deploy.