What it does

The on-premises data gateway is a Windows service you install inside the customer's network that relays traffic between cloud services — Power Automate, Power Apps, Power BI, Azure Analysis Services, Logic Apps — and data sources that stay on-premises. The data source never gets exposed to the internet; the gateway makes the outbound connection.

Key facts

• Two types. The standard on-premises data gateway supports multiple users and multiple data sources across all supported services. Personal mode is single-user and works only with Power BI.
• Gateways can be grouped into clusters. Each cluster supports up to 10 members, and clusters already running more than 10 continue to work but reject new members until one is deleted.
• Deleting a gateway is a soft delete. The cluster moves to a Deleted gateways (Preview) view in the Power Platform admin centre and has to be purged with Permanently delete before the tenant really stops counting it. Documented 10 Sept 2026 in Gateway management.
• Traffic goes to the primary gateway in a cluster unless it's unavailable, at which point the service moves to the next available member. Enabling "Distribute requests across all active gateways in this cluster" switches selection to random; with it disabled the cluster uses round-robin.
• All cluster members should run the same gateway version. Mixed versions cause failures that look random.
• Admins can throttle members on CPU and memory via CPUUtilizationPercentageThreshold and MemoryUtilizationPercentageThreshold in the gateway config file. Both default to 0, meaning disabled. ResourceUtilizationAggregationTimeInMinutes defaults to 5. If every member in a cluster is over a limit, the request fails outright.
• Gateway use is included with Premium, Process and Hosted Process licences. Connectors that need it include SQL Server, file system, SharePoint Server on-premises, and the HTTP connectors when pointed at internal endpoints.

When to use / skip

You need one whenever a flow touches something that lives behind the customer's firewall and there's no cloud-hosted equivalent. Skip it if the data source can be reached over a public HTTPS endpoint with proper auth, or if the environment is VNet-linked and subnet delegation gives you the route instead — running a gateway you don't need adds a server, a patching obligation and a single point of failure.

Configuration decisions

• Single gateway or cluster, and how many members — cluster from the start if the flows are going anywhere near production.
• Which service account the gateway runs under, and whether that account's credentials survive the customer's password rotation policy.
• Whether load balancing is enabled and whether CPU/memory throttling limits are set, or left at the default of off.
• Who holds gateway admin rights, and whether that list survives the consultant leaving the project.
• Where the gateway machine sits relative to the data sources — latency to the data source matters more than latency to the cloud.

Gotchas

• The gateway is a single point of failure until it's clustered, and the most common production incident is a single gateway VM being rebooted for patching mid-run.
• Leave an offline member in a cluster rather than disabling or removing it and requests get routed to it first, time out, then move on. Performance drops and nobody can see why.
• Gateway version updates aren't automatic in every deployment, and a lagging member in a cluster produces intermittent, unreproducible failures.
• Credentials are stored per data source on the gateway. Rotating a service account password breaks every flow using that data source at once, silently, until someone re-enters it.
• Dataflow Gen2 needs the primary cluster member up to create or edit connections, even if other members are healthy.
• A tenant gateway-region change won't complete while soft-deleted gateways exist. Deleting every visible gateway in the source and target regions isn't enough: you also have to open Deleted gateways (Preview) and permanently delete each cluster under Deleted clusters. The blocker gives you no obvious clue what it's waiting for, and this is the kind of thing that eats a change window.

Consultant notes

• Get the gateway into the infrastructure workstream early with a named owner in the customer's IT team. It's a server, and it needs to be treated like one — monitoring, patching, DR.
• Two members minimum for production. Push back hard on "we'll cluster it later"; later never comes and the first outage is always at month-end.
• If a region migration is anywhere in the roadmap, do the soft-deleted gateway purge as a separate, earlier task and confirm the Deleted gateways view is empty. Discovering it on the day is how a two-hour change becomes an aborted one.
• Warn the client that the gateway machine's CPU and memory become a shared resource across Power BI refreshes and Power Automate runs. Sizing conversations should include the BI team.

---

Recheck after gateway version updates, when Deleted gateways leaves preview, or if the client moves to VNet-linked environments and the gateway stops being the only route in