rune login / context

The CLI keeps named contexts in ~/.rune/config.yaml. Each context is a (server, token, namespace, tls) tuple. Switch between them with rune use-context.

`rune login`

Shortcut for “create or update a context, optionally make it the current one.”

rune login dev \
  --server localhost:7863 \
  --token-file ~/.rune/dev.token \
  --default-namespace default

If you omit <context-name>, it defaults to default.

Flag	Notes
`--server`	gRPC address (`host:port`).
`--token`	Inline token value.
`--token-file`	Path to a file containing the token.
`--token-stdin`	Read the token from stdin. Designed for CI — see below.
`--default-namespace`	Default namespace for this context (used when commands omit `--namespace`).
`--no-verify`	Skip server verification — just set the context.
`--set-current`	Make this the active context (default: yes).

rune login verifies the server is reachable and the token works (unless --no-verify).

The legacy --namespace flag on rune login is a deprecated alias for --default-namespace; it still works for one release but emits a warning. The rename disambiguates it from the per-operation --namespace flag used everywhere else (cast, get, delete).

`--token-stdin` for CI

For automation (GitHub Actions, GitLab CI, etc.) prefer piping the token over stdin so it never lands on the process argv — invisible to /proc, ps, shell history, or naive log capture:

printf '%s' "$RUNE_TOKEN" | rune login ci \
  --server runed.example.com:443 \
  --token-stdin

This is what runestack/rune-cast-action uses internally. See the CI deployments guide.

About the `rune_` token prefix

All bearer tokens issued from v0.0.1-dev.25 onward look like rune_<uuid>.<uuid>. The prefix is mandatory — tokens without it are rejected by the server. It exists so secret scanners (Gitleaks, GitHub secret scanning, TruffleHog) can match Rune tokens by a stable distinctive marker, the same way ghp_ or glpat- work.

`rune context`

Sub-commands:

rune context view                      # show current config
rune context list             # list all
rune context use <name>        # switch active context
rune context set <name> [...]  # create or update a context
rune context delete <name>     # remove

`context set`

rune context set prod \
  --server runed.example.com:7863 \
  --token-file /etc/rune/prod.token \
  --namespace prod \
  --tls-ca /etc/rune/ca.crt \
  --tls-cert /etc/rune/client.crt \
  --tls-key /etc/rune/client.key

Update one field on an existing context:

rune context set dev --namespace=staging

Aliases

rune use-context is a top-level alias for rune context use:

rune use-context prod

Config file layout

~/.rune/config.yaml:

current-context: dev
contexts:
  dev:
    server: localhost:7863
    namespace: default
    token: <bearer>
  prod:
    server: runed.example.com:7863
    namespace: prod
    token-file: /etc/rune/prod.token
    tls:
      ca: /etc/rune/ca.crt
      cert: /etc/rune/client.crt
      key: /etc/rune/client.key

The file is created with mode 0600.

Tips

Prefer token-file over inline token for shared machines.
Use one context per environment, not one per cluster — same context, different namespace works fine for many “envs” inside a single Rune.
rune whoami will tell you which context you’re in and whether the token works.

rune login / context

rune login

--token-stdin for CI

About the rune_ token prefix

rune context

context set