Deployment workflow

Propagate replaces the former client-orchestrated serverless workflow with a local CLI + Pulumi pipeline.

Architecture

End-to-end sequence

1. Initialise

propagate init

Creates .propagate/, Pulumi state directory, global config template, and gitignore entries.

2. Authenticate

propagate login

Opens browser on propagate.prisma.events  for Cardano wallet sign-in. Optionally prompts to install the GitHub App if a workspace stack already exists and the app is not yet installed.

3. Create manifest

propagate create

Writes stack.yaml, values.yaml, and credentials.json (GitHub App install + Vercel token).

4. Validate and resolve

propagate validate

1. Parse and validate stack.yaml
2. Load app.manifest.yaml from each selected app repo
3. Build dependency graph from dependsOn
4. Topologically sort → deployment order
5. Resolve capabilities: user values, derivable URLs, generated tokens
6. Verify capability graph is closed (every requires has a provider)
7. Write resolved.json

Fails with a clear message if app.manifest.yaml is missing — run the agent task in propagate AGENT_PREPARE_APPS.md first.

5. Apply

propagate apply --yes

1. Ensure GitHub App is installed on target org (prompt if missing)
2. Mint short-lived GitHub installation token from auth server
3. Read resolved.json
4. Run Pulumi with local file backend (.propagate/pulumi-state/)
5. Per app in deployment order:
   • Fork upstream repo into target GitHub org
   • Create/link Vercel project
   • Inject resolved environment variables
   • Assign domain {appSlug}.{eventCode}.{hostName}
   • Trigger production deployment
   • Provision managed services (Upstash Redis, Railway Neo4j for timelining)
6. Snapshot stack.yaml to .propagate/last-applied/

6. Observe and maintain

propagate status    # Pulumi stack outputs
propagate diff      # manifest drift + pulumi preview
propagate destroy   # tear down for testing

Per-app provisioning steps

Each app in the catalog runs provision steps based on its manifest:

forkRepo (GitHub) → deployToVercel (Vercel) → provisionManagedServices (Upstash / Railway)

Previously these were imperative API actions polled from a Next.js server. They are now Pulumi dynamic resources in packages/infra:

• GitHubFork — forks via GitHub REST API using a GitHub App installation token (minted at apply time)
• VercelDeploy — creates project, env vars, domain, and deployment via Vercel REST API
• VercelUpstashKv — provisions Upstash Redis and connects to the timelining Vercel project
• RailwayNeo4j — provisions Neo4j Community on Railway from timelining .docker/ and injects NEO4J_* into Vercel

See Neo4j provisioning for timelining graph database setup.

Comparison with v1 (web wizard)

Event organising context

Events create exceptional circumstances for demonstrations of alternative futures. The publishing stack (docs, timelining, and future apps) gives hubs data-backed accounts of organising processes and intensives.

During event organising, hubs deploy and configure publishing applications. Propagate automates this for authorised operators while preserving data sovereignty — each app runs in the hub’s own GitHub org and Vercel team.

Currently offered apps in propagation:

1. Docs — static-site documentation with private API for page snapshots and protocol schemas
2. Timelining — Telegram bot + graph database for real-time, voice-based contribution accounting

See Publishing for per-app setup guides.