--- title: Run Script (tines-command-runner) url: https://www.tines.com/docs/self-hosted/configuring-tines/run-script-tines-command-runner/ updated: 2026-07-01T18:25:43+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) › [Configuring Tines](https://www.tines.com/llm/docs/self-hosted/configuring-tines.md)* # Run Script (tines-command-runner) *[View on tines.com](https://www.tines.com/docs/self-hosted/configuring-tines/run-script-tines-command-runner/)* This page documents how to configure your tines-command-runner instance using environment variables. For platform-specific deployment instructions, consult our guides to deploying tines-command-runner with [AWS Fargate](https://www.tines.com/docs/run-script-setup/) or [Docker Compose](https://www.tines.com/docs/run-script-setup/). ## Configuring tines-command-runner Tines-command-runner exposes settings for controlling Run Script action execution using environment variables. See the platform-specific pages linked above for more on setting environment variables in tines-command-runner using your platform of choice. ### Basic settings - `LOG_LEVEL` - Configures the logging level for the Python harness. Set to `DEBUG`, `INFO`, `WARNING`, `ERROR`, or `CRITICAL` (default: `INFO`). Set `LOG_LEVEL=DEBUG` to enable verbose debug logging for troubleshooting. Logs are written to `/tmp/tcr-logs/harness-{environment_id}-{stdout,stderr}.log`. ### Package indexes These settings can be changed to use your own, custom index for Python packages. - `PIP_INDEX_URL` - Specifies the primary Python package index used for package resolution and download. Default: `https://pypi.org/simple`. - `PIP_EXTRA_INDEX_URL` - Specifies a fallback Python package index to be used if the primary index is offline or missing a desired package. Default: `http://pypi-server:8080/simple/`, a local pypi server that runs alongside your tines-command-runner container. - `NO_PIP_INDEX` - If set to `true`, blocks access to all package indexes, even if they are specified by `PIP_INDEX_URL` or `PIP_EXTRA_INDEX_URL`, restricting dependencies to those bundled with the Python image (see "Pre-installed packages" below). - `TRUSTED_HOST` - A hostname for a package index that can be accessed via unsecured HTTP when fetching packages. Default: `pypi-server` #### Pre-installed packages The Python packages below are included in our bundled Python image by default. These packages are available even if `NO_PIP_INDEX=true`. More packages may be added to this list in the future, and the installed version of these packages may change. These packages are **not **available by default to user-provided custom runtimes. Custom runtimes are fully self-contained and must bundle all required dependencies. ```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. ### Performance and scaling #### Timeouts - `RUN_SCRIPT_MAX_TIMEOUT` - Controls the maximum runtime of scripts. Scripts running for longer than this number of seconds will be killed, and the task will be marked as a failure. Default: `60` (sixty seconds) > **WARNING:** > Increasing your script timeout has side effects and may not be the most effective solution for managing slow scripts. > > #### 1\. Resource Requirements > > Longer-running scripts typically are operating on larger data, which requires additional resources. Scale your configuration accordingly. For example, for a 300-second timeout, consider allocating at least 4GB memory and 4 CPU cores to tines-command-runner. > > #### 2\. Concurrency > > Long-running tasks occupy a worker as long as they're running, which means other tasks won't be able to run until they finish. If you anticipate needing to run many long-running tasks at once, you'll need to scale up accordingly. Consider increasing the number of tines-command-runner containers based on your concurrent script execution needs, or increasing the number of jobs each container can run in parallel. See the [parallel execution section](https://www.tines.com/docs/self-hosting/additional-applications/run-script-for-self-hosted/#parallel-execution) below for more on increasing concurrency. > > #### 3\. System Impact > > To manage the impact of long-running tasks on your system: > > - Monitor CPU and memory usage in tines-command-runner > - Review if jobs are queueing or otherwise being blocked by long-running executions > - Increase resources and (potentially) parallel execution limits proportionally with timeout increases > - Set up resource utilization alerts to be notified of unexpectedly high utilization > - High memory utilization is especially critical, as exhausting your memory will crash tines-command-runner and cause all running jobs to fail > > #### 4\. Splitting out your workload to avoid timeouts > > If your scripts are consistently running very slowly, rather than increasing your timeout, consider whether your script can be rewritten to handle **many small chunks** of the task it's performing in separate executions rather than performing the full task in a single execution. This can improve reliability and significantly reduce resource consumption. #### Parallel execution By default, each run-script action on a container can run two tasks concurrently before further tasks begin to queue, and a tines-command-runner container can run up to ten concurrent tasks in total before tasks for any environment will begin to queue. You can increase the number of parallel executions by either adding more containers or increasing the parallel execution limit within the container. #### Trade-offs > **INFO:** > #### More containers > > Adding more containers guarantees that your tasks have their own dedicated environment for each action, but every dedicated environment needs its own set of files, which consumes significantly more disk space. > > #### More parallel executions > > Increasing parallel executions on a single container uses more resources on that container, and means that the same container could be processing many expensive tasks at once, which means that you need to add more memory and CPU accordingly, depending on how resource-intensive your tasks are. Many very large tasks running at once can risk consuming all your memory and crashing the container. #### Custom runtimes Actions using custom runtimes often include files that are modified when the script runs. For this reason, by default, custom runtime actions execute **one task at a time**. If your actions don't modify any files, or if you're confident your script handles coordinating access to any files it touches with other tasks, you can safely turn on parallel execution. > **WARNING:** **Parallel executions that don't properly coordinate interacting with files when multiple tasks are running at once can lead to corrupted or deleted files, duplicated operations, or unpredictably incorrect results.** #### Configuration - `TINES_COMMAND_RUNNER_PARALLEL_RUNS` controls the number of tasks a given action can run concurrently. Tasks for that action that are submitted while this many tasks are running will queue until a running task completes. Default: `2` - `TINES_COMMAND_RUNNER_THREADS` controls the total number of tasks the tines-command-runner container can run at once. If more tasks come in while this many tasks are running, runs will begin to queue *regardless of whether the requested action has reached the limit set by* `TINES_COMMAND_RUNNER_PARALLEL_RUNS`. Default: `10` - `TCR_ENABLE_PARALLEL_CUSTOM_ENVIRONMENTS` enables parallel execution for custom runtimes when set to `true`. **Make sure your scripts run safely when running concurrently before enabling this. **When enabled, custom runtimes will be limited to the number of concurrent runs specified in `TINES_COMMAND_RUNNER_PARALLEL_RUNS`. Default: `false`