Control platform releases
The Releases page in alphaswarm_admin (route /platform/releases, API
/admin/platform/releases/*) builds and deploys AlphaSwarm's own
repositories — the marketing website (alphaswarm_website) and the docs
site (alphaswarm_docs), which build on GitHub Actions and serve on
Cloudflare Pages.
It is the source-to-site counterpart to the Platform page, which drives
the running ECS services via boto3. Control-plane services (admin,
agentcore proxy) appear here read-only and link back to the Platform
(ECS) page, which owns their rollout.
What it shows
| Surface | Source | Purpose |
|---|---|---|
| Repository table | platform_repositories registry | Every platform repo + its deploy target (Cloudflare Pages / GitHub Actions / ECS) and readiness. |
| Credentials strip | __platform__ integration tenant | Whether the platform GitHub PAT + Cloudflare token are connected. |
| Build runs | GitHub Actions listWorkflowRuns | Recent runs of the repo's build workflow (status, conclusion, branch, actor). |
| Deployments | Cloudflare Pages deployments | Recent Pages deployments (stage, status, branch, commit, URL). |
Deploy targets
Each registered repository declares a deploy target that governs the build/deploy actions:
cloudflare_pages(website, docs) — Build dispatches the GitHub Actions build workflow (workflow_dispatch); Deploy creates a Cloudflare Pages deployment through the Cloudflare API.github_actions— build is deploy: both map to the workflowworkflow_dispatch.ecs(admin, agentcore proxy) — rolled out from thePlatform(ECS) page; the release surface lists them read-only.
How it connects
"Connecting" a platform repository has three parts:
- Registry —
alphaswarm_admin.services.platform_repositoriescatalogues the repos and their targets. Extend / override it without a code change viaALPHASWARM_ADMIN_PLATFORM_REPOS_JSON(a JSON array ofPlatformRepositoryobjects merged over the defaults bykey). - Credentials — the admin resolves a GitHub PAT (builds + run
history) and a Cloudflare scoped token (Pages deploys + history)
from the
__platform__integration tenant. Connect them through the cloud-onboarding wizard / account-integration routes (the same flow as any customer org, withorg_id=__platform__). - Workflow trigger — the target repo's build workflow must declare
on: workflow_dispatchso the admin can trigger it via the GitHub Actions REST API.alphaswarm_website/.github/workflows/deploy.ymlalready does.
Required configuration
| Env var | Purpose |
|---|---|
ALPHASWARM_ADMIN_PLATFORM_GITHUB_ORG | GitHub org/owner of the platform repos (default Alpha-Swarm-ai). |
ALPHASWARM_ADMIN_PLATFORM_RELEASES_ORG_ID | Integration tenant the GitHub PAT + Cloudflare token resolve from (default __platform__). |
ALPHASWARM_ADMIN_PLATFORM_CLOUDFLARE_ACCOUNT_ID | Cloudflare account that owns the Pages projects — required before a deploy can be triggered. |
ALPHASWARM_ADMIN_PLATFORM_REPOS_JSON | Optional registry overrides. |
Safety posture
build and deploy are destructive (they run a real pipeline
against a production site), so both are:
- Step-up-MFA gated (
require_admin_step_up("manage:infrastructure"), AGENTS rule 52) — the UI's typed-confirmation dialog arms the action and the api client transparently retries the RFC 9470 challenge. - Audit-first — a
status=pendingrow is written BEFORE the upstream call and asucceeded|failedrow AFTER, carrying the actor chain.
No GitHub PAT or Cloudflare token ever crosses the BFF boundary in a response body or log line; the providers resolve them from the encrypted integration store per call.