AI & Automation

Cisco Workflows Automation Remote: OVA Deployment Walkthrough

By Travis · May 13, 2026 · Updated May 16, 2026 · 12 min read

#meraki #workflows #cisco #automation #ova #vmware #remote

In the last post I walked through building a Cisco Workflow that runs commands on IOS-XE Catalyst devices over SSH. I mentioned the Automation Remote at the end and then pretended it didn’t matter. For about 90% of real enterprise deployments — where your switches, routers, ISE, FMC, and Catalyst Center sit behind firewalls and aren’t reachable from the public internet — the Remote is the first thing you need to deploy. Without it, Workflows is just a fancy dashboard that can’t talk to anything you own.

This post walks through the actual OVA deployment in VMware vSphere: what gets installed, how the connection back to Cisco’s cloud works, the configuration steps from “create the Remote object” through to “status: connected,” and the maintenance gotchas you’ll hit at the 12-month mark if nobody warned you.

What the Automation Remote actually is

The Automation Remote is a small Linux VM you deploy inside your network. Once running, it makes a single outbound TLS connection to Cisco’s automation cloud — Cisco describes this as TCPS connectivity on port 8883 (the well-known MQTT-over-TLS port, though Cisco’s current docs don’t specify the protocol layered on top). Workflows running in Cisco’s cloud route activity calls (SSH to a switch, API call to a private Catalyst Center, REST call to your internal Infoblox) through that outbound connection. The Remote receives the instruction, executes it against the target on your network, and ships the result back over the same channel.

In other words: no inbound firewall rules required. The Remote is a reverse-relay, not a server. From a security review standpoint, it’s much easier to defend than punching holes in a perimeter firewall for a SaaS automation platform.

Under the hood:

The OVA ships Ubuntu 24.04 LTS (was 20.04 — Cisco migrated after the May 2025 EOL).
The Remote runs on a small K3s Kubernetes distribution. This matters because of the certificate-expiry gotcha below.
The current OVA includes adapters for Catalyst Center, Catalyst SD-WAN, Cisco ISE, Cisco FMC (Firewall Management Center), and NetBox, plus generic SSH/REST.
An organization can have up to 20 Remotes total — enough for most multi-region deployments.

When you actually need one

You need an Automation Remote when:

Your targets (Catalyst Center, IOS-XE devices, ISE, FMC, internal IPAM, on-prem ServiceNow, etc.) aren’t reachable from the public internet.
You’d rather not punch inbound holes in a firewall for a SaaS to reach private gear.
You want the audit trail of an explicit relay in your network rather than direct cloud-to-device traffic.

You don’t need one when:

Everything you’re automating is already cloud-hosted (Meraki Dashboard API, public SaaS).
You’re managing internet-reachable Catalyst Center clusters or DMZ-published controllers.
You’re running a tiny lab and willing to allowlist Cisco’s Workflows source IP ranges to a single device.

Prerequisites

Before you start the OVA deployment:

VMware ESXi 5.5 or newer. Cisco officially supports anything from 5.5 forward, but realistically you should be on a modern vSphere release (7.0+) for any production deployment. The HTML5 client and modern vCenter features make the install meaningfully easier.
The Remote’s compute footprint is small. Cisco’s published minimum is 2 vCPU, 2 GB RAM, and 30 GB disk per appliance. That’s all most deployments will ever need — the Remote is a relay, not a workhorse.
Outbound TCPS 8883 from the Remote’s network segment to the Cisco automation cloud endpoint for your region. Per the current Meraki documentation, the regional endpoints are:
- North America — us-remote.workflows.meraki.com
- EU — eu-remote.workflows.meraki.com
- APJC — ap-remote.workflows.meraki.com
Cisco also publishes the underlying source IP addresses on the Automation Remote doc for environments that allowlist by IP rather than hostname. Always confirm the current list via nslookup before adding entries to a firewall — these can change.
Outbound 443 for image pulls, NTP and DNS, and certificate revocation.
NTP and DNS reachable from the Remote VM. NTP especially — K3s and Kubernetes certificate validation are unforgiving on clock skew.
A target network segment with line-of-sight to the gear you’ll automate. The Remote needs to reach the devices it relays to; that’s what makes it useful. Multi-VLAN reachability is fine; the Remote’s NIC just needs an IP that can route to the targets.
A vSphere user with permission to deploy OVAs and customize vApp properties.
An SSH public key if you want SSH access to the Remote VM for troubleshooting (recommended; you’ll be glad you have it at the 12-month mark).
A SOCKS5 proxy address, if your environment requires the Remote to reach Cisco’s cloud through a proxy. Cisco’s docs note that only SOCKS5 is supported for this; HTTP/HTTPS proxies are not.

Plan on roughly an hour for a first deployment — the OVA itself imports in a few minutes; the rest is config and verification.

Step 1 — Create the Remote object in Automation first

Counter-intuitively, you start in the cloud, not in vSphere. The Workflows console generates a unique configuration bundle for each Remote, and that bundle gets injected into the OVA at deploy time. Build the cloud-side object first, then deploy the VM with its credentials baked in.

In the Meraki Dashboard, go to Automation → Targets and click the Remotes tab.
Click New Remote.
Give it a Display Name that includes the location and environment. Something like dc1-prod-remote rather than remote-1. You can’t easily rename later.
Add a short Description with the segment it lives on, who owns it, and what it’s intended to reach.
In the Remote Details section, pick DHCP or Static IP. For production, always use static — Remotes that change IP cause cascading certificate and routing problems. For a quick lab, DHCP is fine.
If you picked Static, fill in IP (in CIDR notation, e.g. 192.168.1.100/24) / DNS server list / gateway for the appliance.
Check the default internal subnets. The Remote uses internal subnets for its K3s networking. Cisco’s documentation explicitly warns that these defaults can collide with subnets already in use on your network — and that any change you make to them at creation time is permanent. You can’t fix a subnet collision later without redeploying the Remote from scratch. Override the defaults now if you know they’ll overlap with anything you have routed: toggle Show advanced options and fill in Remote Cluster Subnet and Remote Service Subnet with values that don’t conflict.
If your Remote must reach the internet through a proxy, toggle Requires Proxy and provide a SOCKS5 proxy address. (HTTP/HTTPS proxies are not supported here.)
Save.

The Remote will appear in the table with a status of Not Connected. That’s expected; it has nothing to connect from yet.

Step 2 — Download the configuration bundle

With the Remote object created:

In the Remotes tab, find your new Remote, click the ⋯ menu in the Actions column, and choose Connect.
In the dialog that opens, click Generate Package.
A file called remotePackage.zip downloads. Unzip it — inside there’s a remoteconfig.txt file. You’ll paste the contents of that file into the OVA at deploy time. It contains the credentials that pair this specific VM to this specific cloud-side Remote object.

Treat remoteconfig.txt like a credential. Anyone who has it can register a VM as your Remote.

Step 3 — Download the OVA

On the same Remotes page, click Download Appliance. This pulls the current OVA from Cisco. The file is large — plan on a few minutes depending on connection speed.

Verify the OVA hash before deploying. Cisco publishes the SHA hash on the same Remotes page next to the download link. Compare what you downloaded to what they published — shasum -a 256 remote.ova on macOS/Linux, Get-FileHash -Algorithm SHA256 remote.ova in PowerShell. If they don’t match, re-download. Never deploy an OVA you can’t verify.

Step 4 — Deploy the OVF template in vSphere

In your vSphere client (HTML5 on modern releases; older 5.5/6.x environments may still be on the legacy clients):

Right-click the folder or resource pool where you want the Remote to live and choose Deploy OVF Template.
Select Local file and browse to the OVA you downloaded.
Click Next.
Name and Location. Give the VM a name that matches the Remote display name from Step 1 (dc1-prod-remote). Place it in a folder that’s sensibly named — these VMs tend to get forgotten about until they break.
Compute Resource. Pick the cluster or host. Any modern ESXi with HA/DRS available is fine.
Review Details. Confirm the OVA contents and signing info match what Cisco published.
Storage. Pick the datastore. Allow at least 30 GB; thin-provision is fine for non-production, thick-lazy for production if you’ve got the space.
Networks. Map the Remote’s NIC to the VLAN that has line-of-sight to your management network and outbound internet for the 8883 connection. This is usually your inside management or out-of-band segment.

Step 5 — Customize the vApp template

This is the only screen that’s specific to the Workflows Remote. You’ll be asked for:

A Unique ID and hostname for the appliance. Match the Remote display name.
SSH public key (optional but strongly recommended). Paste a key in standard ssh-rsa AAAA… or ssh-ed25519 AAAA… format. The OVA appends it to the appliance user’s authorized_keys. The docs include ssh-keygen instructions for Linux/macOS and PuTTYgen for Windows if you don’t already have a key pair.
Encoded user-data — paste the entire contents of remoteconfig.txt from Step 2 into this field. This is the line that binds the VM to your cloud Remote object. Without it the VM boots fine but won’t authenticate to Cisco’s cloud.
Default user’s password — sets the console password for the appliance user ubuntu. Cisco enforces fairly strict complexity rules here, so plan accordingly: at least 14 characters, with at least one uppercase, one lowercase, one number, and one special character. It must not contain three identical characters in a row, three sequential characters (like abc or 123), your username, or common dictionary words. Generate it from a password manager — typing one by hand will fail validation more often than not.

Click Next, review, click Finish. The deploy itself takes a few minutes — most of it is the import unpacking onto the datastore.

Step 6 — Power on and watch the connection

Power the VM on. Boot takes a couple of minutes — Ubuntu cloud-init runs through the hostname, network, and Encoded user-data ingestion before the K3s services start.

You can watch the VM console to see the boot progress (you’ll see standard cloud-init output followed by K3s pod startup). For most deployments the cleaner signal is in the cloud: in Automation → Targets → Remote Targets, refresh the page. The status should transition from Not Connected to Connected — Cisco’s docs note that a newly deployed Remote can take up to 10 minutes to register, so don’t panic at minute four.

If it stays Not Connected past the 10-minute mark:

Outbound 8883 is blocked, the wrong region endpoint is selected, or the appliance has no working DNS. SSH to the appliance (using the key from Step 5; user is ubuntu), run dig us-remote.workflows.meraki.com (or your region’s hostname) and nc -vz us-remote.workflows.meraki.com 8883. Either of those failing tells you where to look.
Status flaps between Connected and Disconnected. Clock skew. Confirm NTP is reachable and time is synced: chronyc tracking should show a System time offset under 100ms.
Status: Revoked. Someone clicked Revoke in the Workflows console (or the previous Remote object was revoked when redeploying). Generate a new remoteconfig.txt from the Remote Targets tab and re-customize the VM, or redeploy.

Step 7 — Bind targets to the Remote

A Remote on its own does nothing. It only matters once Targets are configured to route through it. Worth knowing up front: not every target type can route through a Remote. The Cisco docs are explicit that Automation Remote supports exactly three target types — HTTP Endpoint, Terminal Endpoint, and Unix/Linux Endpoint. That covers the vast majority of on-prem cases (any device you’d SSH to, any internal REST API like Catalyst Center, ISE, or FMC), but if you’re looking for a vendor-specific target type, you’ll likely use HTTP Endpoint and craft the request yourself.

Go to Automation → Targets.
Either edit an existing target or create a new one (HTTP Endpoint, Terminal Endpoint, or Unix/Linux Endpoint).
In the target configuration, find the Remotes section and the Remote Keys dropdown — the name is a bit confusing because “Remote Keys” sounds like credentials, but this is actually the dropdown that selects which Remote Target to route through.
Pick your newly-deployed Remote and click Submit.
Test the target.

The first time a target uses a Remote, the test connection adds a couple of seconds of latency while the relay path establishes. Subsequent calls are fast.

You can have multiple Targets share one Remote. You can also have a single Target use multiple Remotes for redundancy (one in each datacenter, for example) — Workflows will pick whichever is connected.

The 12-month gotcha — read this before deploying

The K3s Kubernetes layer inside the Remote uses internally-managed TLS certificates that expire after 12 months by default. When the certificates expire, the Remote disconnects and you can’t fix it from the cloud side — the VM has to be replaced.

The procedure when certificates expire, per the official Cisco documentation:

Shut down and delete the previously installed VM in vSphere to free up the IP and resources.
In Automation, find the disconnected Remote and click the Revoke action to void the existing connection details. Status will change to Revoked.
Refresh the page, then click the Regenerate action to download a new configuration file (remotePackage.zip).
Deploy a fresh OVA with the new config (steps 4–6 above).
Verify the Remote shows Connected in Automation, and that Targets still route correctly through the rebuilt Remote.

This is not optional. Cisco specifically documents that rotating the Remote VM annually is the supported maintenance path. The bright side: you can use the rotation as an opportunity to pick up the latest OVA (newer base OS, newer adapter set), so it’s not pure busywork.

Practical advice: schedule a calendar reminder for 11 months after each Remote deploys. Build the rebuild as a planned change rather than discovering it via “all my workflows are failing.” If you’re running multiple Remotes, stagger their rebuilds across the year so you’re not redeploying 20 VMs in the same week.

Maintenance and operational notes

A few things worth knowing once you have one running:

Logs. SSH to the VM as the appliance user (with your key from Step 5). The Workflows agent and K3s pods run under standard systemctl units; journalctl -u <unit> and kubectl get pods -A give you visibility. Cisco’s support docs cover the specific unit names per OVA version.

Software updates. Cisco ships updated OVAs periodically. You don’t “upgrade in place” — you deploy a new OVA alongside the old one, switch Targets over, and decommission the old. This is the same playbook as the certificate rotation, which is convenient.

Custom NTP. If you didn’t set NTP at OVA deploy time, edit /etc/chrony/chrony.conf over SSH, replace the default pool lines with your internal NTP servers, then systemctl restart chronyd. Verify with chronyc tracking. NTP problems silently break K3s — fix this first if you see any odd behavior.

Snapshots. Snapshot the Remote before any change, but don’t run it from a snapshot long-term. The K3s state on disk is what binds it to the cloud-side Remote object; restoring an older snapshot can cause certificate mismatch and require a full rebuild anyway.

Sizing. A single Remote can handle a healthy concurrent workflow load — Cisco doesn’t publish a hard limit, but in practice, target count and workflow concurrency matter more than raw throughput. For a large environment, deploy one Remote per region or per security zone rather than trying to scale a single Remote vertically.

TL;DR

The Automation Remote is a small VMware OVA (Ubuntu 24.04 + K3s) that you deploy inside your network so Cisco Workflows can reach private targets without inbound firewall rules. Outbound TCPS 8883 to a regional endpoint is the only required rule.
Deployment order matters: create the Remote object in Automation first, download the config bundle, then deploy the OVA with that config injected at vApp customization time.
The 12-month K3s certificate expiry is a real, unavoidable maintenance event. Schedule a reminder, plan the rebuild as a routine change, and use it as your “pick up the newer OVA” cycle.
Static IP, working NTP, working DNS, and a verified OVA hash are the non-negotiable prerequisites. Skip any of them and you’ll be debugging a flapping Connected/Disconnected status instead of building workflows.
Once it’s connected, binding it to Targets is a one-dropdown change. The hard part of running a Remote is the operational lifecycle, not the day-one install.

If you already have Workflows running against cloud-only targets and you’re adding your first on-prem integration — Catalyst Center, ISE, internal SSH gear — this is the deployment to do first. Once the Remote is up, the IOS-XE SSH walkthrough and everything in the Workflows use cases post become available against your private network.

Reference: Cisco Workflows Remote Setup and Deployment.