--- title: Run Script Setup url: https://www.tines.com/docs/self-hosted/deploying-tines/docker-compose/run-script-setup/ updated: 2026-04-25T14:24:01+00:00 --- *[tines.com](https://www.tines.com/llms.txt) › [Docs](https://www.tines.com/llms.txt) › [Self-Hosted](https://www.tines.com/llm/docs/self-hosted.md) › [Deploying Tines](https://www.tines.com/llm/docs/self-hosted/deploying-tines.md) › [Docker Compose](https://www.tines.com/llm/docs/self-hosted/deploying-tines/docker-compose.md)* # Run Script Setup *[View on tines.com](https://www.tines.com/docs/self-hosted/deploying-tines/docker-compose/run-script-setup/)* We offer the Run Python Script feature for self-hosted customers and for cloud customers using tunnels. For general details on how to use this, please refer to the documentation [here](https://www.tines.com/docs/actions/templates/run-python-script/). ### Overview The self-hosted configuration for this feature requires the configuration of a seperate application called `tines-command-runner`. Details can be found below on configuration. Our Docker based Run Scripts implementation leverages two containers; 1. `tines-command-runner` 2. `pypi-server`([https://github.com/pypiserver/pypiserver)](https://github.com/pypiserver/pypiserver) The `tines-command-runner` is where run scripts will execute. Usage of `pypi-server` is **optional. **The `pypi-server` acts as a local python package index, making the installation of packages efficient and easy to configure as needed. pypi-server can be overridden to use a custom index via environment variables to rely on a different package index. See environment variables [section](/docs/self-hosted/deploying-tines/docker-compose/run-script-setup/#environment-variables) for further details. ### Recommended System Requirements > **INFO:** > - 2 vCPU > - 1.5GB Memory > - 10-20GB disk space > - For heavier workloads you may need to scale up CPU and memory. > - CPU will improve the performance of compute-intensive tasks, memory will allow for more concurrent tasks to run. > - Disk space will need to be scaled based on the size and number of dependencies used, or any storage that your Run Scripts themselves make use of. Note that we pre-package a number of Python dependencies that you can leverage. > - A private network, since the container does not have a built-in authentication system and is meant to be reachable from a Tines tenant only. > - **Note that dependencies may be duplicated on disk across teams, so two different teams that use the same dependencies will still incur additional space for those dependencies.** ### Environment variables You can override certain settings using environment variables. The environment variables have defaults if not populated but can be tweaked if you want to run your own Python Package Index and point to it. - `PIP_INDEX_URL` - Specifies the primary, default Python Package index. Default: `https://pypi.org/simple`. Can be set to a custom index. - `PIP_EXTRA_INDEX_URL` - Allows the customer to specify a fallback Python package index. Default: `pypi-server` , the provided local pypi server - `NO_PIP_INDEX` - Disables any index, even if they are specified by `PIP_INDEX_URL` or `PIP_EXTRA_INDEX_URL`, instead relying entirely on the packages included already in the container. - `UV_NATIVE_TLS` [optional] - When set (e.g. UV_NATIVE_TLS=1), uv uses the platform's native TLS certificate store. This is used to enable corporate proxies or custom CAs in the system store. When not set the variable is not used. By default we specify the extra index as the pypi-server that runs alongside the command runner. - `PIP_EXTRA_INDEX_URL`=http://pypi-server:8080/simple/ - `TRUSTED_HOST`=pypi-server - `LOG_LEVEL` - Configures the logging level for the Python harness. Set to `DEBUG`, `INFO`, `WARNING`, `ERROR`, or `CRITICAL` (defaults to `INFO`). Set `LOG_LEVEL=DEBUG` to enable debug logging for troubleshooting. Logs are written to `/tmp/tcr-logs/harness-{environment_id}-{stdout,stderr}.log`. For timeouts, you can configure: - `RUN_SCRIPT_MAX_TIMEOUT` - This must be set on both tines-app and tines-sidekiq as well. see more information below. ### Pre-Downloaded Python Packages The below common packages are pre-downloaded in the image for efficient access. These packages are available even if `NO_PIP_INDEX=true`. More packages may be added to this list in the future, versions may change as well. ```bash annotated-types anyio beautifulsoup4 boto boto3 click cryptography django fastapi flask grpcio grpcio-reflection grpcio-tools h11 idna jupyter lxml matplotlib networkx nltk numpy openpyxl pandas paramiko plotly protobuf pyarrow pyopenssl pydantic pydantic_core pytest pytz requests scikit-learn scipy seaborn setuptools sniffio sqlalchemy starlette statsmodels sympy typing_extensions uvicorn xlrd ``` **Note:** All transitive dependencies required by the above packages are also automatically downloaded and available for use. This means the actual number of available packages is larger than this explicit list, as each package brings in its own required dependencies during the build process. ### Privilege Escalation The tines-command-runner image generates a unique Linux user for each Tines team using Run Script actions. To ensure each team's scripts are isolated from one another, tines-command-runner uses `sudo` to switch between these users at runtime. If your environment restricts privilege escalation by default, you can explicitly grant only the minimum required Linux capabilities to the container. Required capabilities - `SETUID` - Allows the container to change the effective user ID (required for `sudo` to switch users) - `SETGID` - Allows the container to change the effective group ID (required for `sudo` to switch groups) - `AUDIT_WRITE` - Allows writing to the kernel audit log (required by PAM/sudo for security logging) ### Docker Compose Configuration ##### Step 1. Prepare the docker-compose.yml Here is a docker-compose.yml setup example for tines-command-runner: ```yaml services: tines-command-runner: image: tines/tines-command-runner:latest ports: - "4400:4400" depends_on: - pypi-server networks: - tines-net healthcheck: test: ["CMD", "curl", "-f", "http://localhost:4400/health"] interval: 30s retries: 3 start_period: 10s timeout: 10s restart: always pypi-server: image: pypiserver/pypiserver:latest hostname: pypi-server volumes: - python-packages:/data/packages expose: - "8080" networks: - tines-net command: run -P . -a . /data/packages restart: always volumes: python-packages: networks: tines-net: ``` **CPU & Memory for docker-compose:** We recommend adding these based on your system's configuration to ensure that run scripts don't interfere with other containers on the host, for example, if you want to dedicate 2 of the host's CPU cores and 1GB of memory, try: ```yaml services: tines-command-runner: mem_limit: 1g cpus: '2.0' ``` ##### Step 2. Run the container via Docker compose ```bash docker compose up -d ``` ### Docker Configuration ##### Step 1. Run the container via Docker ```bash docker network create tines-net docker run -d \ --name tines-command-runner \ -p 4400:4400 \ --network tines-net \ --health-cmd "curl -f http://localhost:4400/health" \ --health-interval 30s \ --health-retries 3 \ --health-start-period 10s \ --health-timeout 10s \ --restart always \ tines/tines-command-runner:latest docker run -d \ --name pypi-server \ -v python-packages:/data/packages \ --hostname pypi-server \ --expose 8080 \ --network tines-net \ --restart always \ pypiserver/pypiserver:latest run -P . -a . /data/packages ``` #### Important Considerations for increasing timeout > **WARNING:** > Increasing the timeout requires careful consideration. > > #### 1\. Resource Requirements > > Longer-running scripts need more resources. Scale your configuration accordingly. For example: > > - For a 300-second timeout, allocate at least 4GB memory and 4 CPU cores to the command runner > - Consider increasing the number of command runner containers based on your concurrent script execution needs > - For high concurrency, we recommend at least 2-3 command runner containers > > #### 2\. System Impact > > - Monitor CPU and memory usage > - Consider impact on concurrent script executions > - Scale resources proportionally with timeout increases > - Set up resource utilization alerts