Skip to content

Jobs & CronJobs

Helm-me allows you to declare one-off tasks (Jobs) and scheduled tasks (CronJobs) natively. Instead of long-running deployments, these components spin up, execute a command, and terminate.

Job Components

Jobs are stand-alone pods designed to run to completion once triggered. Unlike Deploy Hooks (which run automatically during helm-me deploy), a job component must be triggered manually using the CLI.

components:
  db-seed:
    type: job
    image: ghcr.io/example/seeder:latest
    command: ["python", "seed.py"]
    # How many retries before failing?
    backoff_limit: 4
    # How long to keep the pod after finishing?
    ttl_seconds_after_finished: 100

from helm_me import App, job, image

class MyApp(App):
    name = "demo"

    db_seed = job(
        image=image("ghcr.io/example/seeder:latest"),
        command=["python", "seed.py"],
        backoff_limit=4,
        ttl_seconds_after_finished=100,
    )

Running Jobs

To manually trigger a Job, use the helm-me job run command, specifying the name of the component:

helm-me job run db-seed

If you want the CLI to block and wait for the job to complete successfully, pass the --wait flag:

helm-me job run db-seed --wait

CronJob Components

CronJobs create Kubernetes CronJob resources which automatically trigger Jobs on a predefined schedule using Cron syntax.

components:
  daily-report:
    type: cronjob
    image: ghcr.io/example/reporter:latest
    schedule: "0 0 * * *"
    command: ["python", "generate_report.py"]

from helm_me import App, cronjob, image

class MyApp(App):
    name = "demo"

    daily_report = cronjob(
        image=image("ghcr.io/example/reporter:latest"),
        schedule="0 0 * * *",
        command=["python", "generate_report.py"],
    )

The schedule must be a valid Kubernetes cron expression (e.g., */5 * * * * for every 5 minutes).

CronJobs are deployed automatically alongside the rest of your app when you run helm-me deploy.

Shared Properties

Like web or worker components, both job and cronjob components support shared options such as:

  • env and secret_refs
  • resources
  • files (inline ConfigMaps)
  • inputs

[!NOTE] Jobs vs. Hooks Use Hooks (hooks: dict) when a task must run as part of the deploy lifecycle (like a database migration before the new code boots). Use Jobs (type: job) when a task is situational, admin-driven, or triggered externally (like manually seeding a staging database or flushing a cache).