Workato On-Premise Agent: hybrid integration for SMEs

For a European SME that needs to integrate a cloud iPaaS with systems that have to stay inside its own network — a Postgres behind a firewall, an SAP instance in a Spanish datacentre, a shared-folder system a client’s security team will not expose — the Workato On-Premise Agent (OPA) is the piece that makes the hybrid model workable without breaking data-sovereignty expectations. This post walks through what the OPA actually is, when it makes sense for an SME, the architecture and system requirements, configuration posture, and the Spanish-market compliance hooks worth naming in the same breath.

When an On-Premise Agent actually earns its place

The OPA is a lightweight software agent that runs inside the SME’s network and gives the Workato cloud a tunnel to on-premise systems without opening inbound firewall rules. The agent initiates the outbound connection to Workato; Workato never reaches into the private network. That single detail is why the OPA fits the security posture of a Spanish SME operating under NIS2 Directive (EU) 2022/2555 or ENS-scope public-sector contracts — the boundary stays where the SME’s security team expects it to stay.

The SMEs where the OPA pays back are the ones whose integration requirements mix with something the security team cannot move to the cloud: a security-sensitive system in finance or healthcare, a data-sovereignty constraint that requires personal or regulated data to stay inside Spain or the EU, or a high-availability requirement where the SME wants multiple agents on-premise to survive a single-host failure. For the SME building a prototype or running everything cloud-native, the OPA is overkill and a full cloud connector is the right answer. For the SME with a Verifactu flow, a healthcare EHR, or a local ERP, the OPA is the pragmatic middle path — the business process lives in Workato, the data stays at home.

Architecture and system requirements — what the security officer needs to see

The operational architecture is deliberately boring, which is the point. The agent installs on a machine inside the SME’s network, exposes a small set of connection profiles to Workato, and synchronises data between connected systems at the cadence the recipe defines. Three components to understand:

1. Agent installation. One agent per host, running on Linux (Ubuntu is the typical choice), Windows, or macOS. The agent runs as a service.
2. Configured connections. A config.yml file declares the connection profiles — which databases, file systems, enterprise applications, and Java-extension services the agent is allowed to talk to. The security officer reviews this file before the agent goes live.
3. Data synchronisation. The agent handles the data pull/push per recipe definition, respecting the connection profile’s authentication and encryption.

System requirements for a baseline SME deployment:

For a Spanish SME in Kit Digital Segment II (3–9 employees, voucher up to €6,000), the OPA host can be a small virtual machine inside the existing infrastructure — hardware cost is often zero if a hypervisor is already in place. The Kit Digital IA/BI category and the process-digitalisation category can jointly fund the integration build if the recipes include AI-enrichment or automation components aligned with the voucher criteria.

Configuration posture — config.yml, on-prem groups, encryption

The config.yml is the file where the SME’s integration shape is declared. The posture that survives past the first deployment is to treat this file as versioned code — check it into the integration repo, review changes in pull requests, apply the same change-management rules as to any production system. Key fields:

• Connection profiles. One named profile per backend — one for the Postgres, one for the S3-compatible on-prem bucket, one for the SAP connector, one for each Java extension. Each profile names the authentication method and the encrypted credential reference.
• Password encryption. Credentials are never stored in cleartext. The agent supports an encrypted password store, and the encryption key is managed outside the config file — typically a KMS or secret manager inside the SME’s network.
• Proxy configuration. If the SME’s network forces outbound HTTPS through a corporate proxy, the agent picks that up from the config file. This is also where the SME can pin the proxy to a specific IP or hostname for supply-chain visibility.
• Connection profile types. The profile type determines which connector schema applies — a database profile for MySQL or PostgreSQL, a file-system profile for AWS S3 or Google Cloud Storage, an enterprise-system profile for Salesforce or SAP, a Java-extension profile for a Spring Boot microservice the SME already runs in-house.

For high-availability requirements, the OPA supports on-premise groups — multiple agents clustered for load balancing and failover. When the primary agent goes down, traffic routes to the secondary with no operator intervention. For a SME running a regulated flow (banking, healthcare, public-sector) where a failed integration means a missed SLA, the two-agent group is the minimum viable posture. The group configuration lives in config.yml alongside the connection profiles, so one file captures the full deployment shape.

The security model the SME should document for its own audit file has three layers: no inbound firewall rules (the agent is outbound-only), encrypted credentials with external key management, and least-privilege connection profiles (each profile scoped to the minimum set of tables or endpoints the recipe needs). The official technical reference sits on help.docebo.com for Docebo connector specifics, and Workato’s own documentation for the OPA baseline.

Reconnection, lifecycle, and the Spanish-market compliance overlay

Agents disconnect occasionally — a network blip, a host reboot, a certificate rotation. The posture that works is to treat reconnection as an expected event, not an incident. The OPA surface in the Workato UI shows the connection status per agent, and the SME’s ops runbook should name who monitors that status, what the disconnect-response SLA is, and when a reconnect failure escalates to an incident. Agent Lifecycle Management in the Workato UI covers version upgrades, decommissioning, and key rotation — handle these on a quarterly cadence alongside the rest of the SME’s security-hygiene work.

For troubleshooting the common issues — connection problems, database connection failures — the first line of diagnosis is always (a) is the outbound HTTPS path to Workato working, (b) does the agent have the right credentials in its encrypted store, and (c) is the target system accepting the connection from the agent’s source IP. Nine times out of ten the fix lives in one of those three checks.

On the compliance side, the OPA is not a regulated AI system on its own — it is an integration runtime. But it crosses the GDPR processing boundary every time a recipe moves personal data between systems. For a Spanish SME, the Article 30 record of processing entry for each OPA-routed flow should name the purpose, lawful basis, data categories, processor (Workato Inc.), and retention. If the recipes include any AI-driven decisioning (a classification step, an emotion-analytic enrichment, a high-risk automated decision), the EU AI Act overlay applies and AESIA is the supervisory reference. The OPA itself does not trigger AI Act obligations — what flows through it might.

Ready to get started?

Working on this yourself? J4SGON S.L. delivers Docebo Connect, HRIS, SSO and migration work for European organisations — see what a scoped engagement covers or describe your project and we will reply with a written scope.