Integrations

MID Server in ServiceNow: Architecture, Use Cases, and When You Need One

MID Server is a Java application that runs inside your corporate network and bridges ServiceNow cloud with systems that are not reachable from the internet. This guide covers the problem it solves, how it works, when you need one, when you do not, capacity planning, and how to use it in Flow Designer.

The problem MID Server solves

ServiceNow is cloud-hosted. Your on-premises systems — internal databases, file servers, SNMP-managed network devices, internal REST APIs behind a firewall — are not reachable from the internet. Without a bridge, ServiceNow cannot discover, monitor, or integrate with them. MID Server is that bridge.

How MID Server works

MID Server is a Java application you install on a server inside your network. On startup, it initiates an outbound HTTPS connection to ServiceNow. ServiceNow sends work items down that connection — scan this IP range, call this internal API, run this script. MID Server executes the work and sends results back up through the same connection.

The key architectural point: no inbound firewall ports needed on your corporate network. MID Server only makes outbound connections on port 443 (HTTPS). Your firewall needs to allow outbound traffic to ServiceNow's cloud IP ranges — that is all.

When you need a MID Server

  • Discovery — scanning your network to populate the CMDB. MID Server needs line-of-sight to the devices being scanned. See the Discovery guide.
  • Integrations with internal APIs — calling a REST API that lives behind your corporate firewall from a Flow Designer flow or RESTMessageV2 script
  • JDBC integrations — connecting to on-premises databases (SQL Server, Oracle, MySQL, PostgreSQL)
  • Orchestration against internal systems — running scripts or PowerShell against internal servers
  • SNMP polling — monitoring network devices that only respond to internal network traffic

When you do NOT need a MID Server

  • Calling public REST APIs accessible from the internet
  • ServiceNow-to-ServiceNow integrations
  • Webhook receivers (inbound to ServiceNow)
  • Any system accessible directly from ServiceNow's cloud IP ranges

MID Server installation

  1. Navigate to MID Server > Download in your ServiceNow instance
  2. Download the installer for your operating system (Windows or Linux)
  3. Install on a server inside your network with outbound HTTPS access to ServiceNow
  4. Configure the MID Server config.xml with your instance URL and credentials
  5. Start the MID Server service — it connects and appears in ServiceNow within minutes

Capacity planning

One MID Server can typically handle moderate Discovery and integration load. For large enterprises, use MID Server clusters — multiple MID Servers in a pool — for redundancy and load distribution. If one MID Server goes down, the cluster continues processing. Configure affinity rules if specific integrations should always use specific MID Servers.

Using MID Server in Flow Designer

When adding a REST step in Flow Designer, the Connection configuration includes a MID Server field. Select the MID Server to route the call through — Flow Designer then proxies the REST call through the MID Server to the internal endpoint. No scripting required.

Related: Discovery guide · RESTMessageV2 · IntegrationHub spokes · Credential Aliases

MID Server architecture — how it actually works

The MID Server is a Java application that runs inside your network, establishes an outbound HTTPS connection to your ServiceNow instance, and waits for work. ServiceNow never initiates a connection into your network — the MID Server calls out. This means no inbound firewall holes are needed, which is why MID Servers can reach internal systems (databases, APIs, file shares) that are not accessible from the public internet.

Work is delivered to the MID Server as ECC Queue records. ServiceNow writes a message to the ECC Queue, the MID Server picks it up, executes the work (a Discovery probe, a REST call to an internal API, a file retrieval), and writes the result back to the ECC Queue. ServiceNow reads the result record. The entire communication path is outbound from the MID Server's perspective.

MID Server installation checklist

  • Java 11 or later installed on the host (Windows Server or Linux)
  • Outbound HTTPS access to your ServiceNow instance URL on port 443
  • A dedicated MID Server service account in ServiceNow with the mid_server role
  • Network access from the MID Server host to the internal systems it will probe (port 22 for Linux SSH, port 135/445 for Windows WMI, SNMP ports for network devices)
  • Sufficient RAM — minimum 2GB dedicated to the MID Server JVM, 4GB+ recommended for production Discovery

MID Server for outbound REST integrations

Any RESTMessageV2 call can be routed through a MID Server by setting the ECC Target field on the REST Message record to the MID Server name. This is the correct pattern for calling internal APIs — an HR system, a billing platform, an internal database API — that are not accessible from ServiceNow's cloud infrastructure. The flow: ServiceNow creates an ECC Queue record with the REST call details, the MID Server picks it up, executes the HTTP call to the internal system, and returns the response via the ECC Queue.

Related: RESTMessageV2 · Discovery · CMDB · Credential Aliases · HTTP status codes

MID Server high availability

For production Discovery and integrations that cannot afford MID Server downtime, deploy at least two MID Servers in a cluster. ServiceNow distributes work across available MID Servers in the same cluster automatically. If one goes down, the other picks up the work. Cluster configuration is done by assigning both MID Servers to the same MID Server Cluster record in ServiceNow. For Discovery specifically, you can also designate MID Servers for specific IP ranges or network segments — useful when your network has multiple segments that are only accessible from specific vantage points.

MID Server upgrades and maintenance

ServiceNow upgrades MID Servers automatically to stay within one or two major versions of the instance release. The MID Server auto-upgrade runs during the ServiceNow instance upgrade window. To prevent automatic upgrades (for testing or controlled rollout), set the mid.auto_upgrade_all property to false on the instance. After any ServiceNow instance upgrade, verify MID Server status in Discovery > MID Servers — look for the "Up" status and confirm the version is current. A MID Server that fell behind on upgrades may be unable to communicate with a newly upgraded instance.

Troubleshooting MID Server connectivity

The most common MID Server issues: the MID Server process is stopped (check the Windows Service or Linux daemon status), the ServiceNow credentials are expired or locked (the MID Server service account password changed), or a firewall rule was updated and blocked outbound HTTPS. Navigate to Discovery > MID Servers on your instance to see the last contact time — if it is more than a few minutes old, the MID Server is not checking in. Review the MID Server's wrapper.log file (in the agent/logs directory) for connection errors. Firewall issues show as connection refused or timeout errors in the log.

MID Server capacity planning

The right number of MID Servers depends on your Discovery scope and integration volume. For Discovery: each MID Server can typically probe 500–2,000 devices per hour depending on probe type and network latency. For integration: each concurrent integration job consuming the MID Server counts against its thread pool. Start with the minimum (two for HA), monitor the ECC Queue depth and MID Server CPU/memory during peak Discovery windows, and add capacity if queues are backing up or CPU is sustained above 80%. ServiceNow's sizing guidance (available in the product documentation) provides more specific recommendations based on your Discovery scope and infrastructure size.

MID Server Clustering and High Availability

A single MID Server is a single point of failure for every integration and Discovery process that routes through it. Production deployments should run at least two MID Servers per capability cluster, configured with the same application properties and IP range assignments. ServiceNow automatically distributes work across healthy MID Servers in a cluster — if one goes offline, the others handle the load. MID Server clusters are defined by shared worker name assignments and identical application properties. For geographically distributed environments, place MID Servers in each network segment that needs Discovery coverage rather than routing all discovery traffic through a central MID Server, which adds latency and creates a cross-network traffic bottleneck. The Credential Aliases configuration applies at the Connection level, not the MID Server level, so MID Server failover is transparent to credential management.

MID Server Upgrades

MID Servers upgrade independently of the ServiceNow instance. When the instance upgrades to a new release, the MID Server must be upgraded to the matching version within the support window — running a mismatched version causes connectivity warnings and eventually blocks MID Server communication. The auto-upgrade feature handles this automatically: when enabled, the MID Server downloads and applies the upgrade package from the instance during the next maintenance window. The only reason to disable auto-upgrade is if your organisation requires change management approval for MID Server upgrades separately from instance upgrades. In that case, plan MID Server upgrades immediately after each instance upgrade to avoid running outside the supported version window for longer than necessary.

MID Server Security Hardening

The MID Server has significant network privileges — it can connect to both the ServiceNow instance and internal network resources. Treat MID Server hosts as privileged infrastructure. Run the MID Server service as a dedicated low-privilege service account, not as a local administrator or domain admin. Apply OS-level hardening to MID Server hosts (disable unnecessary services, apply security patches promptly, restrict remote access to authorised administrators). Monitor outbound connections from MID Server hosts for anomalous destinations. In environments with strict network segmentation, document the required firewall rules for each MID Server's function (Discovery vs integrations vs JDBC imports) and scope the rules to the minimum required destinations rather than granting broad outbound access. The Credential Aliases framework, used for MID-routed integrations, keeps credentials out of script code, which reduces the impact of MID Server host compromise.

MID Server Capacity Planning

A single MID Server can handle a significant load, but understanding its limits prevents capacity-related failures in production. Each concurrent probe execution during Discovery uses one worker thread on the MID Server host. The default thread configuration handles discovery of a few hundred devices concurrently — adequate for most enterprise environments. For large Discovery deployments scanning thousands of devices on a short interval, or for integrations with very high call volumes, monitor MID Server CPU and memory during peak Discovery windows. If the MID Server host CPU is consistently above 80% during Discovery, either reduce concurrent probe limits in the Discovery schedule, add a second MID Server to share the load, or upgrade the MID Server host's CPU allocation. The MID Server log (located in the MID Server's installation directory) records thread pool utilisation and can be shipped to a log aggregation tool for capacity monitoring.

The complete integrations reference

The NowSpectrum Integrations Guide covers MID Server, REST, OAuth 2.0, IntegrationHub, and 50 interview Q&As.

Get the Integrations Guide →
← Back to all posts