One friend asked me how it differs from tmux or screen, so here are my thoughts.
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.
Tmux/screen can also use separate PTY for named sessions, not just multiplex a single session. A separate process is used as well.
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.
Thanks a lot for the thoughtful comment, I really appreciate it.
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.
Thanks for the additional details. I can see how a more lightweight dev tool could be helpful in many situations, and leveraging the API sounds interesting. Anything improving workflow pain is a big win. Thank you for sharing!
One friend asked me how it differs from tmux or screen, so here are my thoughts.
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.
Tmux/screen can also use separate PTY for named sessions, not just multiplex a single session. A separate process is used as well.
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.
Thanks a lot for the thoughtful comment, I really appreciate it.
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.
Thanks for the additional details. I can see how a more lightweight dev tool could be helpful in many situations, and leveraging the API sounds interesting. Anything improving workflow pain is a big win. Thank you for sharing!