CLI Reference

Command Index

Command	Phase	Purpose
`kindling init`	Setup	Bootstrap Kind cluster + operator
`kindling runners`	Setup	Register CI runner pool (GitHub/GitLab)
`kindling explain`	Setup	On-demand kindling concepts/workflow guidance
`kindling analyze`	Setup	Check project readiness
`kindling generate`	Setup	AI-generate CI workflow
`kindling deploy`	Develop	Apply DSE from YAML file
`kindling push`	Develop	Rebuild + redeploy one service via CI
`kindling sync`	Develop	Live-sync files into running pod
`kindling debug`	Develop	Attach VS Code debugger to deployment
`kindling dev`	Develop	Frontend dev server with cluster access
`kindling load`	Develop	Build + load image into Kind directly
`kindling dashboard`	Develop	Launch web dashboard
`kindling expose`	Develop	Public HTTPS tunnel to cluster
`kindling env`	Develop	Manage deployment env vars
`kindling secrets`	Develop	Manage external credentials
`kindling ingress`	Develop	Manage extra Ingress routes on a DSE
`kindling deps`	Develop	Manage shared dependency resources
`kindling status`	Develop	Cluster + environment status
`kindling logs`	Develop	Tail controller logs
`kindling snapshot`	Staging	Export Helm/Kustomize + deploy
`kindling staging tls`	Staging	Configure TLS with cert-manager
`kindling reset`	Lifecycle	Remove runner pool, keep cluster
`kindling destroy`	Lifecycle	Delete cluster and all resources
`kindling version`	—	Print CLI version

Installation

brew install kindling-sh/tap/kindling

Build from source:

cd kindling && make cli
sudo cp bin/kindling /usr/local/bin/

Global Flags

Flag	Short	Default	Description
`--cluster`	`-c`	`dev`	Kind cluster name
`--project-dir`	`-p`	`.`	Path to kindling project root

Setup

`kindling init`

Synopsis: kindling init [flags]

Bootstrap a Kind cluster with the kindling operator, ingress controller, and in-cluster registry.

Steps: preflight checks → kind create cluster → switch kubectl context → install Traefik ingress + registry → load operator image → apply CRDs → deploy operator → wait for rollout.

Recommended resources:

Workload	CPUs	Memory	Disk
Small (1–3 services)	4	8 GB	30 GB
Medium (4–6 services)	6	12 GB	50 GB
Large (7+ services)	8+	16 GB	80 GB

Flags:

Flag	Default	Description
`--skip-cluster`	`false`	Skip Kind cluster creation (use existing)
`--build`	`false`	Build operator from source instead of pulling
`--operator-image`	`ghcr.io/kindling-sh/kindling-operator:latest`	Operator image to pull
`--image`	—	Kind node image (e.g. `kindest/node:v1.29.0`)
`--kubeconfig`	—	Path to write kubeconfig
`--wait`	—	Wait for control plane (e.g. `60s`, `5m`)
`--retain`	`false`	Retain nodes for debugging
`--expose`	`false`	Start HTTPS tunnel after bootstrap

Examples:

kindling init
kindling init --build
kindling init --expose
kindling init --image kindest/node:v1.29.0
kindling init --skip-cluster

`kindling runners`

Synopsis: kindling runners [flags]

Create a CI runner pool. Supports GitHub Actions (default) and GitLab CI.

Flags:

Flag	Short	Default	Description
`--username`	`-u`	—	CI platform username
`--repo`	`-r`	—	Repository (`owner/repo` or `group/project`)
`--token`	`-t`	—	PAT or runner registration token
`--ci-provider`		`github`	`github` or `gitlab`

Examples:

kindling runners -u myuser -r myorg/myrepo -t ghp_xxxxx
kindling runners --ci-provider gitlab -u myuser -r mygroup/myproject -t glpat_xxxxx

`kindling explain`

Synopsis: kindling explain [topic]

Prints short, current guidance on kindling concepts and workflows (e.g. debugging/hot-reload, dependency auto-injection, Kaniko build constraints, secrets flow, staging graduation) — pulled on demand instead of injected into every coding-agent session. Run with no arguments to list topics.

kindling explain
kindling explain debugging

`kindling analyze`

Synopsis: kindling analyze [flags]

Check project readiness before generating a workflow. Detects Dockerfiles, dependencies (15 types), secrets, agent frameworks (LangChain, CrewAI, LangGraph, OpenAI Agents SDK, MCP), inter-service communication, and build context alignment.

Flags:

Flag	Short	Default	Description
`--repo-path`	`-r`	`.`	Path to the repository
`--verbose`	`-v`	`false`	Show additional detail

See Analyze for full reference.

`kindling generate`

Synopsis: kindling generate [flags]

AI-generate a CI workflow for any repository. Scans for Dockerfiles, dependencies, ports, health checks, Helm charts, Kustomize overlays, docker-compose files, .env templates, and agent frameworks. Produces a complete GitHub Actions or GitLab CI workflow.

Flags:

Flag	Short	Default	Description
`--api-key`	`-k`	— (required)	GenAI API key
`--repo-path`	`-r`	`.`	Path to the repository
`--ai-provider`		`openai`	`openai` or `anthropic`
`--model`		auto	Model name (default: `o3` / `claude-sonnet-4-20250514`)
`--output`	`-o`	auto	Output path for workflow file
`--dry-run`		`false`	Print to stdout instead of writing
`--ingress-all`		`false`	Wire every service with an ingress
`--no-helm`		`false`	Skip Helm/Kustomize rendering
`--ci-provider`		`github`	`github` or `gitlab`
`--shared-deps`		—	Comma-separated dependency types (e.g. `redis,postgres`) to mark `shared: true` across all detected services

Examples:

kindling generate -k sk-... -r .
kindling generate -k sk-... -r . --dry-run
kindling generate -k sk-ant-... -r . --ai-provider anthropic
kindling generate -k sk-... -r . --ci-provider gitlab
kindling generate -k sk-... -r . --ingress-all
kindling generate -k sk-... -r . --shared-deps redis,postgres

Develop

`kindling deploy`

Synopsis: kindling deploy -f <file>

Apply a DevStagingEnvironment from a YAML file (manual deploy).

`kindling push`

Synopsis: kindling push -s <service>

Rebuild and redeploy a single service via CI. Verifies workflow secrets and workflow file exist before triggering.

`kindling sync`

Synopsis: kindling sync [flags]

Live-sync local files into a running pod with language-aware hot reload. Automatic rollback on Ctrl+C.

Restart strategies (auto-detected):

Strategy	Runtimes	Mechanism
wrapper + kill	Node.js, Python, Ruby, Perl, Lua, Julia, R, Elixir, Deno, Bun	Patch deployment, sync files, kill child to respawn
signal reload	uvicorn, gunicorn, Puma, Unicorn, Nginx, Apache	SIGHUP for zero-downtime reload
auto-reload	PHP, nodemon	Sync files, runtime re-reads automatically
local build + sync	Go, Rust, Java, Kotlin, C#/.NET, C/C++, Zig	Cross-compile locally, sync binary, restart

Flags:

Flag	Short	Default	Description
`--deployment`	`-d`	— (required)	Target deployment name
`--src`		`.`	Local source directory
`--dest`		`/app`	Destination inside container
`--namespace`	`-n`	`default`	Kubernetes namespace
`--restart`		`false`	Restart app after each sync
`--once`		`false`	Sync once and exit
`--container`		—	Container name (multi-container pods)
`--exclude`		—	Additional exclude patterns
`--debounce`		`500ms`	Debounce interval
`--language`		auto	Override runtime detection
`--build-cmd`		auto	Local build command for compiled languages
`--build-output`		auto	Path to built artifact

Examples:

kindling sync -d my-api --restart
kindling sync -d my-api --restart --once
kindling sync -d orders --src ./services/orders --restart
kindling sync -d gateway --restart --language go
kindling sync -d frontend --src ./dist --dest /usr/share/nginx/html --restart

`kindling debug`

Synopsis: kindling debug -d <deployment> [flags]

Attach a VS Code debugger to a running deployment. Auto-detects runtime, injects debug agent, port-forwards, and writes launch.json.

Flags:

Flag	Short	Default	Description
`--deployment`	`-d`	— (required)	Deployment name
`--stop`		`false`	Stop an active debug session
`--namespace`	`-n`	`default`	Kubernetes namespace
`--port`		auto	Override local debug port
`--no-launch`		`false`	Skip writing launch.json

Supported runtimes:

Runtime	Debug tool	Default port
Python	debugpy	5678
Node.js	V8 Inspector	9229
Deno	V8 Inspector	9229
Bun	Bun Inspector	6499
Go	Delve	2345
Ruby	rdbg	12345

Examples:

kindling debug -d my-api          # start debugging, then F5 in VS Code
kindling debug --stop -d my-api   # stop and restore original deployment

See Debugging for language-specific details.

`kindling dev`

Synopsis: kindling dev -d <deployment> [flags]

Run a frontend dev server locally with full access to cluster APIs. For frontend deployments (nginx, caddy, httpd) where you want local hot reload instead of build+sync.

Steps: detect frontend → resolve source dir → port-forward backend APIs → detect OAuth/start tunnel → patch Vite/Next.js config → launch dev server.

Flags:

Flag	Short	Default	Description
`--deployment`	`-d`	— (required)	Frontend deployment name
`--namespace`	`-n`	`default`	Kubernetes namespace
`--stop`		`false`	Stop the dev session

Examples:

kindling dev -d my-frontend       # start dev mode
kindling dev --stop -d my-frontend  # stop

See Dev Mode for full documentation.

`kindling load`

Synopsis: kindling load -s <service> --context <path>

Build and load a container image directly into Kind (without CI).

`kindling dashboard`

Synopsis: kindling dashboard [--port 9090]

Launch the kindling web dashboard. Provides visual management for environments, sync, load, pods, logs, secrets, env vars, scaling, and tunnels.

Dashboard sections:

Section	Capabilities
Setup	App Designer, Analyze & Generate, Runners
Develop	Environments, API Explorer, Cluster Resources
Staging	Overview, Deploy, Workloads, Network, TLS, Metrics

`kindling expose`

Synopsis: kindling expose [flags]

Create a public HTTPS tunnel to the cluster's ingress controller.

Provider	Account required
cloudflared	No (free quick tunnels)
ngrok	Yes (free tier available)

Flags:

Flag	Default	Description
`--tunnel`	auto-detect	`cloudflared` or `ngrok`
`--port`	`80`	Local port to expose
`--stop`	`false`	Stop tunnel and restore ingress
`--service`	—	Specific ingress to route to

`kindling env`

Synopsis: kindling env <subcommand> <deployment> [args]

Manage environment variables on running deployments.

Subcommand	Synopsis	Description
`set`	`kindling env set <deploy> KEY=VALUE [...]`	Set environment variables
`list`	`kindling env list <deploy>`	List environment variables
`unset`	`kindling env unset <deploy> KEY [...]`	Remove environment variables

`kindling secrets`

Synopsis: kindling secrets <subcommand>

Manage external credentials as Kubernetes Secrets with local backup.

Subcommand	Synopsis	Description
`set`	`kindling secrets set <name> <value>`	Create/update Secret + local backup
`list`	`kindling secrets list`	List all kindling-managed secrets
`delete`	`kindling secrets delete <name>`	Remove from cluster and backup
`restore`	`kindling secrets restore`	Re-create secrets from backup after cluster rebuild

`kindling ingress`

Synopsis: kindling ingress <subcommand>

Manage extra path -> service routes on a DevStagingEnvironment's managed Ingress (spec.ingress.routes) — additional paths merged onto the same host/Ingress alongside the DSE's primary route. Useful for a frontend that calls several backend services via same-origin path prefixes (/orgs, /auth, /billing, ...) under one shared host.

Subcommand	Synopsis	Description
`list`	`kindling ingress list <dse>`	Show the primary route + all extra routes
`add-route`	`kindling ingress add-route <dse> --path P --service S --port N`	Patch a route onto the live Ingress
`remove-route`	`kindling ingress remove-route <dse> --path P`	Remove a route from the live Ingress
`save`	`kindling ingress save <dse> -f <file>`	Write the live extra routes into a DSE YAML file

Workflow: patch a route with add-route, confirm it works, then run save to persist the same routes into the DSE's YAML file so they're applied on every future deploy — not just this session's live patch.

kindling ingress add-route jeff-vincent-gateway --path /orders --service jeff-vincent-orders --port 5000
kindling ingress list jeff-vincent-gateway
kindling ingress save jeff-vincent-gateway -f dev-environment.yaml

`kindling deps`

Synopsis: kindling deps <subcommand>

Manage shared dependency instances (spec.dependencies[].shared) — see Shared dependencies. Shared instances aren't owned by any single DSE and aren't deleted automatically once unused, so use these to find and clean them up.

Subcommand	Synopsis	Description
`list-shared`	`kindling deps list-shared`	List shared dependency instances and which DSEs reference them
`prune-shared`	`kindling deps prune-shared`	Delete shared instances no DSE references anymore

kindling deps list-shared
kindling deps prune-shared

`kindling status`

Synopsis: kindling status

Show cluster, operator, runner, and environment status. Includes crash diagnostics for unhealthy pods.

`kindling logs`

Synopsis: kindling logs [flags]

Tail the kindling controller logs.

Flags:

Flag	Short	Default	Description
`--all`		`false`	All containers in the pod
`--since`		`5m`	Duration (e.g. `5m`, `1h`)
`--follow`	`-f`	`true`	Follow output

Staging

`kindling snapshot`

Synopsis: kindling snapshot [flags]

Export a Helm chart or Kustomize overlay from the current cluster state, optionally push images to a container registry, and deploy to a staging cluster.

Steps: read all DSEs → strip actor prefix from names → generate chart with values.yaml (clean defaults) + values-live.yaml (dev values) → optionally push images via crane copy → optionally helm install on staging cluster.

With --deploy, unless --name/--namespace are set explicitly, both are derived from the current git branch (or --branch) via a stable slug — so concurrent branches deployed to the same shared staging cluster (e.g. multiple open PRs) never collide. Any DSE with Ingress enabled but no host set gets a branch-derived host too, via --staging-domain (result: <branch-slug>.staging.<domain>) — an explicit spec.ingress.host always wins over the derived one, and --deploy fails fast if neither is available rather than producing an unreachable environment.

Unless --tag is set explicitly, --registry pushes (with or without --deploy) auto-detect the next sequential <branch-slug>-N tag for the current branch, so concurrent branches pushing to the same shared registry get their own tag sequence instead of colliding on a single snapshot-N one.

With --render-prod-values (requires --registry in the same invocation), an additional values-prod.yaml is written alongside the chart: the same clean-defaults values every service already gets (TODO placeholders for anything credential-shaped, dependency connection strings included), except each service's image is pinned to the exact digest just pushed (registry/name@sha256:..., never a mutable tag) and KINDLING_ENV_PREFIX (default prod-, override with --prod-env-prefix) is added to every service's env. Kindling never generates, resolves, or stores an actual credential value here — the chart's Deployment template already wires every secret-backed env var to a secretKeyRef against a chart-managed Secret, identically for staging and production since both deploy the same chart; filling in the real value is a manual step (or whatever process your team already uses), by design, not something --render-prod-values does.

Combine --render-prod-values with --deploy in one call for the typical CI shape (a GH Actions job on pull_request): the production values are only written after the staging deploy actually succeeds, so a failed staging deploy never produces a values-prod.yaml — a later workflow step can use the file's mere existence as a pass/fail signal, then diff it against environments/production/values.yaml to flag whatever secrets the new build now needs before anyone merges.

Credential resolution (--deploy) is a single, unified pass, resolved once per distinct credential — never once per service, and never twice for the same one. In order: --creds-config (a committed YAML file mapping credential env var names to where their staging value actually lives — almost always fromEnv: SOME_ENV_VAR, a reference to an environment variable a CI job already populated from a GH Actions secret, never a literal value; plain non-secret values may use value: ... directly) always wins; anything the config file doesn't cover falls back automatically to the corresponding dev-cluster value, with no prompt — this is what makes every dev credential carry over to staging by default; a credential with no value anywhere (not in the config, and the dev-cluster value is itself empty) never fails the deploy — it's warned about immediately and, once the deploy succeeds, listed in MISSING_CREDENTIALS.md in the output directory for a later workflow step to check for and act on.

--non-interactive (also auto-enabled whenever stdin isn't a TTY, e.g. any GH Actions runner) makes the whole command safe to run unattended: no huh form is ever shown, for credentials, registry auth, or Ingress selection. Registry auth comes from --registry-username/KINDLING_REGISTRY_USERNAME and the KINDLING_REGISTRY_PASSWORD env var — deliberately no --registry-password flag, since a password passed as a plain CLI argument would be visible via ps/shell history. --ingress-services (a comma-separated service list, or an explicitly-empty string to disable Ingress for all) replaces the interactive multi-select; when omitted in non-interactive mode, it defaults to whatever was already enabled in the dev cluster.

Flags:

Flag	Short	Default	Description
`--format`	`-f`	`helm`	`helm` or `kustomize`
`--output`	`-o`	`./kindling-snapshot`	Output directory
`--name`	`-n`	`kindling-snapshot` (or branch slug with `--deploy`)	Chart/project name
`--registry`	`-r`	—	Container registry (e.g. `ghcr.io/myorg`)
`--tag`	`-t`	next sequential `<branch-slug>-N` (or `snapshot-N` outside a git branch context)	Image tag
`--deploy`		`false`	Deploy after generating chart
`--context`		—	Kubeconfig context for staging cluster
`--namespace`		`default` (or branch slug with `--deploy`)	Namespace to deploy into
`--branch`		current git branch	Git branch to derive the staging name/namespace/Ingress host/image tag from (used with `--deploy` or `--registry`)
`--staging-domain`		—	Base domain for branch-derived Ingress hosts — result is `<branch-slug>.staging.<domain>`, e.g. `subnode1.xyz` (required for `--deploy` if the DSE doesn't already set an Ingress host)
`--render-prod-values`		`false`	Write a `values-prod.yaml` with the promoted image digest pinned in, alongside the chart (requires `--registry`)
`--prod-env-prefix`		`prod-`	`KINDLING_ENV_PREFIX` value injected into every service's env when using `--render-prod-values`
`--creds-config`		—	Path to a YAML file mapping credential env vars to staging values (`fromEnv`/`value`) — safe to commit, no literal secrets when using `fromEnv`
`--non-interactive`		`false`	Never prompt (fail fast instead if a required value can't be resolved from flags/env/config) — for CI; auto-enabled when stdin isn't a TTY
`--registry-username`		—	Registry username (falls back to `KINDLING_REGISTRY_USERNAME`; password must come from `KINDLING_REGISTRY_PASSWORD` or an interactive prompt, never a flag)
`--ingress-services`		—	Comma-separated list of services to enable public Ingress for (pass an empty string to disable Ingress for all) — skips the interactive prompt when set

Examples:

# Generate only
kindling snapshot                          # Helm chart in ./kindling-snapshot/
kindling snapshot --format kustomize       # Kustomize overlay
kindling snapshot -o ./my-chart            # custom output directory

# Push images + deploy to staging
kindling snapshot -r ghcr.io/myorg --deploy --context do-staging
kindling snapshot -r ghcr.io/myorg -t v1.2.0 --deploy --context do-staging --namespace staging

# PR branch → its own name/namespace-scoped staging environment
# (feature/checkout-retry -> name/namespace "feature-checkout-retry")
kindling snapshot -r ghcr.io/myorg --deploy --context do-staging

# ...with a branch-derived, resolvable Ingress host too
# (-> feature-checkout-retry.staging.example.com)
kindling snapshot -r ghcr.io/myorg --deploy --context do-staging --staging-domain example.com

# Push images and also write values-prod.yaml, pinned to the pushed digest
# (no deploy — kindling never touches a production cluster or credential)
kindling snapshot -r ghcr.io/myorg --render-prod-values

# Typical CI shape: deploy to staging, then (only if that succeeded)
# write values-prod.yaml for a later workflow step to diff/review
kindling snapshot -r ghcr.io/myorg --deploy --context do-staging --render-prod-values

# Fully unattended, from a GH Actions job (KINDLING_REGISTRY_USERNAME/
# KINDLING_REGISTRY_PASSWORD populated from ${{ secrets.* }}) -- no prompt
# is ever shown, for credentials, registry auth, or Ingress selection
kindling snapshot -r ghcr.io/myorg --deploy --context do-staging \
  --non-interactive --creds-config deploy/staging-credentials.yaml \
  --ingress-services frontend,api

Manual usage:

helm template my-app ./kindling-snapshot -f values-live.yaml
helm install my-app ./kindling-snapshot \
  --set gateway.env.DATABASE_URL=postgres://staging-host:5432/mydb

`kindling staging tls`

Synopsis: kindling staging tls [flags]

Configure TLS with cert-manager for staging Ingress resources. Installs cert-manager, creates a Let's Encrypt ClusterIssuer, and optionally patches a DSE YAML to enable TLS.

Flags:

Flag	Short	Default	Description
`--context`		— (required)	Kubeconfig context for staging cluster
`--domain`		— (required)	Domain for TLS certificate
`--email`		— (required)	Email for Let's Encrypt registration
`--issuer`		`letsencrypt-prod`	ClusterIssuer name
`--staging`		`false`	Use Let's Encrypt staging server
`--file`	`-f`	—	DSE YAML to patch with TLS config
`--ingress-class`		`traefik`	IngressClass for ACME solver

Examples:

kindling staging tls --context my-staging --domain app.example.com --email admin@example.com
kindling staging tls --context my-staging --domain app.example.com --staging
kindling staging tls --context my-staging --domain app.example.com -f dev-environment.yaml

Lifecycle

`kindling reset`

Synopsis: kindling reset [-y]

Remove the runner pool to point at a new repo. Leaves the cluster intact.

`kindling destroy`

Synopsis: kindling destroy [-y]

Delete the Kind cluster and all resources.

`kindling version`

Synopsis: kindling version

Print the CLI version.

Dependency Auto-Injection

When a dependency is declared in spec.dependencies[], the operator auto-injects the connection URL:

Dependency	Injected env var
postgres	`DATABASE_URL`
redis	`REDIS_URL`
mysql	`DATABASE_URL`
mongodb	`MONGO_URL`
rabbitmq	`AMQP_URL`
minio	`S3_ENDPOINT`
elasticsearch	`ELASTICSEARCH_URL`
kafka	`KAFKA_BROKER_URL`
nats	`NATS_URL`
memcached	`MEMCACHED_URL`
cassandra	`CASSANDRA_URL`
consul	`CONSUL_URL`
vault	`VAULT_ADDR`
influxdb	`INFLUXDB_URL`
jaeger	`JAEGER_URL`

Do not duplicate these in spec.env[] — they are injected automatically.

Typical Workflow

# ── SETUP ────────────────────────────────────────
kindling init
kindling runners -u alice -r acme/myapp -t ghp_xxxxx
kindling analyze
kindling generate -k sk-... -r .
kindling secrets set STRIPE_KEY sk_live_...

# ── DEVELOP ──────────────────────────────────────
git push origin main                    # outer loop: build + deploy
kindling status                         # verify deployment
kindling sync -d alice-myapp --restart  # inner loop: live sync
kindling debug -d alice-myapp           # attach debugger
kindling dev -d alice-frontend          # frontend hot reload
kindling dashboard                      # visual control plane
kindling env set alice-myapp LOG_LEVEL=debug
kindling push -s alice-myapp            # rebuild one service
kindling expose                         # public URL for OAuth

# ── PRODUCTION ───────────────────────────────────
kindling snapshot -r ghcr.io/myorg --deploy --context my-staging
kindling staging tls --context my-staging --domain app.example.com --email admin@example.com

# ── LIFECYCLE ────────────────────────────────────
kindling reset                          # switch repos
kindling destroy -y                     # tear down

Command Index​

Installation​

Global Flags​

Setup​

kindling init​

kindling runners​

kindling explain​

kindling analyze​

kindling generate​

Develop​

kindling deploy​

kindling push​

kindling sync​

kindling debug​

kindling dev​

kindling load​

kindling dashboard​

kindling expose​

kindling env​

kindling secrets​

kindling ingress​

kindling deps​

kindling status​

kindling logs​

Staging​

kindling snapshot​

kindling staging tls​

Lifecycle​

kindling reset​

kindling destroy​

kindling version​

Dependency Auto-Injection​

Typical Workflow​

Command Index

Installation

Global Flags

Setup

`kindling init`

`kindling runners`

`kindling explain`

`kindling analyze`

`kindling generate`

Develop

`kindling deploy`

`kindling push`

`kindling sync`

`kindling debug`

`kindling dev`

`kindling load`

`kindling dashboard`

`kindling expose`

`kindling env`

`kindling secrets`

`kindling ingress`

`kindling deps`

`kindling status`

`kindling logs`

Staging

`kindling snapshot`

`kindling staging tls`

Lifecycle

`kindling reset`

`kindling destroy`

`kindling version`

Dependency Auto-Injection

Typical Workflow