Workato On-Prem Agent: Architecture for Hybrid Cloud Integration

Few enterprises run entirely in the cloud. ERP databases, file shares, Active Directory, and message queues often stay behind the firewall for regulatory, latency, or legacy reasons, while the business increasingly runs on SaaS. That leaves integration architects with a hard question: how does a cloud iPaaS reach systems that are deliberately unreachable from the internet?

Workato answers it with the on-prem agent (OPA). Here is how it is architected and what to plan before rollout.

What the On-Prem Agent Does

The OPA is a lightweight service installed on a host inside your private network. Recipes still run in Workato's cloud. When a recipe step targets an on-prem database, file system, or application, Workato routes the request through the agent, which executes it locally and returns the result. Orchestration stays in the cloud; the agent provides controlled local reach.

A single agent can serve many internal systems, including databases such as SQL Server, Oracle, and PostgreSQL, on-prem file directories, JMS message brokers, and LDAP directories.

The Core Pattern: Outbound-Only Tunneling

The defining architectural choice is that the agent never accepts inbound traffic. On startup, it opens an outbound, TLS-encrypted WebSocket connection to Workato's on-prem gateways over TCP port 443. Because the tunnel is initiated from inside and kept open, Workato can dispatch jobs through it without ever connecting into your network.

This removes the usual hybrid-integration baggage: no inbound firewall rules, no DMZ relay, and no public endpoints on internal databases. Your network team only needs to allow outbound traffic from the agent host to Workato's published gateway addresses.

Security Model: Mutual TLS on a Private PKI

The tunnel uses mutual TLS, so both ends prove their identity. The gateway presents a certificate signed by Workato's private certificate authority, and each agent presents its own client certificate, generated during activation. The agent's embedded trust store accepts only Workato's private CA.

This design protects against fraudulent certificates from a compromised public CA, man-in-the-middle interception, and rogue agents attempting to connect. It also has two operational consequences. Agent certificates expire one year after generation, so rotation belongs on your calendar. And SSL inspection tools such as Zscaler or Cisco Umbrella will break the connection because they re-sign traffic with their own CA. Importing that CA into the agent won't help; the fix is a do-not-inspect exception for Workato's gateway domains. Involve your security team early.

Within Workato, role-based access control determines who can create groups, add agents, or build on-prem connections.

Resilience and Scale: On-Prem Groups

Agents are organized into on-prem groups, and connections bind to a group rather than an individual agent. Workato distributes workload evenly across active agents in a group, so adding agents delivers load balancing, fault tolerance, and high availability together.

Groups also enable zero-downtime maintenance: with two or more active agents, you can upgrade them one at a time while the others keep processing jobs. A sound design places group members on separate hosts or availability zones and uses distinct groups per environment, such as production and development.

Two Ways to Define Connections

Cloud profiles, introduced in OPA version 2.15.0, let you configure on-prem connections directly in the Workato interface, like any SaaS connector. This centralizes governance and avoids editing files on servers.

Connection profiles take the opposite approach. Details live in the agent's local config.yml file, and Workato references each connection only by profile name. Sensitive values can be encrypted with the bundled encryptor tool or sourced from an external secrets manager, though encryption keys are agent-specific, so passwords must be re-encrypted when an agent is replaced.

Choose cloud profiles for simpler administration, or connection profiles when policy requires credentials to stay inside the perimeter.

Hybrid and Multicloud Deployment Patterns

The agent runs on 64-bit Linux, Windows, and macOS, and as a Docker image, supporting several patterns. In a data center, a VM sits close to the ERP database it serves to minimize latency. In public cloud, an agent on an AWS, Azure, or Google Cloud instance inside a private VPC reaches managed databases with no public endpoint. In networks with restricted egress, the tunnel can run through a corporate proxy that permits CONNECT requests to Workato's gateways.

For logic with no standard connector covers, OPA extensions let you deploy custom Java code on the agent and call it from Connector SDK connectors through the secure tunnel.

Pre-Deployment Checklist

Treat Workato's published minimums of 8 GB RAM, 768 MB of disk, and a 64-bit CPU as a floor, and size up for high-volume file or batch database workloads. Confirm your plan includes on-prem connectivity, since it isn't available on every tier. Allowlist gateway addresses, exempt them from SSL inspection, and schedule certificate rotation. Keep agent versions under a year old, as Workato deprecates older releases on a recurring schedule. For large estates, automate group and agent provisioning through the Workato API.

The Bottom Line

The Workato on-prem agent turns hybrid integration from a network exposure problem into an outbound connectivity problem. Its outbound-only tunnel, private-PKI mutual TLS, and group-based high availability let cloud recipes work with firewalled systems without opening your perimeter. Get the network exceptions, group design, and credential strategy right up front, and the agent becomes a durable bridge between your legacy core and your cloud stack.