Support multiple remote Herdr servers

[icedac]

Current behavior

Herdr currently has a 1:1 client/server attach model.

• herdr attaches to one local headless server.
• herdr --remote <target> attaches to one remote headless server.
• For users working across two or more local/remote Herdr or tmux-backed servers, the practical workaround is still separate windows or nested Herdr/tmux sessions.

That nesting technically works, but even two layers create friction: shortcuts become ambiguous, mouse UI actions can go to the wrong layer or stop working reliably, and host-terminal features such as image paste do not behave consistently.

Requested change

It would be genuinely useful if a user could add remote Herdr headless servers once, then use several servers from one Herdr sidebar almost as if they were one server.

Desired user experience:

• launch herdr locally or herdr --remote <target>;
• treat the launched server as the main server;
• use menu -> add remote to add another remote host or localhost;
• show local and remote workspaces/agents together in the sidebar;
• click a workspace or agent to switch to that server;
• cycle the spaces header through all -> local/main -> remote...;
• when creating a workspace from all, ask which server should receive it.

The server boundary should be visible only as lightweight labels such as local, x, or x herdr, not as another nested terminal app.

Reason

Many tmux users work locally while also managing several remote development or service hosts. Today that means the user has to remember which server owns which workspace, which nested UI currently has focus, and where a new shell or agent will be created.

This feature would trade internal Herdr complexity for a simpler user workflow: one client, one sidebar, clear server labels, and predictable workspace/agent routing.

Product impact

Yes, this changes UI and workflow expectations. It adds an add remote flow and makes the sidebar a multi-server navigation surface.

Non-goals:

• do not merge panes, PTYs, processes, or runtime state across machines;
• do not move workspaces between servers;
• do not require nested Herdr UIs for the multi-server workflow;
• do not make this a general SSH session manager.

Implementation notes draft

This is only a possible direction, not the requested user-facing contract.

• Keep the launched server as the main server.
• Persist only a lightweight remote registry on the main server.
• Keep actual secondary server connections client-owned.
• Refactor sidebar ownership so the thin client can render a unified sidebar from server/workspace/agent summary data.
• Reuse the existing remote attach/SSH bridge where possible for secondary connections.

[ogulcancelik]

i know this is much wanted and i appreciate your help offer, but this is a big change i want to tackle myself for now, after some api stuff. ty tho!

[icedac]

@ogulcancelik

I know you probably don't want me to do this because it's such a large refactor, but I built a PoC to reduce my own cognitive load right now, and it works well. Take a look when you have time. Changing 1:1 to 1:many requires a lot — a lot — of changes.

Remote server rendering should be refactoring like udp-style.

telegram-cloud-document-5-6114140371128688345.mp4

CleanShot.2026-05-31.at.00.14.28.mp4

2lab-ai#8

[roderik]

I was looking for the same, ended up with named workspaces in cmux

[icedac]

@roderik Cmux named workspaces + Herdr will help, but that's exactly the workaround I'm trying to get away from. A "space" in Herdr is just a label you carry in your head — you still have to remember which space lives on which server. That mental mapping is the real cognitive-load cost.

The core issue for me is reducing cognitive load: locating a space is a two-level indirection (which server → which space), and removing that is what I'm after. Everything else is a bonus.

That's what this PoC targets.

And one thing I found along the way: once the left sidebar moves from server-side to client-side rendering, it opens the door to a much more responsive TUI — richer interactions with immediate feedback (e.g. hovering a space to show a preview), and features that are awkward or impractical to do with server-side rendering.

Ultimately, the kind of modern tmux replacement I want is to push this far enough that — like tmux + mosh keeping you always attached — local and remote stop being a distinction you have to think about at all, so you just work off the space name with zero cognitive overhead.

[ogulcancelik]

@icedac thanks for sharing the poc of yours. i agree on your idea and concept, after i finish current refactors for agent detection and some more stuff, this the next feature i wanna work on.

however i'm still investigating the best kiss and intuitive ux here. multiple remote vs local sessions can have different approaches, using side bar is one of them, but again i didn't decide on one yet. if i decide on making sidebar spaces the joined solution i may ask for a pr.

[chrisg32]

I came here to propose exactly this feature. Finally a way to integrate my personal and work workspaces seamlessly. That you @ogulcancelik for all the work on herdr. It is awesome.

[LWooler]

+1 for this feature. also a new convert to herdr. Nice job, thanks!

[drod3763]

Nested herdr sessions are a pain. I would like to make a second tab or space a herdr session.

[cleverdevil]

Came to write this feature request and was happy to discover that it’s already in motion. I personally find @icedac’s (lovely) PoC to be an ideal UX.

It would be nice if I could launch a multi-remote instance of herdr on one machine via the CLI by passing multiple remotes:

herdr --remote ssh://one --remote ssh://two

Thanks for your incredible work on herdr, @ogulcancelik. Taking a thoughtful approach to this feature is wise. Look forward to seeing where this lands!

[cleverdevil]

Side note — my first instinct was to see if this could be implemented as a plugin, but my research indicated that it would not be possible without changes to the core of herdr. It may be an interesting approach to extend the plugin API to allow for this feature to be implemented as a separate plugin, leaving some of the UX decisions to the plugin. Just a thought!

[icedac]

You can try the multi-remote support on my preview build:

brew install 2lab-ai/tap/herdr-mx-preview

I've been running 3–4 remotes at once on it for over two weeks now, and it's held up well in daily use.

(The -mx / separate tap is just so I can ship a throwaway preview without stepping on the main release — not a fork I'm maintaining. Heads up though: this build is synced up on 6.10, and upstream has since moved to 0.7.1 with a big plugin update, so you'll likely hit conflicts)

[mapa17]

+1 from me, this would be a great feature for my use case.

[nicwhites]

+1 from me as well, this would be fantastic for being able to have all agent harnesses installed locally, but be able to attach to long lived sessions on remote machines. Would also be nice to be able to inject some sort of context at agent launch.

BACKGROUND: my team deploys HPC systems and we are constantly switching to new systems. With that, we are leveraging AI for deploying and running commands on remote systems. We are ok with installing herdr on the remote admins for having long lived shell sessions, but we don't wanna go through the process of installing any harnesses like opencode as well as not wanting to have a single config for users. Sure we could do env sourcing and more, but that just adds more overhead. Instead it would be nice for each user to use their harness on their local machine and then inject some context into the harness to tell the harness which node to ssh into to run remote commands. Right now I am using tmux and sending in keys into managed panes which works, but could be better and I like the features herdr adds in terms of agent management, but with the current implementation, its not quite a replacement for tmux for us.

I really appreciate all the work and look forward to see what y'all come up with!

[chaoxu]

This feature would be a game changer. I mean even if we are not using these for agents at all, having a universal access to a lot of persistent sessions across a fleet is amazing.

[johnuopini]

+1 on this, it's the main thing I'm missing, local + remote is my daily situation, there is a duplicate of this here #1101

[johnuopini]

@icedac i see your fork is stale on 6.x, are you planning to open a PR for your great work or you are fine if someone else cherry picks your changes and try to open one instead? or maybe @ogulcancelik is already working on this?

[ogulcancelik]

update on the multi-client feature:

first of all, thanks, everyone, for the interest. this is the top priority at the moment, but it requires a robust architecture. it can be implemented in multiple ways, and i appreciate @icedac for the fork. however, i’m currently working on herdr’s backend server-client architecture, which i want this feature to be built on top of. so please bear with me a little longer :)

[kjarnot-uips]

Many thanks, @ogulcancelik! As stated above, this would be a game changer, and would simplify the daily workflows of many of us. Looking forward to seeing what you come up with.

[tahaalibra]

While it's been worked on, you can use my branch, it works with remote servers.

https://github.com/tahaalibra/herdr/tree/feat/multi-remote or check release at https://github.com/tahaalibra/herdr/releases

[heeen]

subscribed, echoing that I'd like this feature.

[rossirpaulo]

I’m also looking for this workflow and wanted to add another concrete use case.

I regularly have workspaces that should remain local, while other projects and agents run on a remote development machine. I would like to launch Herdr locally and see both kinds of workspaces in the same Herdr's ui

The important distinction from the existing herdr --remote <target> behavior is that I do not want to replace the local session with a remote session. I want the local Herdr client to connect to both and present them as one workspace-navigation surface.

I'm happy to build it myself or help in some way! How can I be added to the contributors' list?

Cheers!

[qiuchuy]

My daily work relies heavily on deploying and managing multiple agents across remote servers and containers via SSH. Herdr would be a perfect fit after this feature is implemented.

[chwzr]

would love to have multiple spaces from multiple remotes in one view on my local herdr too - this would unify all my work across all machines i'm on. ux wise, i think just select a remote when creating a new space would be the simplest and most intuitive

[wjdwndud0114]

+1 working with multiple remote containers and this would be better than a cmux setup

[issei-m]

+1, the feature is exactly what I'm looking for, would love to have it!

[13lbise]

I guess I'll add my +1 to the pile ;) I'm working on several ssh machines and also locally having everything in the same instance would be awesome