Dockerised Cronicle, based on the Cronicle-Edge fork of Cronicle. This container was built to include features I value in containers, namely logging to stdout and configurable PUID and PGID.

This container can function in both the manager and worker role.

• 🍵 Gitea Repo (source)
• 🐋 Containers (also published to GHCR)
• 🪞 GitHub mirror
• 📦 Cronicle Repo
• 📦 Cronicle-Edge Repo

This repo is mirrored to GitHub

Cronicle is a multi-server task scheduler and runner, with a web based front-end UI. It handles both scheduled, repeating and on-demand jobs, targeting any number of worker servers, with real-time stats and live log viewer. It's basically a fancy Cron replacement written in Node.js. You can give it simple shell commands, or write Plugins in virtually any language.

• Single or multi-server setup.
• Automated failover to backup servers.
• Auto-discovery of nearby servers.
• Real-time job status with live log viewer.
• Plugins can be written in any language.
• Schedule events in multiple timezones.
• Optionally queue up long-running events.
• Track CPU and memory usage for each job.
• Historical stats with performance graphs.
• Simple JSON messaging system for Plugins.
• Web hooks for external notification systems.
• Simple REST API for scheduling and running events.
• API Keys for authenticating remote apps.

Tags relating to releases are also available, for locking in on a specific version.

config.json, located in /config/cronicle/conf/config.json, is automatically generated on the first run of Cronicle in 'manager' mode. This file must be kept identical between the manager and any workers it controls.

If you want to configure Cronicle before first run (e.g to use a different storage engine), download config_sample.json and adjust accordingly before placing in /config/cronicle/conf/config.json. Make sure to change the secret!

❗ You must define the hostname of the container. Cronicle expects the hostname to remain the same, so the randomly-generated container hostname can cause problems if it changes. ❗

docker run -d --name cronicle \
    --hostname cronicle-manager \
    -p 3012:3012 \
    -e MODE=manager \
    -e PUID=1000 \
    -e PGID=1000 \
    -e TZ=Europe/London \
    -v {path on host}:/config
    git.mrmeeb.stream/mrmeeb/cronicle:latest 

version: '3'
services:
  cronicle:
    container_name: cronicle
    image: git.mrmeeb.stream/mrmeeb/cronicle:latest
    restart: unless-stopped
    hostname: cronicle-manager
    ports:
      - 3012:3012
    volumes:
      - {path on host}:/config
    environment:
      - MODE=manager
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London

This container automatically checks for scripts in /config/init and runs them at startup. This could be useful if you need to install additional applications into a worker container so it can execute jobs.

Note that any scripts will be run as root before permissions are altered in /app and /config. Anything that an init script does in either of these folders will be owned by cronicle when the container continues.

For a single manager behind a reverse proxy, you may need to specify a specific route for the web-socket connections.

An example using nginx:

  location /socket.io/ {
        client_max_body_size                    2048m;
        proxy_read_timeout                      86400s;
        proxy_send_timeout                      86400s;
        proxy_set_header                        X-Forwarded-Host $host;
        proxy_set_header                        X-Forwarded-Server $host;
        proxy_set_header                        X-Real-IP $remote_addr;
        proxy_set_header                        Host $host;
        proxy_set_header                        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version                      1.1;
        proxy_redirect                          off;
        proxy_set_header                        Upgrade $http_upgrade;
        proxy_set_header                        Connection "upgrade"; 

    proxy_pass          http://localhost:3012/socket.io/;
  }

Source: jhuckaby/Cronicle#535

Load-balancing between multiple managers, as described here, has not been tested, and could behave strangely due to docker DNS.