ETL Advisors | Scheduling Talend Jobs in 2026

Our 2014 tutorials on Windows and Unix deployment still describe how a built Talend job works: a zip with jars and a _run.sh/_run.bat launcher that accepts --context_param arguments. What has changed is everything around it. This is how we deploy and schedule Talend jobs today, in order of how often we recommend each.

1. Build the artifact

In current Talend Studio, right-click the job and choose Build Job. The options that matter:

Build type: Standalone Job produces the familiar zip with a launcher script. Docker image builds a container directly (see section 3). OSGi bundle is for the ESB runtime.
Context: pick the context the build should default to; you will still override values at run time.
Apply to children: include child jobs called through tRunJob.

For anything beyond a one-off, build from the command line so it is reproducible. Talend's Maven-based commandline build (commandline in the Studio distribution, or the CI builder plugin) lets a CI pipeline produce the same artifact from Git on every commit, which is what you want before any of the scheduling options below.

Unzip the standalone build and you get:

my_job_0.1/
  my_job/
    my_job_run.sh
    my_job_run.bat
    lib/            # all jars, including drivers
    contexts/       # Default.properties etc.

Run it directly to confirm it works before scheduling anything:

bash my_job/my_job_run.sh --context=Production --context_param input=standard

Note the double dash on --context_param. Our original tutorials rendered it as an en dash, which is why copied commands failed; that is fixed in the updated posts.

2. Talend Management Console (the default for Talend customers)

If you are on Talend Data Fabric or Qlik Talend Cloud, Talend Management Console (TMC) is the scheduler. It replaced Talend Administration Center (TAC) for cloud and hybrid deployments. The flow:

Publish the job from Studio to the cloud artifact repository (right-click, Publish to Cloud), or push it from CI.
Create a task in TMC: choose the artifact, the environment/workspace, the engine that will run it (a cloud engine, or a remote engine installed inside your network), and the context parameter values. Secrets go into connection parameters rather than the artifact.
Add a trigger: a simple schedule (every N minutes/hours/days), a cron expression, a webhook, or a plan (a DAG of tasks with success/failure branches).
Set run profiles and alerts: JVM options, log level, and who gets notified on failure.

TMC gives you run history, logs, retries, and promotion between environments without any scripting. The documentation is in the TMC user guide. If you still have TAC, migrating its tasks to TMC is usually part of a Qlik Talend Cloud move.

3. Containerize the job and let the platform schedule it

For teams that run everything on Kubernetes or ECS, a Talend job is just another batch container.

Build the image

Talend Studio can build a Docker image directly (Build Job with build type Docker image), but a hand-written Dockerfile over the standalone build is easier to reason about and to scan:

FROM eclipse-temurin:17-jre-jammy

WORKDIR /opt/talend
COPY my_job_0.1/my_job/ ./my_job/
RUN chmod +x ./my_job/my_job_run.sh

# Context values come from the environment at run time, never baked in.
ENTRYPOINT ["bash", "./my_job/my_job_run.sh"]
CMD ["--context=Production"]

Pick the JRE major version your Studio release supports (Talend 8 currently targets Java 17). Build and test locally:

docker build -t my_job:0.1 .
docker run --rm my_job:0.1 --context=Production --context_param input=standard

Pass secrets as environment variables and read them in the job via tContextLoad from System.getenv(), or use --context_param db_password="$DB_PASSWORD" in a wrapper script.

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-job
spec:
  schedule: "0 23 * * *"        # 23:00 daily, cluster time zone
  concurrencyPolicy: Forbid     # never overlap runs
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 1
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: my-job
              image: registry.example.com/my_job:0.1
              args: ["--context=Production", "--context_param", "input=standard"]
              envFrom:
                - secretRef:
                    name: my-job-secrets
              resources:
                requests: { cpu: "500m", memory: "1Gi" }
                limits:   { memory: "2Gi" }

concurrencyPolicy: Forbid is the setting people forget; a slow run overlapping the next schedule is the most common cause of duplicated loads.

AWS ECS scheduled task

Register a task definition with the same image and arguments, then create an EventBridge Scheduler rule (cron or rate expression) whose target is Run ECS task. Logs go to CloudWatch via the awslogs driver. Use a Fargate launch type for batch jobs so you pay only while the job runs.

4. An orchestrator (Airflow or Dagster)

When a Talend job is one step in a pipeline that also runs dbt models, Python, or other tools, scheduling it from the orchestrator keeps dependencies explicit. With Airflow, the simplest reliable pattern is the KubernetesPodOperator or DockerOperator running the container above:

from datetime import datetime
from airflow import DAG
from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator

with DAG(
    dag_id="nightly_customer_load",
    schedule="0 23 * * *",
    start_date=datetime(2026, 1, 1),
    catchup=False,
) as dag:
    load_customers = KubernetesPodOperator(
        task_id="talend_load_customers",
        name="talend-load-customers",
        image="registry.example.com/my_job:0.1",
        arguments=["--context=Production", "--context_param", "input=standard"],
        get_logs=True,
    )

Downstream dbt tasks then depend on load_customers. TMC can also be called from an orchestrator through its API if you want TMC to own execution but Airflow to own the DAG.

5. When plain cron is still fine

It is. A single server, a handful of jobs, no cross-tool dependencies, and someone who checks the logs: cron is simpler than any of the above and has fewer ways to fail.

# m h dom mon dow  command
0 23 * * *  /opt/talend/my_job/my_job_run.sh --context=Production >> /var/log/talend/my_job.log 2>&1

Two upgrades make cron production-grade: wrap the command with flock so runs cannot overlap, and send a failure notification (exit code check in a wrapper script, or a dead-man's-switch monitor that expects a ping after each run). Windows Task Scheduler is the equivalent on Windows and still works exactly as our 2014 tutorial shows.

Choosing

You have	Use
Talend Data Fabric / Qlik Talend Cloud	TMC
A container platform and a platform team	Kubernetes CronJob or ECS scheduled task
Pipelines mixing Talend with dbt/Python	Airflow or Dagster running the container
One server and a few jobs	cron with `flock` and alerting

Whatever you choose, build artifacts from CI, keep secrets out of the artifact, and prevent overlapping runs. Those three rules cause more incidents than the choice of scheduler ever will.

Need help moving off TAC or getting Talend jobs into your container platform? Contact us.