Deployment Selection

Deployment Selection

Purpose

Choose where each application runs in production, matched to the app type and the team's real operational capacity — the most managed option that meets requirements — as a recorded, approval-gated decision. Provisioning and rollout mechanics are ../../backend/backend-deployment.

When to Use

• After applications and stack are chosen, before building the deploy pipeline.
• When re-evaluating an existing app's hosting.
• Not for the rollout procedure (../../backend/backend-deployment) or provisioning infra (out of scope — no scaffolding).

Inputs

• Selected applications and their runtimes (backend API, web/SSR, static site, mobile).
• Ops capacity, scaling/latency needs, budget, existing infrastructure.

Discovery Questions

• Per app: what is it (long-running backend, SSR web, static frontend, mobile) and what does it need (persistent processes, edge, workers)?
• What is the team's ops capacity — can they run containers/orchestration, or is managed strongly preferred?
• Scaling profile and budget? Existing cloud/platform commitments?

Responsibilities

• Match each application to candidate targets:
  • Backend API / workers → managed PaaS, container platform, or serverless — factoring persistent connections, background workers/queues (../../backend/queues), and cold-start tolerance.
  • Web / SSR → SSR-capable host / edge platform; static frontends → static/CDN/edge hosting.
  • Mobile → app stores via the mobile pipeline (../../mobile/mobile-release) — not a server host.
  • Database → managed database service (pairs with ../../database/backup-recovery), not self-hosted unless justified.
• Prefer the most managed option that meets requirements — ops burden is a permanent cost; justify any move toward self-managed.
• Record decisions with trade-offs (cost, scale, lock-in, ops) for approval (Gate 2); note what would flip each.
• Feed targets to ci-cd/github-actions (deploy jobs), docker-foundation (if containerized), staging-environment, and production-readiness.

Required Workflow

1. Classify each app by type + runtime needs.
2. Shortlist targets per app; weigh ops capacity + scale + cost.
3. Recommend the most-managed sufficient option per app with trade-offs.
4. Record for approval; note flip conditions.
5. Hand off to pipeline + readiness skills.

Decision Rules

• Most managed that meets the need — reach for containers/orchestration only when requirements demand the control.
• Serverless suits spiky/stateless workloads but weighs cold starts and persistent-connection limits (realtime, long jobs) — check against the app's needs.
• Static frontends don't belong on always-on servers; backends with workers don't fit pure static/edge.
• Target changes are stack decisions — approval required; no lock-in without acknowledging it.

Rules

• Recommend, don't pre-provision; user approves at Gate 2.
• No infrastructure scaffolding here.
• Each app's target justified against its type + ops reality.

Anti-Patterns

• One target forced onto every app regardless of type.
• Self-managed Kubernetes for a team without ops capacity.
• Serverless for a persistent-connection/long-job workload without weighing limits.
• Static site on an always-on VM; backend workers on a static host.
• Choosing a target before knowing ops capacity.

Validation Checklist

• Each app classified by type + runtime needs.
• Targets shortlisted; ops/scale/cost weighed.
• Most-managed sufficient option recommended per app with trade-offs.
• Recorded for Gate 2; flip conditions noted.
• Handed to pipeline + readiness skills.

Definition of Done

A recorded per-application deployment-target recommendation — most-managed option that meets each app's needs, with trade-offs and flip conditions — pending approval and feeding the pipeline and readiness skills.

Related Skills

../../backend/backend-deployment, ../../mobile/mobile-release, docker-foundation, ci-cd, github-actions, staging-environment, production-readiness, ../../database/backup-recovery, ../../stack-recommendation.

Related Knowledge

../../../knowledge/ (ops capacity, budget, existing infra).

Related References

../../../references/devops/ (target comparison notes, when populated).

Context Loading Guidance

• Requires: app types/runtimes, ops capacity, scale/cost constraints.
• Does not require: provisioning detail, app feature code.
• May load: ../../backend/backend-deployment, staging-environment.
• Stop when: per-app targets are recommended and recorded for approval.

Token Efficiency Guidance

The app × (target, ops cost, trade-offs) table is the artifact; decide per app against managed-first.