Platform Secrets & Variables
The Ybor platform provisions a set of organization-level GitHub Actions secrets and variables into every onboarded GitHub organization. They are created and kept fresh automatically — tokens are rotated on a schedule matched to their lifetime, so your workflows never need to manage these credentials.
This page documents the P6M_ naming convention these names are migrating to, the complete list of platform-managed names, and what (if anything) you need to do.
The P6M_ convention
Every platform-managed secret and variable is named P6M_<NAME>.
# New (preferred)
artifactory-username: ${{ secrets.P6M_ARTIFACTORY_USERNAME }}
artifactory-hostname: ${{ vars.P6M_ARTIFACTORY_HOSTNAME }}
# Legacy (being retired)
artifactory-username: ${{ secrets.ARTIFACTORY_USERNAME }}
artifactory-hostname: ${{ vars.ARTIFACTORY_HOSTNAME }}
Why
- Provenance at a glance — in an org's settings page (or a workflow file),
P6M_*names are immediately identifiable as platform-provisioned and platform-rotated. Everything else is yours. - No collisions — the platform will never overwrite or delete a secret you define, because it only ever manages names on its own allow-list (see below). The prefix makes the boundary explicit.
- Safe lifecycle automation — the platform's sync reconciles and drift-cleans only the names it owns. The prefix lets it retire legacy names mechanically without ever touching customer-defined secrets.
Scope
The convention applies to org-level Actions secrets and variables managed by the platform's GitHub operator. The set of managed names is a fixed, code-reviewed allow-list — nothing is prefixed, rewritten, or deleted outside this list. Repository-level secrets and anything you create yourself are never touched.
Platform-managed names
Secrets
| Current (legacy) | New name | Purpose | Rotation |
|---|---|---|---|
REPOSITORY_PUSH_TOKEN | P6M_REPOSITORY_PUSH_TOKEN | Push access for platform repo automation (.platform, manifests) | 30 min (1h-TTL GitHub App token) |
UPDATE_MANIFEST_TOKEN | P6M_UPDATE_MANIFEST_TOKEN | Dispatching platform manifest updates for deployment | 30 min (1h-TTL GitHub App token) |
SUBGRAPH_PULL_TOKEN | P6M_SUBGRAPH_PULL_TOKEN | Read access to org repositories (e.g. federated graph composition) | 30 min (1h-TTL GitHub App token) |
SECURITY_AGENT_GITHUB_TOKEN | P6M_SECURITY_AGENT_GITHUB_TOKEN | Security agent GitHub access | 30 min (1h-TTL GitHub App token) |
PLATFORM_AGENT_GITHUB_TOKEN | P6M_PLATFORM_AGENT_GITHUB_TOKEN | Platform agent GitHub access | 30 min (1h-TTL GitHub App token) |
ARTIFACTORY_TOKEN | P6M_ARTIFACTORY_TOKEN | Artifactory CI token (username:token, base64) | Daily (7d-TTL JFrog token) |
ARTIFACTORY_IDENTITY_TOKEN | P6M_ARTIFACTORY_IDENTITY_TOKEN | Artifactory identity token for registry authentication | Daily (7d-TTL JFrog token) |
ARTIFACTORY_DOCKERCONFIG | P6M_ARTIFACTORY_DOCKERCONFIG | Docker registry auth configuration | Daily (7d-TTL JFrog token) |
ARTIFACTORY_USERNAME | P6M_ARTIFACTORY_USERNAME | Artifactory service account username | Daily (non-expiring value) |
ARTIFACTORY_HOSTNAME | P6M_ARTIFACTORY_HOSTNAME | Artifactory server hostname | Daily (non-expiring value) |
ARTIFACTORY_PROJECT | P6M_ARTIFACTORY_PROJECT | Project key in Artifactory | Daily (non-expiring value) |
Variables
| Current (legacy) | New name | Purpose |
|---|---|---|
PLATFORM_DISPATCH_URL | P6M_PLATFORM_DISPATCH_URL | Platform manifest dispatch endpoint |
PLATFORM_INSTALLATION_ID | P6M_PLATFORM_INSTALLATION_ID | GitHub App installation ID for the org |
PLATFORM_TOKEN_EXCHANGE_URL | P6M_PLATFORM_TOKEN_EXCHANGE_URL | Platform token exchange endpoint |
ARTIFACTORY_HOSTNAME | P6M_ARTIFACTORY_HOSTNAME | Artifactory server hostname |
ARTIFACTORY_PROJECT | P6M_ARTIFACTORY_PROJECT | Project key in Artifactory |
ARTIFACTORY_HOSTNAME and ARTIFACTORY_PROJECT exist as both a secret and a variable for historical reasons; prefer the variable form in workflows (vars.P6M_ARTIFACTORY_HOSTNAME).
Migration: what you need to do
The rename rolls out per-organization in three phases, designed so nothing breaks:
| Phase | What exists in GitHub | What you should do |
|---|---|---|
| Legacy-only (pre-migration) | Unprefixed names only | Nothing yet |
| Dual-write (transition window) | Both names, same values | Update workflow references from <NAME> to P6M_<NAME> at your own pace |
| Prefixed-only (after consumer migration) | P6M_* names only; legacy names removed | Done — workflows still referencing legacy names will fail |
During the dual-write window both names carry identical, equally fresh values — switching a workflow is a find-and-replace with no coordination required. Your organization will be notified before the legacy names are removed.
Related
- CI/CD Overview — where these secrets and variables are used in build workflows
- Promotion — dispatch tokens and URLs used during promotion
- Builds for existing applications — configuring repositories that predate the platform