Hello there, could you clarify something to me, please?
Almost every documentation page refers to Control Room and some cloud-based solutions. Even self-hosted workers run from Control Room (so why they are self-hosted if I still need the cloud?).
How exactly can I run robots truly self-hosted on my server without any attachment to the cloud? Imagine the server without internet, only local network in some company.
There is a poor documentation about some tool named RCC. Leaving aside the fact that even this page mentions uploading to the cloud, is this what I need? Can this tool run robots, show logs, pass input variables to the robot?
First of all, because Control Room is service we provide, that is why our documentation focuses on Control Room and our cloud based solution.
We provide container based cloud Workers. When customers need “something” different (private applications, Windows desktop, privacy), then they can setup self-hosted Workers and still benefit Control Room for orchestration. See: Working with Control Room | Robocorp documentation
And rcc is command line tool for running robots. It is working under the hood of our tooling, and it is open source. And yes, it can run your robots and pass arguments to robots based on robot.yaml file, but it is not orchestrator (Control Room is). It cannot show logs, that is job of web browsers.
And I’m sorry that you see our documentation as poor on rcc front. There is additional documentation (and source code) in rcc repo, see:
We clearly still have some work to do around documenting the concepts terms better, so thank you for the feedback.
What the “Self-hosted Worker” means is that the executions of the automations happen on machines that are controlled and manage by you in networks that you control. The workers do not and cannot provide things like orchestration, centralized reporting, notifications etc. features. That is where Robocorp Control Room is working and also why it only cloud-based.
Once you start setting up orchestration functionality on CI/CD tools like Jenkins, you quickly realize that making them scalable and actually maintaining them (and the related infrastructure) is a quite the gigantic effort, so that is why we develop our Control Room as a service.
On the docs side: As RCC is an open-source tool why want to keep it’s documentation inside the repository, but we could look into also importing those directly to our docs site as well so that people find it a bit better… will ponder this.
Can I use self-hosted workers without Control Room? If I setup my own orchestration system, will I be able to run workers in any internal way (HTTP API, console commands, tcp requests etc)? And if so, where can I read more about this?
Our Worker works with our Control Room. If you want to build your own orchestration system, then it is up to you to build both orchestration and how your workers should work. Or use something like Jenkins CI/CD.
And note that communication between Worker and Control Room is not simple thing to implement. So if you start to do your own thing, please be aware of that.
And I think we don’t have documentation for that, because our focus is on our services. We are still in startup phase.
But it would be interesting to know, why don’t you want to use our (already) ready made solution and instead want to build it by yourself? Or maybe even do this: Talk to an Open Source RPA Expert | Robocorp | Robocorp for just gaining information on what is missing for you.
As Jippo explained the connection between Control Room and our Worker is heavily secured and that security is absolutely vital in all cases… no matter what the orchestration system is and what network it is running in. For example just relying on HTTPS or the fact that “these are all in an internal network” is simple not good enough.
…but the short answer is that rcc is open-source and we’d like to see that adopted as a toolchain for not just Python based automations, but any automation. At some point we did make a Jenkins + rcc example, basically also to remind to ourselves how much work is it to set that up and keep it working
…but we do have a lot of options to block data of the executions from passing to Control Room and we have customers from banking to healthcare using those options. So essentially you can leverage the orchestration of robots, processes and workers in Control Room without having any identifiable data from the robot execution inside Control Room.
But I do get that in some cases going fully “air-gapped” is the requirement, there RCC is still your friend as it can do pre-built environments etc.
