# 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.

**You'll learn**

- Understand what a deploy target is, and why the lifecycle is built around one
- Know the two targets that ship today — AWS Lambda and ECS Fargate
- Separate what stays constant (manifest, stages, ledger) from what a target decides
- See why rollback, audit, and previews work the same regardless of target

## The shape of a deploy

```bash
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](https://www.kanject.com/docs/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](https://www.kanject.com/docs/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.

> **Same workflow, either target:** Lambda and ECS Fargate are a choice of substrate, not a different workflow. The manifest, stages, env and secret resolution, the ledger, rollback, and previews are identical — only the target block on the entry changes.

**Recap**

- A deploy target is the compute substrate the manifest fans out to; the lifecycle is built around it.
- Two targets ship today — AWS Lambda (functions + API Gateway, alias-flip rollback) and ECS Fargate (containers + ALB, task-def rollback).
- The manifest, stages, env/secret resolution, ledger, and previews stay constant across targets.
- Set the target with `deployTarget` on the entry; see [ECS Fargate](https://www.kanject.com/docs/ecs-fargate/) for the container path.

---
_Source: https://www.kanject.com/docs/deploy-targets/ · Kanject Docs_