Cronicle Job Scheduler on Ubuntu 24.04 on Azure User Guide
Overview
Cronicle is a simple, distributed job scheduler and cron replacement with a polished web UI. Define scheduled events once, then run shell scripts, HTTP requests or custom plugins across your fleet of servers, watch live progress and logs straight from the browser, and chain jobs together with dependencies and alerting. Install the cloudimg image and you have a ready to use scheduler with a clean web UI. The image installs Cronicle 0.9.122 from the official pinned installer and runs it as the dedicated cronicle system service on Node.js 22. The web UI is bound to the loopback address 127.0.0.1:3012, and nginx on port 80 reverse proxies to it plus an unauthenticated health endpoint. The embedded flat file storage that holds your jobs, schedule and users, along with logs and the job queue, lives on a dedicated Azure data disk. A unique admin password is generated on the first boot of every VM, so a fresh VM never ships the default admin/admin login. Backed by 24/7 cloudimg support.
What is included:
- Cronicle 0.9.122 installed via the official pinned installer and run as the
croniclesystem service on Node.js 22 LTS - The built in embedded flat file Storage engine (no external database required), with your schedule, job history and users on a dedicated Azure data disk at
/var/lib/cronicle - Cronicle bound to
127.0.0.1:3012, fronted by nginx on port 80 (including the live-log websocket) - Port 80 serving an unauthenticated
/healthzendpoint for load balancer probes - A unique
adminpassword generated on first boot and written to a root only file, so no shared or default admin ships in the image - A fresh per-VM session-signing secret generated on first boot (never a shared, image-baked secret)
- Three ready to use plugins out of the box: Shell Script, HTTP Request and a Test Plugin
cronicle.serviceandnginx.serviceas system services, enabled and active- 24/7 cloudimg support
Prerequisites
An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a reasonable starting point; size up if you plan to run many concurrent jobs. NSG inbound: allow 22/tcp from your management network and 80/tcp (and 443/tcp if you add TLS) for the web UI. The web UI is served over plain HTTP by default, so for production put your own domain and a trusted certificate in front of it (see Maintenance).
Step 1 - Deploy from the Azure Marketplace
Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Cronicle by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create and Create.
Step 2 - Deploy from the Azure CLI
az vm create \
--resource-group <your-rg> \
--name cronicle \
--image <marketplace-image-urn> \
--size Standard_B2s \
--admin-username azureuser \
--ssh-key-values ~/.ssh/id_ed25519.pub \
--vnet-name <your-vnet> --subnet <your-subnet> \
--public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name cronicle --port 80 --priority 1010
Step 3 - Connect to your VM
ssh azureuser@<vm-public-ip>
Step 4 - Confirm the services are running
systemctl is-active cronicle.service nginx.service
ss -tlnp | grep -E '3012|:80 '
Both services report active. Cronicle listens only on the loopback address 127.0.0.1:3012, and nginx on port 80 reverse proxies to it. The application connector is never exposed directly on a public interface.

Step 5 - Retrieve your admin password
The Cronicle admin password is generated uniquely on the first boot of your VM and written to a root only file:
sudo cat /root/cronicle-credentials.txt
This file contains CRONICLE_USERNAME (admin), CRONICLE_PASSWORD and the web UI URL. Store the password somewhere safe. The file is mode 0600 and owned by root, so only an administrator can read it. The embedded Storage that holds your schedule, job history and users lives on the dedicated Azure data disk mounted at /var/lib/cronicle.

Step 6 - Confirm the health endpoints
nginx serves an unauthenticated health endpoint for load balancers and probes, and fronts the Cronicle app shell:
curl -s http://localhost/healthz
curl -s -o /dev/null -w 'healthz HTTP %{http_code}\n' http://localhost/healthz
curl -s -o /dev/null -w 'root HTTP %{http_code}\n' http://localhost/
/healthz returns ok with HTTP 200 and never requires authentication, so it is safe for an Azure Load Balancer health probe. The root path returns HTTP 200, which confirms Cronicle is up behind nginx and ready to sign in to.

Step 7 - Verify authentication from the command line
Cronicle's login API is a plain JSON POST to /api/user/login. It always returns HTTP 200 - success or failure is carried in the JSON body's code field (0 on success, plus a session_id). The check below signs in with the correct per VM password and, for contrast, with the default admin password and a wrong password (both rejected). Because the command embeds your unique password, run it interactively rather than from a script; substitute the value of CRONICLE_PASSWORD from Step 5 for <CRONICLE_PASSWORD>:
login() {
curl -s -H 'Content-Type: application/json' \
-d "{\"username\":\"admin\",\"password\":\"$1\"}" \
http://localhost/api/user/login \
| python3 -c 'import json,sys; d=json.load(sys.stdin); print("code=%s session=%s" % (d.get("code"), bool(d.get("session_id"))))'
}
echo "per-VM password -> $(login '<CRONICLE_PASSWORD>')"
echo "default admin -> $(login 'admin')"
echo "wrong password -> $(login 'wrong')"
The correct per VM password prints code=0 session=True (signed in). The default admin password and a wrong password both print code=login session=False, proving the appliance rotated the default login away on first boot.

Step 8 - Sign in to the web UI
Browse to http://<vm-public-ip>/. You land on the Cronicle User Login page. Enter admin as the username and the password from Step 5, then select Login.

Step 9 - Explore the Home dashboard
After signing in you land on the Home tab. It shows server stats (total events, categories and plugins), a live list of active jobs, and any upcoming scheduled events. From here you can jump straight to the Schedule tab to manage events.

Step 10 - Create a scheduled event
Select the Schedule tab, then Add Event.... Give the event a title, choose a Category (the image ships a ready made General category), a Target (which server or group to run on) and a Plugin - the image ships Shell Script, HTTP Request and a Test Plugin out of the box. Set a schedule (or leave it disabled and run it on demand), then select Create Event. The screenshot below shows a new Hello World event using the built in Test Plugin.

Step 11 - Run a job and watch the live log
From the Schedule tab, select Run next to your event to launch it immediately, then select the Running status badge to jump to its live Job Details page. Cronicle streams job progress, CPU and memory usage, and the live log in real time over a websocket, so you can watch exactly what a job is doing while it runs. When it finishes the job moves to the Completed tab with its full log retained.

Step 12 - Confirm data lives on the dedicated disk
Cronicle's data, the embedded Storage that holds your schedule, job history and users, along with logs and the job queue, is stored under /var/lib/cronicle on the dedicated Azure data disk, so it survives OS changes and can be resized independently:
findmnt /var/lib/cronicle
The mount is backed by a separate Azure data disk captured into the image and re provisioned on every VM.
Maintenance
- Password: the admin password is set on first boot via Cronicle's own storage CLI. To rotate it again later, run
sudo /opt/cronicle/bin/control.sh admin admin '<new-password>'whilecronicle.serviceis stopped (sudo systemctl stop cronicle.service), then start it again (sudo systemctl start cronicle.service). - Serve a real domain and TLS: the appliance serves the web UI over plain HTTP on port 80. For production, point a DNS name at the VM, obtain a trusted certificate (for example with certbot / Let's Encrypt), and front Cronicle with nginx TLS on port 443. Then set
base_app_urlin/opt/cronicle/conf/config.jsonto yourhttps://URL so the links Cronicle generates are correct, and restart the service. - Plugins: Cronicle ships Shell Script, HTTP Request and a Test Plugin. Add your own custom plugins (any executable that speaks Cronicle's simple JSON-over-stdio protocol) from the Admin tab.
- Users and access control: add teammates and set per-privilege access (create/edit/delete/run events, abort jobs, toggle the scheduler) from the Admin tab.
- Multi-server clusters: a single Cronicle server is a complete "Primary Group" master out of the box. To add worker servers, install Cronicle on additional VMs, point them at the same Storage backend, and add them under Admin -> Server Groups.
- Storage and backup: all Cronicle state lives under
/var/lib/cronicleon the data disk; back up that volume to protect your schedule, job history and users. - Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.
Support
cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.