This article covers the more technical aspects of Tulip Connector Hosts. This article is intended to be a guide for individuals with a background in Information Technology (IT).

What is the Tulip Connector Host?

Tulip Connectors are designed to allow your Tulip Apps to interface with external systems such as databases, APIs, and machines. Information about our Connectors module can be found in this article: Introduction to Connectors

The Tulip Connector Host is the part of the Tulip platform that creates connections to these external services.

For the Connectors module of Tulip to be used, a Connector Host must be able to establish a connection to the external system that is outbound from the Connector Host and inbound to the external system.

Where does the Tulip Connector Host Software Run?

The first, and most common, deployment option is a Cloud Connector Host. A Cloud Connector Host is included in your Tulip subscription and is deployed alongside the Tulip Platform and is available for use on the “Connectors Page” as “Cloud Connector Host”. 

For cloud customers, this means that connection requests from this Connector Host will come from an IP address in Tulip’s Classless Inter-Domain Routing (CIDR) block. This allows customers to whitelist access from the Tulip Connector Host to their service. For customers running the entire Tulip Platform on-premise, the Connector Host will make requests from the same IP address as the Tulip Platform, which is dependent on your particular deployment configuration.

For more information on Networking Requirements, check out this article.

The second, less common, deployment option is an on-premise Connector Host. In this case, a customer elects to host an on-premise version of the Connector Host within their own networking infrastructure to remove the need to allow incoming connections from Tulip’s CIDR block. Instead, the Connector Host will create an outgoing connection from your network that is inbound to Tulip. This type of deployment is not standard and has many additional requirements such as:

  • An additional subscription cost for the software.

  • Remote access requirements for Tulip to support, maintain, and update the Connector Host.

  • Delays in the deployment of updates including those that may affect security.

  • Delays in support for outages or configuration errors.

  • Additional work for the customer to host and support this software.

Deployment options for on-premise Connector Hosts should be discussed directly between Tulip’s implementation team and your IT department. If you would like to move forward with this option, please contact your Tulip representative for more information.

For more information on the technical specifications for an On-Premise Tulip Connector Host implementation, check out this article.

What ports do I need to open to allow the Cloud Connector Host to access my system?

The network connection between the Connector Host and your external system are entirely managed by you as the end customer. If you have questions, you should reach out to your internal teams. However, the default ports for many common services are listed below for your convenience:


  • PostgreSQL: TCP/5432

  • Microsoft SQL Server: TCP/1433

  • Oracle: TCP/1521


  • HTTP: TCP/80

  • HTTPS: TCP/443

Machine Protocols:

  • OPC UA: TCP/4840

  • Kepware OPC UA: TCP/49320

  • MTConnect: TCP/5000 or TCP/80

What are the security issues of opening access to my DB, API, or OPC UA server to the Tulip Cloud Connector Host?

The recommended way to connect a DB, API, or OPC UA server to Tulip is to allow incoming access from a Tulip Cloud Connector Host. When doing this, it is important to follow security best-practices to ensure continued security.

  • Open your firewall to only Tulip IP addresses (listed here).

  • Encrypt traffic using SSL/TLS encryption using trusted certificate authorities. This addresses many of the common Man in the Middle (MitM) attacks.

  • Use strong authentication schemes for your APIs and DBs. This will be dependent on the type of API or DB, but strong password credentials would be one example of a minimally acceptable solution.

  • Limit access for users within your DBs, APIs, and OPC UA servers. This includes both read-only users and access to various schemas, tables, endpoints, tags, etc.

  • Host your resources on infrastructure that has advanced monitoring to monitor, alert on, and dismiss malicious requests. This addresses many types of DDoS attacks.

Note that these suggestions should be taken as a starting point and that this advice does not replace personalized security planning.

If you have additional questions, please reach out to your Account Manager or to our support team through the Support Request or Live Chat option using the Help button in the top right of the screen.

Did you find what you were looking for?

You can also head to to post your question or see if others have faced a similar question!

Did this answer your question?