sbsh provides persistent terminal sessions with built-in discovery, environment profiles, and an API for automation.
*The problem:*
- Complex configuration required to access multiple Kubernetes clusters and Terraform workspaces, including setting visual prompts to identify production environments and avoid mistakes
- Manual setup of environment variables and credentials for each environment
- No easy, shareable way to reproduce those configurations across a team
- Lack of structured logs or visibility into existing sessions
- SSH sessions that die in the middle of debugging or long tasks
*How it works:*
sbsh separates the terminal session (your shell and environment) from the supervisor (the controller). Terminals continue running even if the supervisor stops or the network connection drops.
*Key features:*
- Terminal session discovery: sb get lists all sessions, sb attach mysession reconnects instantly
- Profiles: YAML-defined environments for Kubernetes contexts, Terraform workspaces, or Docker containers, identical in local dev and CI/CD
- Multi-attach: Several users can connect to the same live session
- API access: Control and automate sessions programmatically
- Structured logs: All input and output are recorded for replay or analysis
*Use cases:*
- DevOps: Persistent kubectl or Terraform sessions
- Developers: Long-running tests and builds over unstable connections; launching Python environments, npm projects, and more
- CI/CD: Identical profiles in local and pipeline environments
sbsh is a single Go binary (busybox-style) that can also be used as a login shell. It runs on Linux, macOS, and FreeBSD.
Repository: github.com/eminwux/sbsh
I have been using it for some time now, and it completely changed how I manage infrastructure. I would love to hear feedback and see how others might use it.
eminwux•3mo ago
sbsh does not multiplex a single terminal session like those tools. Instead, it runs a persistent supervisor that manages multiple terminal sessions (PTYs) as independent processes. Each session can continue running even if the supervisor exits, and you can attach to it later from any machine that has access.
The main motivation was having YAML-defined profiles that set up environment variables, prompts, and startup commands for kubectl, terraform, or any other tool. This makes it easy to share consistent environments across a team without relying on ad-hoc Bash scripts.
chickensong•3mo ago
Why not just use something like Ansible if you mainly want YAML config management? It handles multiple environments elegantly and isn't constrained to any particular use case.
Not trying to knock your tool; building stuff is cool, and little custom programs are great for internal use, but it's a harder sell to convince the general public to move away from more generic and battle-tested tools. My feedback here, is that I'm still not sure why I'd choose sbsh.
eminwux•3mo ago
You are absolutely right that screen and tmux use separate PTYs for sessions, and they are both extremely powerful. I actually use screen myself and it was one of the main inspirations for sbsh.
The main difference is that sbsh provides manifests to define terminal sessions declaratively. A manifest can include commands, environment variables, prompts, and lifecycle hooks such as onInit and postAttach. This makes it easy to reproduce and share terminal configurations, for example to run the same process locally or inside a CI/CD pipeline without manual setup.
Unlike screen, sbsh includes session discovery and metadata. It keeps a metadata directory that stores detailed information about all running terminals and supervisors, including their profiles and states. This allows you to query or reattach programmatically through the API.
Regarding configuration management, I agree that Ansible is great for provisioning and automation, but my goal with sbsh was different. I wanted a lightweight tool to set up working environments for Terraform, Kubernetes, Python venvs, and similar workflows.
For large Terraform projects with many environment variables, keeping local runs consistent can be difficult. sbsh profiles help with that by defining everything once and setting up a clear prompt to avoid running commands in the wrong environment. The same applies to Kubernetes clusters with multiple environments and namespaces.
You can also share these manifests with teammates so that when they start a terminal session, the environment is configured exactly the same way, with the right variables, cluster context, and visual prompt. This ensures consistency and prevents human error across local and CI/CD environments.
In short, sbsh focuses on developer session reproducibility rather than system configuration. It fills the gap between shell setup, automation, and environment safety.
Thanks again for the feedback. I completely agree that adopting new tools is always a challenge, but I built this to solve my own workflow pain, and it has made a big difference for me.
chickensong•3mo ago