Run Script Setup

Last updated July 1, 2026•Open markdown version^↗

We support running Run Script actions on your infrastructure for self-hosted customers and for cloud customers using tunnels. For general details on the Run Script action, refer to the documentation here.

Overview

Run Script actions are executed locally using tines-command-runner.

Our deployment of tines-command-runner includes two containers:

1. tines-command-runner

2. pypi-server(https://github.com/pypiserver/pypiserver)^↗

The tines-command-runner container handles executing scripts.

Usage of pypi-server is optional. The pypi-server acts as a local python package index, making the installation of packages efficient and easily configurable. For details on configuring tines-command-runner, including available environment variables and options for configuring your own custom package index, see our tines-command-runner configuration reference.

Recommended System Requirements

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 when running scripts for a particular team.

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)

Deployment

Step 1. Prepare the tines-command-runner Docker image 

To simplify deployment, we mirror the image from Docker Hub into an ECR repository:

aws --profile test ecr create-repository --repository-name tines-command-runner

# Replace this with the address of the registry output in the previous command:
REGISTRY=306378194054.dkr.ecr.eu-west-1.amazonaws.com

aws ecr get-login-password --region eu-west-1 | \
  docker login --username AWS --password-stdin $REGISTRY

TCR_IMAGE=tines-command-runner:latest

docker pull tines/$TCR_IMAGE
docker tag tines/$TCR_IMAGE $REGISTRY/$TCR_IMAGE
docker push $REGISTRY/$TCR_IMAGE

Step 2. Update the ECS task definitions 

Deploy the tines-command-runner container alongside your existing containers by adding it to the tines-sidekiq task. You can update the JSON payload in the AWS ECS UI by locating the latest task definition and add the following container definition:

{
  "name": "tines-command-runner",
  "image": "$REGISTRY/tines-command-runner:latest",
  "environment": [
    {
      "name": "PORT",
      "value": "4400"
    }
  ],
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "tines",
      "awslogs-region": "$AWS_REGION",
      "awslogs-stream-prefix": "tines"
    }
  },
  "portMappings": [
    {
      "containerPort": 4400
    }
  ]
}

Step 3. Set a new environment variable

You also need to set the following environment variable on the Tines containers : TINES_COMMAND_RUNNER_HOST=localhost. This should be done on your .env file or task definition.

Step 4. Restart the services 

aws ecs update-service --cluster <cluster_name> --service tines-sidekiq --force-new-deployment

Run Script Timeout Configuration

The default timeout for scripts is 60 seconds. In Fargate, you can override this by setting the RUN_SCRIPT_MAX_TIMEOUT environment variable on your .env file or on the tines-sidekiq and tines-app application.

For more information on tuning tines-command-runner for longer timeouts, see our configuration reference.

This should be done on your .env file or in your AWS task definition.

.env file

# Other tines-app env vars
RUN_SCRIPT_MAX_TIMEOUT=90

AWS Fargate (add to the tines-sidekiq task definition):

{
  "environment": [
    {
      "name": "RUN_SCRIPT_MAX_TIMEOUT",
      "value": "90"
    }
  ]
}