On-premise data gateway for Microsoft Fabric, Power Platform and Azure
Cloud services reach on-premise databases and systems through one HTTPS endpoint - no VPN, no vendor gateway and nothing installed on the cloud side.
Your data lives in a local network - databases, an ERP, internal APIs - and your analytics or automation runs in the cloud, in Microsoft Fabric, Power Platform or anything hosted on Azure or elsewhere. The question is always the same: how does the cloud side reach the on-premise side?
With Zato, the answer is that Zato runs where the data is. It is installed inside your network, next to the systems it reads, and it publishes HTTPS REST channels that the cloud services call. The data never moves anywhere it was not going anyway, and nothing is installed on the cloud side at all.
Do you need a VPN or a data gateway
No. The role an on-premise data gateway plays for cloud services - relaying their requests to local data - is what a REST channel already does, through one HTTPS endpoint with TLS and authentication instead of per-application tunnels and relay agents.
A VPN, an SSH tunnel or a reverse proxy is a network-level choice your organization may already have made, and Zato works inside any of them - behind the proxy, inside the VPN, or exposed directly. None of them is required for cloud services to reach on-premise data, because everything a caller needs is the one endpoint.
An on-premise database as a REST API
The service below reads a warehouse database that is reachable only inside the local network. The SQL connection is defined in the Dashboard and the query runs where the database is:
# -*- coding: utf-8 -*-
# Zato
from zato.server.service import Service
class GetStockLevels(Service):
output = 'product_id', 'quantity'
def handle(self):
conn = self.out.sql['Warehouse DB']
query = 'SELECT product_id, quantity FROM stock WHERE quantity > :min_quantity'
params = {'min_quantity': 0}
result = conn.execute(query, params)
self.response.payload = result
A REST channel mounts the service at a URL path, say /api/stock, with an API key from a security definition assigned to it. That URL is the whole gateway - anything that can send an HTTPS request can now read the warehouse:
The output declaration keeps the response to the declared fields, so the channel returns product_id and quantity and nothing else the query may pick up later.
Calling in from Microsoft Fabric
A Fabric notebook reads the endpoint like any other HTTPS API - the rows arrive as JSON, ready for a DataFrame:
# In a Microsoft Fabric notebook
import requests
url = 'https://api.example.com/api/stock'
headers = {'X-API-Key': 'your-api-key'}
response = requests.get(url, headers=headers)
stock_levels = response.json()
df = spark.createDataFrame(stock_levels)
A Data Factory pipeline does the same through its Copy activity or Web activity, with the URL as the source and the API key in a header. In both cases, Fabric is an ordinary HTTPS client and the on-premise side needs nothing installed for it.
Calling in from Power Automate
In a flow, add the HTTP action, set the method to GET, the URI to the channel's address and the X-API-Key header to the key. The response body is JSON that the following actions parse and act on - the same endpoint serves the analytics side and the automation side alike.
The other direction
Services running on-premise also call cloud APIs, and that direction is outbound HTTPS only, with nothing to open inbound at all. The Microsoft Fabric examples run notebooks and pipelines from your services, and the Power Automate examples trigger flows and read their responses - both through connections defined once in the Dashboard.
Securing the endpoint
The channel that faces the cloud carries the same protections as any other:
- A security definition - an API key, Basic Auth or bearer tokens
- TLS, either on Zato itself or on the reverse proxy in front of it
- Rate limits per caller, so one runaway pipeline cannot saturate the database
The production checklist covers what to confirm before the endpoint carries real traffic.