Ctx

Details

External ID

46737344

Source

HN

Company

—

Product

Ctx

Website domain

github.com

Launched

Jan. 23, 2026

Cohort

—

Upvotes

7

Upvotes percentile

0.3544137022397892

Tags

—

Fetched at

Sept. 7, 2026, 9:25 p.m.

Updated at

Sept. 7, 2026, 9:25 p.m.

Description

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 envKey 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/fishWritten 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.

• Source listing
• Website