Overview
Not every system your team needs to automate lives in the cloud. Whether it's an on-prem active directory server, an internal ticketing system, or a legacy API behind a firewall, the reality for most organizations is a hybrid landscape.
The good news: you don't need to self-host Tines to reach those resources. A handful of lightweight containers, deployed in your network, bridge the gap.
The building blocks
These three container types cover every on-prem connectivity scenario:
Tines Tunnel
Tines Command Runner (TCR)
Command-over-HTTP (CoHTTP)
Tines Tunnel
This enables HTTP Request actions to reach private services. No inbound firewall rules required. You only need to deploy a single container inside your network.
Best used for
Tines tunnel is best used for connecting to on-prem HTTP APIs such as Jira Server, GitLab or internal REST services.
Key benefits
Tines Tunnel is a secure, outbound-only connection from your network to Tines via Cloudflare Tunnels. It is secure as there is no need for a VPN and there aren’t any exposed ports.
Minimum requirements
1 vCPU, 1 GB RAM. For HA, run a second instance on a separate host with the same secret.
Read this article on deploying and using the Tines Tunnel.
Tines Command Runner (TCR)
TCR powers the Run Script action on your infrastructure. It runs Python with access to packages like `requests`, `pandas`, `cryptography`, and `boto3`. Adding libraries is straightforward, just point TCR at a public or local PyPI server and install what you need.
Best used for
Use TCR for complex transforms, custom enrichment, SDK integrations, or anything that goes beyond Tines formulas. You can also combine TCR with the Tines tunnel: the tunnel handles HTTP Request actions to internal services; TCR handles Run Script actions.
Key benefits
TCR executes Python in isolated, per-team sandboxes with 60+ pre-installed packages. It pairs with an optional local PyPI server for air-gapped environments.
Minimum requirements
2 CPUs, 2 GB RAM recommended. Optional `pypi-server` for local package caching.
Command-over-HTTP (CoHTTP)
Executes Python, Bash, and PowerShell on your private network. Built for systems without HTTP interfaces, with native Kerberos authentication for Active Directory and Exchange.
Best used for
Automating active directory user management, Exchange mailbox provisioning, or domain controller queries. In your workflow, target `https://command-over-http/run` with a JSON payload specifying the executor and script, and select a tunnel on the action to route the request into your network.
Note: CoHTTP's library set is fixed — if you need custom Python dependencies, TCR is the better fit.
Key benefit
CoHTTP is purpose-built for systems without HTTP APIs. CoHTTP accepts script payloads and executes them using Python, Bash, or PowerShell — with Kerberos authentication out of the box.
Minimum requirements
1 vCPU, 1 GB RAM.
The deployment matrix
The following matrix summarizes each of the 3 building blocks listed above.
Pattern | Containers | Best for | Key benefit |
Tunnel | Tines tunnel | On-prem HTTP APIs (Jira Server, GitLab, internal REST services) | Secure, zero-inbound connectivity |
TCR | `tines-command-runner` + `pypi-server` | Python scripting (data transforms, enrichment, custom logic) | 60+ packages; isolated per-team execution |
CoHTTP | command-over-http | Active Directory, Exchange, PowerShell/Bash | Native Kerberos auth; no HTTP interface needed |
Use these links to learn more about the optimal way to connect Tines to your on-premise resources: