Context & Probleme description:
In our factory environment, Tulip Player is running on Android tablets deployed in a highly restricted OT network (almost air‑gapped).
Outbound internet access is limited and strictly controlled by domain allow‑listing.
We currently whitelist and trust the following Tulip-controlled domains:
*.tulip.co (including our instance domain)
download.tulip.co
*.tulip-custom-widgets.com
This allows normal Player operation.
However, Tulip Player updates are distributed via Amazon S3 under the shared domain:
s3.amazonaws.com (e.g. https://s3.amazonaws.com/co.tulip.cdn/)
From a security standpoint, it is not reasonable for us (or most industrial IT/OT teams) to whitelist the entire s3.amazonaws.com domain, as it is a multi‑tenant global storage endpoint well outside Tulip’s control.
As a result:
- Player auto‑updates are blocked in our OT network
- Tablets periodically get stuck requiring an update
- Our current workaround is to manually move tablets to a separate “office” network to perform updates, which is operationally painful and error‑prone
Requested Feature / Improvements:
We would like to request an enterprise‑friendly update distribution mechanism that does not require allowing access to s3.amazonaws.com.
Examples of possible solutions (any of these would solve the problem):
-
Host Player update artifacts on a Tulip‑controlled domain
For example:
updates.tulip.coor reusedownload.tulip.co
This would allow customers to safely whitelist a Tulip‑owned domain only. -
Support a configurable update endpoint (advanced / enterprise option)
Allow the Player to be configured with a custom update base URL(via configuration file, environment variable, managed setting…)
This would allow customers to place a reverse proxy under their control in front of Tulip’s S3 backend.