Skip to content

Job-Based Containers

A Container Job allows you to run a container image on a scheduled basis — ideal for tasks that need to be executed periodically. Think of it as a lightweight, stateless function that you can trigger every few minutes, hours, or on a custom schedule using cron notation.

Whether you're running a script, generating reports, or syncing data, container jobs provide a simple, automated execution model without managing background workers or dedicated services.

Use Cases

  • Data migration: Schedule a monthly backup job.
  • Report generation: Create daily or weekly reports at a specific time.
  • Data ingestion: Fetch and process data from external sources.
  • Triggering message queues: Start workflows or send system signals.
  • Cleanup tasks: Automate periodic resource cleanup.

Key Characteristics

  • Ephemeral Execution
    Job-based containers run to completion and then stop. They're designed for short-lived tasks such as batch processing or scheduled scripts.

  • Scheduled Runs
    Jobs can be executed on a schedule using cron-like syntax, allowing precise control over when tasks are triggered.

  • No Concurrency
    Jobs do not run concurrently. A new job will wait until the previous execution has fully completed before starting, ensuring data consistency.

  • Persistent Storage
    Mount volumes to store and share data between containers or preserve important files. (See Persistent Storage for details.)

  • Logging via Stdout/Stderr
    Output from job executions is available via standard logging mechanisms — ideal for debugging or monitoring via external tools.

  • Resource-Efficient
    Since containers only consume resources during execution, job-based containers are highly cost-efficient for periodic tasks.

Underlying Technology

  • OCI-Compatible Runtime
    Containers run on an orchestration system built for scale, using industry-standard runtimes behind the scenes.

  • Image-Based Deployments
    Nexaa does not build Docker images. You must host your image in a registry (e.g., Docker Hub, GitLab, GitHub, or your private registry).

  • Environment Variables
    Configuration is injected via environment variables — ideal for secrets, endpoints, and runtime settings.

Cron Notation

Scheduling is handled using cron syntax, which defines when a job should run.

Format:
minute hour day-of-month month day-of-week year
0 12 * * * → Every day at 12:00
*/15 * * * * → Every 15 minutes

Use the five-field version supported by Nexaa: - Minute (0–59) - Hour (0–23) - Day of month (1–31) - Month (1–12 or JAN–DEC) - Day of week (0–6 or SUN–SAT)

Example: Run a script every Monday at 03:00 → 0 3 * * 1

Entrypoint vs CMD

These Docker instructions defined in your dockerfile defines what happens when a container starts:

Directive Purpose
ENTRYPOINT Defines the main executable that always runs in the container.
CMD Provides default arguments or the main command if no ENTRYPOINT is set.

Execution Behavior

  • Startup
    When deployed, your container image is pulled from your registry and started with the provided configuration.

  • Lifecycle Management
    Job-Based Containers are exited and removed automatically when the process for the job is finished.

  • No Concurrency
    Nexaa does not support concurrent runs of the same container job.
    If a scheduled job is still running, the next scheduled run will wait until it completes.
    This avoids overlapping executions, which can lead to corrupted data or resource conflicts.

Best Practices

  • Design for Idempotency
    Ensure your jobs can run multiple times without causing unintended side effects — this is critical for retries or restarts.

  • Keep Jobs Stateless
    Avoid storing state inside the container. Use external databases or persistent volumes for storing data across job runs.

  • Use Clear Exit Codes
    Make sure your container exits with appropriate status codes (0 for success, non-zero for failure) so Nexaa can track job health.

  • Log Meaningfully
    Write structured and readable logs to stdout and stderr for easy integration with external monitoring tools.

  • Handle Failures Gracefully
    Implement retry logic, backoffs, or checkpoints inside your job code to handle errors or partial failures.

  • Optimize Image Size
    Use minimal base images (e.g., Alpine) and multi-stage builds to reduce cold start time and improve performance.

  • Secure Secrets with Env Vars
    Pass sensitive data like API keys or credentials using environment variables instead of hardcoding them in your image.

  • Monitor Execution Time
    Keep job runtimes within expected limits to avoid overruns or timeouts.

  • Keep Jobs Short
    Break down long processes into smaller tasks where possible — shorter jobs reduce resource usage and lower your costs.

  • Use Persistent Volumes When Needed
    For data sharing between jobs or always-on containers, attach a persistent volume instead of writing to the container filesystem.

FAQs

Q: Can I store data inside a container job?
No. Container jobs are stateless. Any files or data created during execution will be lost after the job ends. Use an external database or mount a persistent volume.

Q: How are failures handled?
Jobs that fail will show error logs and exit codes. Retry logic must be implemented internally (e.g., CI/CD, queue system).

Q: How can I monitor execution?
Each job produces logs and exit statuses visible in the UI or via the API.

Q: Can jobs be triggered on demand?
No, Jobs must be scheduled but a workaround is to schedule the job in the near future and disable the job when the execution is done.

References & Additional Resources

What's Next