Deploy Targets

A deploy target is the compute substrate your service runs on once it ships. You describe a service once in the manifest; kanject aws deploy reads that contract and stands up the target. Today there are two targets — AWS Lambda and ECS Fargate — and the lifecycle is built so the target is a choice, not a different workflow.

The shape of a deploy

your .NET service              ← csproj + handlers, written once      │      │  described in      ▼manifest.json + stages/<stage>.json   ← the contract, in git      │      │  kanject aws deploy      ▼AWS Lambda  ·  ECS Fargate        ← two targets today      │      │  recorded in      ▼S3 deployment ledger              ← every release, for audit + rollback

One direction, four steps: your code is described once in the manifest and stage files, deploy reads that contract and provisions the target, and the deployment ledger records the result. The middle — the target — is the only part that changes as the platform grows.

AWS Lambda

The default target. Your service packages as a zip or a container image (set by service.packageType), fronted by an API Gateway HTTP API. Rollback is an alias flip — repointing the live alias at a prior version, no rebuild. The Deployment page covers what deploy does step by step.

• Packaging — zip (default) or container image, declared in manifest.json → service.packageType
• Edge — an API Gateway HTTP API mapped to the function
• Rollback — an alias flip to any version in the ledger, in seconds
• Isolation — a separate CloudFormation stack per stage ({stage}-{service})

ECS Fargate

For a long-running webapi that wants to run as a container. Set deployTarget: "ecs-fargate" on the entry; the deploy builds an image, registers a task definition, and promotes it through CloudFormation behind an Application Load Balancer. Rollback re-promotes the previous task definition — minutes, not the alias-flip's seconds. See ECS Fargate for the full setup.

• Packaging — a container image; runtimeMode must be webapi
• Edge — an Application Load Balancer + target group
• Rollback — re-promote a prior task definition (a stack update), preflighted
• Service shape — cpu / memory / autoscaling / ALB in stages/<stage>.json → ecs

What stays the same across targets

The point of building the lifecycle around a target is that almost nothing else moves. These are constant no matter where your code ends up running:

• The manifest — service identity, stages, and cross-repo dependencies are the contract, whatever the target.
• Env and secrets — param: and secret: references resolve the same way at deploy.
• The deployment ledger — every release is recorded in S3; kanject aws rollback reads it.
• Previews and regions — per-PR preview stacks and multi-region targets[] compose the same way.

So the workflow you learn for Lambda — scaffold, deploy, audit, roll back — is the workflow for everything that comes after it.

What a target decides

• The compute substrate, and how your code is packaged to run on it
• The resources a deploy provisions — a Lambda function + API Gateway, or an ECS service + load balancer
• The rollback mechanism — a fast alias flip for Lambda, a task-definition re-promotion for ECS Fargate

More targets coming

Lambda and ECS Fargate ship today. The lifecycle — describe, resolve env, deploy, record, roll back — is kept deliberately target-neutral so further compute targets can plug in without changing the manifest you already write. As they land, they are documented here.