A real CLI is working great on a local machine but at a certain point you may start to wonder why keep all this tight to my local dev machine. You may be working in a team or you may switch devices often and having to go through all the setup every single time gets t iring pretty fast. Or maybe you just don't want your entire workflow to depend on your local machine. That's where remote workers come in and it's actually how I've been running Ralph Loops over the past few months. I have a dedicated Mac mini in my home

That's where remote workers come in and it's actually how I've been running Ralph Loops over the past few months. I have a dedicated Mac mini in my home office that sits behind me and it also powers my old school cinema display which you can see behind me but you don't need to invest in a dedicated machine. This would also work on a VPS from any provider as long as you can SSH into it. I configured my machine to be accessible when I run SSH Cloudbox and the first way to set up a remote worker is actually super simple.

accessible when I run SSH Cloudbox and the first way to set up a remote worker is actually super simple. You SSH into your remote server, in my case Cloudbox, we make sure Ralph is installed and is on version 0.13. Next, we start a team accession using tmux new -s/aracost_ralph. We see the into our project directory and we run Ralph. Do note that we basically need to set up everything like we did before, Ralph needs to be installed on the remote, we got that covered. We need a

did before, Ralph needs to be installed on the remote, we got that covered. We need a linear environment variable to be available on the remote as well if we intend to use linear. We need to install the YOLO box if you use that and we need the GitHub CLI to be configured and authenticated but more on that in a bit. Now when we detach from this tmux session, Ralph will keep running and because we're in linear mode with polling, this can keep running headless

will keep running and because we're in linear mode with polling, this can keep running headless and it will pick up work from linear. This way linear becomes our control pane which is pretty convenient because we can now dispatch tasks headlessly to Ralph. Linear has a great mobile app so you could even do this from your phone. The disadvantage here is that you'd have to attach to the remote and the tmux session if you want to tail the agent output or kill it for example. We'd have

remote and the tmux session if you want to tail the agent output or kill it for example. We'd have to say tmux attach -t/larchost_ralph and we'll attach to this session again but honestly this is basically how I run it and I personally really don't mind. If you do need that extra level of control or dislike the fact that you'd console you have to SSH and attach to the tmux session, I got you covered as well. Let me kill this session and let's go back to our local machine. I build remote

covered as well. Let me kill this session and let's go back to our local machine. I build remote support in the Ralph CLI. We can configure a remote in a configuration file as follows we can say cat Ralph.ctomo and in here we see a remote section. We can configure our host which in my case is Cloudbox. We'll configure our project directory, our workspace mode which is still copy on rights, the directory for our workspace which is larchosts and we want to have YOLO box

on rights, the directory for our workspace which is larchosts and we want to have YOLO box set to true. Let's edit the configuration and also say that we want to auto create PR. Let's set this to true there we go. Now when we run Ralph locally with the -re-mode Cloudbox flag this allows us to dispatch Ralph loops over SSH onto our Cloudbox. I prepared a small PRD that will get rid of the godawful brown color that has been bothering me for a few lessons now and

will get rid of the godawful brown color that has been bothering me for a few lessons now and instead let's just make it white like a normal webshop. We can dispatch our linear issue by pressing C, enter and now what happens behind the scenes is that Ralph opens an SSH session to the remote and runs Ralph in headless mode inside a tmux session and the logs are then streamed back to our local control pane. Now if we say SSH Cloudbox and we say tmux attach -t Ralph we can

back to our local control pane. Now if we say SSH Cloudbox and we say tmux attach -t Ralph we can see our Ralph worker working. When the Ralph session finishes working it will also kill the tmux session and this way we're actually using tmux as a persistence layer so our local machine knows exactly which agents are still running and which aren't. If we press Q while our loop is running we don't kill the loop instead we simply detach from it and we can attach to it again anytime from any

don't kill the loop instead we simply detach from it and we can attach to it again anytime from any device. This setup might need some tweaking to get it to work properly on your machines but we have the magic of other lamps at our fingertips so if you run into any issues just ask Cloud to fix them for you. Now a thing I've been doing on these remote machines is to authent icate using a dedicated GitHub user not using my own personal user because I found that even with fine-

icate using a dedicated GitHub user not using my own personal user because I found that even with fine- grained access tokens it is pretty hard to get the boundaries exactly right. On top of that using your own GitHub credentials for the agent gets confusing very quickly because now when you look at a commit or a pull request it's no longer obvious whether that was you or the agent. I really prefer a clean separation between human actions and agent actions and not just for

agent. I really prefer a clean separation between human actions and agent actions and not just for security but also for clarity. So by giving the remote agent its own GitHub account you can solve this problem but it may come at a cost of an additional seat which to me personally is worth it. Taking a look at the PR we can see my Cloudbox user created a PR and let's quickly test it out we can say dhpr checkout 5, yarn install, yarn def, taking a look at the PR and

quickly test it out we can say dhpr checkout 5, yarn install, yarn def, taking a look at the PR and the browser we can see we got rid of the brown color and instead have a much cleaner interface now should have done that sooner. In the next lesson I'll be showing you a fun experiment I did with the perpetual loop. Join me there.