Skip to content

Deployment

Deployment docs should keep infrastructure provisioning, app release orchestration, and static docs publishing as separate surfaces.

  • Frontend application.
  • Backend API.
  • Pulumi-managed infrastructure.
  • Supporting services such as database, media storage, registry, ingress, DNS, and control plane.
  • Static documentation site.

The reviewed dev application topology figure shows the current Pulumi-visible deployed-dev surface. Runtime database and volume state are intentionally left as an explicit caveat until they are modeled as separate topology nodes.

Topology diagram showing the dev application public web surface, control plane, runtime, media storage, and image registry relationships.

Dev application deployment topology generated from reviewed semantic topology data. Reviewed Mermaid source: fig-dev-application-deployment.mmd.

  • App/API runtime deployment and infrastructure provisioning are separate surfaces.
  • Docs deployment is a static lane and does not use the EC2 app runtime, backend, database, wake path, or container host.
  • Routine branch CD targets the conservative deployed-dev endpoint profile.
  • Heavier browser, seeded-data, media, and lifecycle proofs remain manual/profile-scoped until repeated signal justifies promotion.
  • Generated private infrastructure artifacts should not be uploaded directly to the public docs site.

Raw topology captures flow through a private artifact lane first; only reviewed and sanitized projections should enter the docs app.

  • Versioned public docs and PR previews.
  • Automated generated topology publishing.
  • Staging/production promotion automation.