Deployment

wisp deploys directly to your own AWS account — bring-your-own-cloud. There's no separate wisp-hosted control plane in the loop.

Credentials

wisp resolves AWS credentials the same way the AWS CLI does: environment variables (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), a named profile, or an EC2/ECS instance role. Set profile in wisp.config.ts to use a specific profile instead of the default chain:

export default {
  app: "my-app",
  target: "aws",
  region: "eu-north-1",
  profile: "my-aws-profile",
};

Credentials are validated with a real sts:GetCallerIdentity call at the start of every deploy — so a missing or expired credential fails immediately with a clear message, not partway through a change set.

Stages

A stage is a named deployment environment — dev, staging, prod, or anything else. It's resolved, in order:

1. --stage <name> on the command line.
2. The WISP_STAGE environment variable.
3. "dev", if neither applies.

Every resource's physical name includes the stage (my-app-dev-orders, my-app-prod-orders), so different stages never collide within the same AWS account.

Per-branch stages

Set WISP_STAGE_FROM_GIT_BRANCH=1 to derive the stage from the current git branch instead of defaulting to dev. This is opt-in because it is rarely what you want locally: with it on, creating a branch silently retargets a brand-new, empty stack, so the next wisp dev fails until you deploy again, and a busy repo accumulates one full stack per branch. It's a good fit for CI preview environments, where exactly that isolation is the point.

The artifact bucket

The first deploy in a given account/region bootstraps a dedicated S3 bucket (wisp-artifacts-<account-id>-<region>) for bundled Lambda code and, for larger apps, nested-stack templates. This is idempotent — later deploys just reuse it.

Deploying

wisp deploy

runs synthesis, bundles every function with Bun.build, uploads artifacts, and deploys the stack via a CloudFormation change set — the same mechanism wisp deploy always uses, whether it's the first deploy or the thousandth. A change set with no changes is a no-op, not an error, so wisp deploy is safe to run repeatedly.

Tearing down

wisp destroy [stage]

Deletes the stack for the given stage. Stage names containing prod require typed confirmation first — see the CLI reference. If a Bucket still has objects in it, CloudFormation will refuse to delete it; empty the bucket and retry.