Deploy Strategies

Every deployable service has a deploy.strategy. It is the single selector the orchestrator dispatches on — it absorbed the concept that foundry-ops previously called kind. The convention engine derives the other deploy fields (Dockerfile, build context, secrets) from stack + scope.

The enum

Strategy	Meaning
`service`	Containerized — ECS Fargate
`static`	S3 / CDN static hosting (SPA or static site)
`desktop`	Tauri desktop release — signed installers + updater manifest
`game-publisher`	UE5 game build / publish
`none`	Not deployed (libraries / packages)

Convention defaults

When a discovered service is added by foundry init, the strategy is inferred from stack: a backend defaults to service, a plain frontend to static (a Next.js frontend can be service for SSR), and a package to none. You can override any of these in the manifest.

Common deploy fields

Field	Used by	Description
`strategy`	all	The selector (required for deployable services)
`buildCommand`	`static`	Shell command that builds the static assets
`cdn`	`static`	Enable CloudFront in front of the bucket
`dockerfile` / `buildContext`	`service`	Docker build inputs (defaulted by convention)
`secrets`	`service`	Secrets to fetch from Secrets Manager into the container
`dependsOn`	all	Services/phases that must finish first (e.g. `iac`, `database:{name}`)
`iac`	all	Provider-specific deploy config passed through to IaC (compute, ALB, stack path, domain, …)

Implementation status

The deploy.strategy enum is fully defined in the schema, but the orchestrator only implements static end-to-end today. service, desktop, and game-publisher are stubbed pending engine relocation — see Orchestrator & Strategies for the live status table.