Skip to content
Zava IDP

Provision a service

The golden path turns a service name into a working, governed service — no tickets, no manual Azure clicks, no copied YAML. One request in, a deployed repo out.

Request a new service

Section titled “Request a new service”
Lowercase kebab-case. The zava- prefix is added automatically.
Review the prefilled request ↗

You'll be taken to a prefilled GitHub issue. Submitting it opens the golden path — the platform provisions the repo, wires Azure OIDC (no secrets), and deploys. You get a comment with the repo and live URL.

What happens

Section titled “What happens”

  1. You submit the form. It opens a prefilled GitHub Issue (label provision). The form is just a friendly front end — the issue is the request.

  2. IssueOps takes over. The provision-from-issue workflow parses your request and runs the platform golden path in a gated platform environment.

  3. The platform provisions. A repo is created from zava-app-template, a GitHub-federated Azure identity is wired (no secrets in your repo), RBAC is scoped to a dedicated resource group, and the first deploy runs.

  4. You get a comment back on the issue with the repo link and the live URL. The issue closes itself on success.

What you get

Section titled “What you get”
  • A repo from the golden template — app, infra (Bicep), and the deploy pipeline.
  • Secretless Azure auth via OIDC federated to your repo’s dev environment.
  • A dedicated resource group (rg-<service>) — isolated blast radius.
  • Governance already on: the APM supply-chain audit gate and secure-baseline pins ship with the repo. You configure none of it.

Operators

Section titled “Operators”

The same engine backs a workflow_dispatch escape hatch for platform operators (re-runs, backfills) — see provision-golden-path. Developers should always use the form above.

Provision a service