| 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. |