context add

noetl context add

Create a new context from CLI flags.

noetl context add <name> --server-url=<url> [flags]

Use this when you already know every field you want to set. For a guided bootstrap from a gateway URL, prefer noetl context init --from-gateway.

Required arguments

Flag	Description
<name>	Context name. Must be unique.
--server-url=<url>	HTTP base URL the CLI will call. Gateway URL for the gateway path; loopback URL for port-forward; dev server URL for direct.

Optional arguments

Flag	Default	Description
--runtime=<mode>	auto	Default runtime: local, distributed, or auto.
--auth0-domain=<domain>	—	Auth0 tenant domain (e.g. acme.us.auth0.com).
--auth0-client-id=<id>	—	Auth0 application client_id.
--auth0-redirect-uri=<url>	—	Auth0 callback URL the SPA registers (the CLI prints this in PKCE pre-flight).
--auth0-audience=<aud>	—	Optional API audience.
--auth0-client-secret=<secret>	—	Optional Auth0 client_secret for password grant.
--kube-context=<name>	—	Kubernetes context name for noetl context port-forward.
--kube-namespace=<ns>	—	Namespace the in-cluster noetl service lives in.
--kube-service=<name>	noetl	Service name.
--kube-remote-port=<port>	8082	In-cluster service port.
--set-current	off	Switch to the new context after creating it.

Examples

# Local dev server
noetl context add local --server-url=http://localhost:8082 --runtime=local

# Gateway with Auth0
noetl context add prod \
  --server-url=https://gateway.example.com \
  --auth0-domain=acme.us.auth0.com \
  --auth0-client-id=Abc123XYZ \
  --auth0-redirect-uri=https://app.example.com/login \
  --auth0-audience=https://api.example.com \
  --runtime=distributed \
  --set-current

# Port-forward target — server_url is the loopback the local tunnel binds to
noetl context add gke-pf \
  --server-url=http://127.0.0.1:18082 \
  --runtime=distributed \
  --kube-context=gke_acme_us-central1_prod \
  --kube-namespace=noetl \
  --kube-service=noetl \
  --kube-remote-port=8082

Notes

• The CLI does not validate --server-url reachability at write time. Connect later with noetl auth login or noetl --context <name> catalog list Playbook to confirm.
• For Auth0, the gateway validates tokens per-request against the auth0_domain carried in the login payload. The fields on the context are passed verbatim to the gateway; they only need to match the Auth0 application the gateway expects.
• If you'd rather have the gateway hand back its expected Auth0 configuration so you don't have to type it, use noetl context init --from-gateway.

See also

• noetl context init --from-gateway — discover Auth0 fields from the gateway runtime contract.
• noetl context update — patch fields in place after creation.
• noetl context port-forward — uses the kube_* fields written here.