Configure self-hosted integration runtime for secure hybrid ingestion

1. Define what runs on the self-hosted runtime

Use this pattern to copy from an on-premises SQL Server or a private VM database into an approved Azure destination. Install the self-hosted IR on a dedicated, hardened Windows host close to the source; it must reach both source and sink. The factory orchestrates the job, while the runtime moves data directly between stores. ExpressRoute connectivity alone does not cause Azure IR to run inside your network.

Inventory the Windows hosts, source DB, cloud destination, Key Vault, any staging storage, and the factory control endpoint in the system boundary. The provider offering does not cover your own host configuration or source database responsibilities. Self-hosted IR supports movement and activity dispatch; Mapping Data Flows use managed Azure compute and require a separate approved architecture.

2. Build the hosts and register the logical runtime

Choose a Windows release currently supported by the IR installer, supported .NET dependencies, and approved connector drivers. Microsoft does not support installation on a domain controller. Keep the runtime on separate hosts from the production database where practical to avoid contention. Apply your program’s patching, endpoint protection, disk encryption, service-account, and administrator-access baselines.

Create a named self-hosted IR in the approved factory, install the verified Microsoft installer, and register each node to that same logical IR using the registration key through an approved secret-handling process. Treat that key as a credential: keep it out of scripts, job output, tickets, and examples. Restrict access to registration-key retrieval and document recovery and revocation procedures.

The following PowerShell reads runtime status after approved authentication. It does not install a node or retrieve registration keys:

Connect-AzAccount -Environment AzureUSGovernment
Set-AzContext -SubscriptionId $ApprovedSubscriptionId
$runtime = @{
  ResourceGroupName = $ApprovedResourceGroup
  DataFactoryName = $ApprovedFactory
  Name = $ApprovedRuntime
}
Get-AzDataFactoryV2IntegrationRuntime @runtime -Status

Set connectVia to this logical runtime in both applicable linked services. Verify the source’s authentication mode and SQL driver support. Factory managed identity, VM identity, Windows service account, and source SQL credential are distinct identities; document which one is used at each hop.

3. Configure cloud-specific control and data connectivity

Discover the actual service URLs from the runtime’s Nodes view instead of allowing the whole Internet. Microsoft documents HTTPS control traffic to the factory and conditional Azure Relay traffic for interactive authoring. Download/update traffic and identity, Key Vault, source, and destination dependencies need their own approved paths.

Use private endpoints and custom DNS in the customer VNet for stores, with on-premises forwarding through an approved resolver. For ADLS Gen2, configure DFS and Blob private paths. SQL needs its own network policy, including connection-policy dependencies where applicable; a single successful TCP 1433 test is not a complete SQL connectivity test.

Self-contained interactive authoring can remove the Relay dependency for supported runtime operations; Microsoft documents limitations including “Get IP” and “Send log.” A Limited runtime status can indicate that interactive authoring or updates are unavailable even when scheduled activities run. Test these functions separately.

4. Keep credentials and cryptography within the approved baseline

Self-hosted IR can use Windows DPAPI to protect locally stored credentials and synchronize them across nodes. That mechanism is not proof that your program’s cryptographic requirements are satisfied. Prefer supported Key Vault-backed secrets and restrict the retrieval and connector paths. Keep disk access, local administrator privileges, backups, and diagnostic bundles within the data-handling boundary.

Restrict local-machine access and credential-setting interfaces to the minimum required by your connectors and HA design. Preserve local folder-path validation unless there is an approved exception. Private Link and HTTPS do not independently demonstrate compliance of the operating system, driver, or credential protection.

5. Add nodes and rehearse recovery

Microsoft supports up to four nodes on one logical self-hosted IR. Start with at least two appropriately sized nodes when the workload requires node-level availability, placed in separate approved failure domains. HA is runtime capacity and failover; it does not make every copy exactly-once or protect against shared network, source, credential, and destination failures.

Follow the documented Remote Access from Intranet requirements when adding nodes. Scope the node-to-node port, commonly 8060 or your configured alternative, to the participating nodes and approved management path. Do not expose it to the Internet. Verify credential synchronization, driver versions, DNS, and sink reachability on every node.

Load-test actual concurrent jobs while observing host CPU, memory, source query pressure, disk usage, and destination throughput. Patch or replace one node at a time under a controlled maintenance plan. Store node rebuild instructions and required versions; neither IR registration nor HA is a substitute for rebuilding the customer-managed hosts.

6. Test failure, replay, and unauthorized access

1. Run a synthetic source-to-sink copy and reconcile keys, types, row counts, and the batch manifest.
2. Take one node offline during an approved test; observe queued or retried work and verify one logical published result.
3. Rebuild a node from the approved baseline and confirm it can join, synchronize, and execute without exposing a registration key.
4. Block an unapproved destination and revoke a test credential to verify independent network and identity denial.
5. Exercise secret rotation and a denied source table, then test authoring and update delivery separately.
6. Restore the control state and replay a retained batch using the incremental-load recovery procedure.

Keep sanitized node inventory, patch and driver versions, connection decisions, test run IDs, and recovery timings. Continue with incremental copy and safe replay and failure and capacity monitoring.

Sources and technical review

Technical review: October 7, 2026. Recheck cloud, regional, connector, and authorization scope before implementation.

• Self-hosted runtime requirements, FIPS note, HA, and Government endpoints
• Integration runtime capabilities
• Factory Private Link and interactive authoring limitations
• Key Vault-backed credentials
• Azure Government differences

Public offering and service-scope checks are documented in the Data Factory hub. The protected provider authorization package and live Azure behavior have not been reviewed or tested by these guides.