Story

Hey HN,

I built ctx because I was tired of the mental overhead of managing multiple client environments. Every context switch meant: change AWS profile, switch kubeconfig, start the right SSH tunnels, set the right env vars, remember which VPN i need to connect to. Miss one step and you're deploying to the wrong environment.

The problem: Existing tools are siloed. kubectx handles Kubernetes. aws-vault handles AWS. direnv needs .envrc files everywhere. SSH tunnel managers don't know about your cloud context. Nothing ties them together.

ctx does one thing: Atomic context switches across all of these at once.

ctx use client-a-prod

# Now your shell has:

# - AWS_PROFILE=client-a-prod

# - KUBECONFIG pointing to their cluster

# - Nomad/Consul env vars set

# - SSH tunnels to their bastion started

# - VPN connected

# - Secrets loaded in env

Key features:

- Single YAML per context defines everything

- CLoud SSO integration - detects expired sessions, triggers login automatically, caches tokens so switching back is instant

- Browser profiles - ctx open grafana opens Chrome/Firefox with the right profile (useful when each client has different SSO/Google accounts)

- SSH tunnels auto-start on context switch, auto-reconnect on failure

- Production safety: color-coded prompts, confirmation required for prod contexts

- Per-terminal isolation - different terminals can be in different contexts simultaneously

- Shell integration for bash/zsh/fish

Written in Go, single binary, no dependencies.

GitHub: [https://github.com/vlebo/ctx/]

I'd love feedback on the design. The config format took a few iterations to get right - balancing simplicity with flexibility for complex setups.