Connecting the machines(herdr.dev) |
Connecting the machines(herdr.dev) |
Now they have raised $6M in funding. [1]
Do not be surprised to realize that open source does not pay their bills.
I haven’t tried herdr yet, but maybe it’s just not targeted at me?
The real problem I have with the remote codex setup is when it needs to authenticate as me. I sort of solved this for sudo and ssh with this [1], but I think something like this could be integrated deeper into the harness
I had always been curious on why Tailscale hasn't creating agent-oriented features. It's obvious to me that Tailscale is at the best position (AFAIK) to capitalize on agents demand.
Their connectivity product is unique. And it's a natural fit to connecting long-running agents instance across the Internet.
I was thinking the herdr remote features is nice to have in my app, given this herdr multi machine support, perhaps I need to reconsider how I integrate it in the future
There is also netbird, netmaker, zerotier and several others.
My read here isn’t about connecting to remote machines in the sense of ssh, but presenting a unified view across herdr instances running on multiple remote machines.
This stinks of the same enshittification moves Docker made 10 years ago.
What I need is to have a general solution to connect me to my agents running somewhere. The motivation is that any hosted solution deprives me of ownership of my data. And I am planning to share more private data with my agents, that cannot be done to have hosted agents today. (I plan to build a hosted solution myself where users can declarative define their own agents, and completely own their own data without my service save anything, I'll ask users to connect to their own storage solutions like Google doc)
I of course can build everything myself. But I think a tailscale offering could be very convenient.
I am guessing cloud flare should have building blocks of their own, but it's a different layer than tailscale's.
The limitation of Orca or Herdr is that they don't have integration for multi project work. Here is what I wanted
Telegram/OpenClaw → Single Linear Account Control plane with multiple projects → route each task to be completed and PRs open for review across multiple repos.
This is where Cyrus helps. You setup labels and routing so cyrus knows which gitrepo to build worktrees from, and the labels can help you pick up the right model (codex-sol/astro or claude-opus/fable). This has helped me be more hands off.
So I use both Orca and Cyrus. Cyrus for automation (telegram ingress) vs Orca if I want anything hands on.
will turn into absolute dogshit within weeks, use proper software.
Running via ssh is great when your machines are pets that have local state. I don’t find it to be that useful when I have more than two machines that I’m load balancing agent sessions across.
Just for example, a nice feature from the Codex app; if you edit a markdown file on your remote, and click on the link to the edited .md file, it just opens the file in the local app, and you can view the rendered form too. If I’m working on my local machine this isn’t a win vs. opening the file in Obsidian / IDE. But it’s way easier than manually viewing the file over SSH (unless you just want to look at the raw text version). Similar applies to html files.
I think it’s more likely the Fly Sprites or Claude/Codex sandbox model will win as we move to swarms. If I’m not watching the actual harness output, there’s not a great reason to attach a pty.
I get that Herdr wants investors to give them money to own developers' coding sessions, but the value proposition ("Walk away and they keep working. Come back from any machine and they're where you left them.") seems like a miss since it's so easy to do that without them.
I'm surely missing something.
1) are terminal based (not gui apps that you need to install)
2) Can be run by mosh/ssh
3) Track agent sessions automatically
4) Have built-in git worktree management
5) Show agents connections over different machines (the new feature mentioned in the blog post)?
You finally don’t need to do the janky termux ‘Claude —remote-control’ startup dance.
Still not as productive as on desktop, but viable for side project style work.
Oh, right, this is how we monetize in 2026. Nevermind.
is it, though?
I can imagine having a local Herdr instance and one running on a remote box somewhere, but I can't think of a use case where I'm trying to juggle N different Herdr instances and that overhead becomes a meaningful bottleneck.
> Getting to 1.0
> After this update, what I want is to make connecting those machines more convenient. You shouldn’t need to think about SSH or deal with complicated network setup. It should be easy to connect any machine, anywhere, through one Herdr account.
(emphasis added)
sigh. I'm a daily user of Herdr. I don't have a Herdr account today. I don't want a Herdr account. I don't need a Herdr account.
the product is not even to 1.0 yet and already the writing is on the wall for the path towards enshittification & acquisition by $bigco.
of course, I'm sure there will be some "usage without an account will still work" platitudes, but the trend of development is clearly going to be in the direction of features that "integrate" with the "developers using Herdr pay us money and/or we collect their data" business model.
The reason Herdr is novel, IMO, is its runtime owns the PTYs and builds a bidirectional messaging system on top of that. It’s like Pi’s RPC - a very limited version of it - which allows one to hook into agent i/o without needing to invoke “$agentcli -p”. There’s a lot they could build on that, and so I wonder why a managed cloud play was first on their list.
https://herdr.dev/blog/herdr-is-joining-y-combinator/
On the wall ? It's spray painted in big neon letters, and by themselves, lmao. Herdr cannot be trusted.