# CLI Workflows

Use workflows when you know the job you are trying to complete and need the right command sequence rather than a command-by-command reference.

**Choose the outcome**

- Deploy a Lambda service and retain a ledger-backed rollback path
- Publish a NuGet surface through candidate smoke and explicit approval
- Distribute a desktop application through local artifact proof and byte-identical promotion

- **[Deploy a Lambda service](https://www.kanject.com/docs/quick-start/)** — Create or enrol a project, configure dev, add a secret, deploy, then rehearse rollback while the context is fresh.
- **[Publish .NET packages](https://www.kanject.com/docs/packages/)** — Classify the surface, verify it, audit versions, stage candidates, build consumers, approve, and journal the release.
- **[Distribute a desktop app](https://www.kanject.com/docs/distribute/)** — Register macOS/Windows/Linux cells, prove artifacts locally, stage an RC, and promote the approved bytes.

## Preview stacks

```bash
kanject aws preview publish pr-184
kanject aws preview url pr-184
kanject aws preview extend pr-184 --by 7d
kanject aws preview rm --expired
```

Static-site previews publish under the base stage's existing CloudFront distribution. Stack-backed and static-site previews share the same live inventory, TTL, URL, extension, and cleanup commands.

## CI integration

```bash
kanject aws pipeline up
kanject aws deploy --env prod --non-interactive
```

Use `pipeline up` for AWS-native CodePipeline/CodeBuild, or run `kanject aws deploy --env <stage> --non-interactive` from GitHub Actions, GitLab, Buildkite, or any runner with .NET and AWS credentials. `--non-interactive` disables prompts; add `--yes` only when a command explicitly requires approval. The full walkthrough lives on the *CI/CD Pipeline* page.

## Local test with real env

```bash
kanject test --pull-env --env stage
```

> **Secret safety:** `--pull-env` is intentionally explicit and warns when SecureString or Secrets Manager values enter the local process.

**Recap**

- Lambda uses the deploy ledger and alias-flip rollback; packages use plans/preflight/journals; desktop uses release feeds and byte-identical promotion.
- Every path has a credential-free or non-publishing local proof before production authority enters the workflow.
- Bean & Bark pages teach the situations; Deployment, Packages, and Distribute pages remain the neutral operational references.

---
_Source: https://www.kanject.com/docs/cli-workflows/ · Kanject Docs_