Deployment Topologies
Three ways to run Robomotion. The choice is usually made by a constraint rather than a preference, so this page leads with the constraints.
| Cloud | Private Cloud | On-Prem | |
|---|---|---|---|
| Control plane runs | Robomotion's infrastructure | A cluster dedicated to you, operated by Robomotion | Your infrastructure, operated by you |
| Your flows run on | Your robots | Your robots | Your robots |
| Data at rest | Robomotion's region | The region you choose | Wherever you put it |
| You operate | Nothing | Nothing | Everything |
| Sign-in address | yourcompany.robomotion.io | your domain | your domain |
| API address | api.robomotion.io | your domain + /api | your domain + /api |
| Right when | You want it to work on Tuesday | Data residency or isolation is contractual | Regulation or policy forbids third-party operation |
Note the row that does not change: your flows run on your robots in every topology. The choice is about where the control plane lives, not where the work happens. See Robot.
Cloud
The hosted service. Sign up, install a robot, start building — no infrastructure decisions.
Choose it unless you have a specific reason not to. Most reasons people give for avoiding it turn out to be satisfied already by the fact that flows execute on their own machines and credentials are encrypted before upload.
Private Cloud
A dedicated deployment, in a region you choose, operated by Robomotion.
The usual reasons:
- Data residency as a contractual or regulatory requirement — data stays in a named jurisdiction.
- Isolation — no shared database, no shared cluster, no noisy neighbours.
- Your own domain for sign-in and the API, so nothing points at a third-party hostname.
- A custom retention or backup policy that differs from the shared service.
You still operate nothing. Upgrades, patching and backups remain Robomotion's job.
On-Prem
You run the whole control plane and everything it stores. Nothing leaves your network.
Choose it when regulation or policy genuinely forbids a third party operating the control plane — some public-sector, defence, and regulated-finance environments. It is a real commitment, so be honest about the cost:
- You own upgrades, database backups, certificate renewal and capacity.
- You own the failure modes. A stuck TLS renewal or a full disk is yours to notice.
- Support debugging is slower, because Robomotion cannot see your logs.
If the requirement is really about data rather than operation, Private Cloud usually satisfies it at a fraction of the ongoing effort.
What changes for you
Licensing. Robot limits and features come from a signed licence file rather than a subscription. See Licenses.
API address. Everything under /api on your own domain — so https://robomotion.acme.inc/api/v1/robots.list
rather than https://api.robomotion.io/v1/robots.list. The playground has your
origin as a server option for exactly this reason.
Authentication. LDAP and OIDC matter more here, because an isolated deployment usually sits behind an existing corporate directory. Configure it under Admin Console → Authentication.
Secrets in environment variables. On-prem robots are typically started by systemd or
Docker rather than by a person, so use ROBOMOTION_WORKSPACE, ROBOMOTION_ROBOT_ID and
ROBOMOTION_ROBOT_TOKEN instead of command-line flags — a flag is visible in ps to every
user on the box. Linux VPS has a systemd unit.
Network requirements
The property that makes robots easy to place: a robot needs no inbound access. It opens an outbound TLS connection and keeps it open. No port forwarding, no inbound firewall rule, no public address — a laptop behind NAT works the same as a datacentre host.
What a robot needs outbound, on 443:
| Destination | For |
|---|---|
| Your workspace host | The control-plane connection, over WSS |
| The package registry | Downloading packages a flow needs |
| Whatever your flows reach | The APIs and sites being automated |
Where the network is restrictive:
- Proxy —
--proxy [<scheme>://]<host>[:<port>]on the robot, or set it in the robot config. - Allow-listing — allow your workspace host and the package registry. Robots do not need to reach each other.
- TLS inspection — a middlebox re-signing traffic must have its CA trusted on the robot's machine, or the websocket will fail to establish.
If your flows drive a GUI
This is the requirement most often missed on a server, and it is worth stating separately because it is not a networking problem.
Headless browser work and API, database or file operations need no display. Headed browser automation and any GUI automation need an interactive desktop session. On Linux that means X11, Wayland, VNC or Xvfb; on Windows it means a logged-on session, because a service in session 0 has no desktop. The Windows VPS and Linux VPS guides cover both.
Data residency
What is stored, so you can answer the question precisely:
| Data | Where |
|---|---|
| Flow definitions | Control plane object storage |
| Credentials | Control plane, encrypted client-side — see Security Model |
| Job history and audit | Control plane |
| Data your flows process | Nowhere in the control plane, unless a flow explicitly writes it there |
That last row is the one that usually settles a residency discussion. An invoice a robot reads and posts to your ERP never reaches Robomotion at all — the robot handled it locally. What the control plane learns is that a job ran, on which robot, for how long, and whether it succeeded.
Exceptions to check for: Queues hold the item payloads you put in them, artifacts hold what a flow uploads, and job logs hold whatever your flow logs — so do not log a customer record.
Next
- Robot — what actually executes a flow, and where
- Security Model — encryption, robot identity
- Install a robot on a Linux VPS