Skip to main content

How-to install a robot on a Windows VPS

A robot on a Windows server differs from a desktop install in two ways: it authenticates with a robot token instead of your password, and something other than you has to start it after a reboot.

Prerequisites​

  • A Windows Server or Windows VPS you can reach over RDP
  • Administrator rights on that machine
  • A robot created in the Admin Console, and a robot token for it

1. Install the application​

Follow Windows Installation over your RDP session. The installer is the same one used on a desktop.

The CLI lands in:

%LOCALAPPDATA%\Robomotion\bin

2. Create the robot and its token​

In the Admin Console → Robots, create a robot and generate a robot token. Note the robot's ID too — token authentication needs both.

3. Connect once, interactively, to verify​

robomotion-deskbot connect `
  -w rpa.acme.inc `
  -r 624609c6-1a27-458f-ace5-3889dc554e28 `
  -t <robot-token> `
  --no-attach

The robot should report connected. Stop it with Ctrl-C once you have seen that.

note

--token requires both --robot and --workspace. If either is missing the command prints its usage and exits.

4. Keep the token out of the command line​

Flags are visible to anyone who can list processes on the machine. The robot falls back to these environment variables whenever the matching flag is empty:

VariableEquivalent flag
ROBOMOTION_WORKSPACE-w, --workspace
ROBOMOTION_ROBOT_ID-r, --robot
ROBOMOTION_ROBOT_TOKEN-t, --token
ROBOMOTION_USER_EMAIL-i, --identity

Set them for the machine, so a scheduled task or service picks them up:

[Environment]::SetEnvironmentVariable('ROBOMOTION_WORKSPACE','rpa.acme.inc','Machine')
[Environment]::SetEnvironmentVariable('ROBOMOTION_ROBOT_ID','624609c6-...','Machine')
[Environment]::SetEnvironmentVariable('ROBOMOTION_ROBOT_TOKEN','<robot-token>','Machine')

Then the connect command reduces to:

robomotion-deskbot connect --no-attach --log-level info

5. Start the robot after every reboot​

Pick based on what your flows do — this is the decision that matters most on Windows.

If your flows drive the GUI​

GUI automation — Windows Automation, Image Automation, mouse and keyboard nodes, and headed browser flows — needs a real interactive desktop session. A Windows service running in session 0 has no desktop, so those flows will fail there.

Use Task Scheduler with an auto-logon session:

  1. Configure the server to log the robot's user on automatically after boot.
  2. Create a task: Trigger → At log on for that user.
  3. Action → start %LOCALAPPDATA%\Robomotion\bin\robomotion-deskbot.exe with arguments connect --no-attach --log-level info.
  4. Settings → enable If the task fails, restart every 1 minute, and disable Stop the task if it runs longer than….
  5. Leave Run only when user is logged on selected. This is the point of the setup.
warning

Closing an RDP window disconnects the session and the desktop stops rendering, which breaks GUI automation. Disconnect with tsdiscon — or configure the server to keep the console session active — rather than logging off.

If your flows are headless only​

API calls, database work, file and Excel operations, and headless browser flows need no desktop. Run the robot as a Windows service with the environment variables from step 4, or use the same Task Scheduler task with Run whether user is logged on or not.

Useful flags for unattended robots​

FlagWhy it matters on a server
--no-attachSkips attaching to the Flow Designer. Faster, and correct for an unattended robot.
--lockLock mode refuses to run any flow that is not already cached — a hardening measure for production.
--log-leveldebug, info, warning, error, off.
--logdirSend logs somewhere you rotate.
--proxy[<scheme>://]<host>[:<port>] for outbound proxies.
--send-crash-dumpsForwards crash dumps to Robomotion.

Verify​

In the Admin Console → Robots, the robot should show as connected. Then reboot and confirm it comes back without you touching it.

Next steps​