Crontab UI

• Find the Crontab UI on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.
• Choose your subscription, resource group and region.
• Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.
• On the Networking tab, allow inbound 443 and 80 from your users, and restrict 22 to your management network.
• Select Review + create. When the VM is running, browse to https://<your-public-ip>/.

Deploy the image from the command line and restrict SSH to your management network. Replace the example values with your own:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:crontab-ui-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name crontab-ui \
  --image sac1647283583153:crontab-ui-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard
# Allow the web UI from your users and SSH from your management network only
az vm open-port --resource-group my-resource-group --name crontab-ui --port 443 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name crontab-uiNSG \
  --name allow-ssh --priority 1002 --destination-port-ranges 22 \
  --source-address-prefixes <your-mgmt-cidr> --access Allow --protocol Tcp

When the VM is running, browse to https://<public-ip>/.

Authentication is on by default. Each VM generates its own admin username and password on first boot and writes them to a root-only file. Read the file over SSH:

ssh azureuser@<vm-ip> 'sudo cat /root/crontab-ui-credentials.txt'

The file contains the CRONTAB_UI_USER, CRONTAB_UI_PASS and CRONTAB_UI_URL for this VM. Keep it secret. The credential lives only in this root-only file and in the service environment file, and is never baked into the image.

Browse to https://<vm-ip>/. The certificate is self-signed per VM, so your browser shows a certificate warning the first time. Accept it to proceed, or install the per-VM certificate, or place a CA-signed certificate in front as described in Step 10. Sign in with the username and password from Step 3.

Crontab UI opens the Cronjobs dashboard. It is a table of every scheduled job with its name, command, schedule and last modified time. A toolbar lets you create jobs, back up, import, export, and write the jobs to the real crontab.

Click New to open the job form. Give the job an optional name and enter the command to run. Set the schedule with a quick preset (Every Minute, Hourly, Daily, Weekly and so on), or enter the minute, hour, day, month and week of month fields directly. The Job preview at the bottom shows the exact crontab line that will be written.

Autosave is enabled on this image, so saving a job writes it straight to the crontabui user's real crontab. You do not need to click Save to crontab. Use that button only if you prefer to apply a batch of changes at once.

Each row in the dashboard has controls to Edit the job, Run now (run it immediately), Disable (pause it without deleting it), Duplicate and delete. Edit reopens the job form pre-filled with the job's current name, command and schedule.

Tick Enable error logging to have Crontab UI capture each run's standard output and error to per-job log files. You can view them from the dashboard to see why a job failed.

Click Preview crontab at any time to see exactly what Crontab UI will deploy to the system crontab, including the logging wrappers it adds around each command. This is the real crontab content for the crontabui service account.

You can confirm the same content from the shell. On the VM, list the crontabui user's crontab:

sudo crontab -u crontabui -l 2>/dev/null | head -20 || echo "(no jobs scheduled yet — add one in the web UI)"

SSH to the VM as azureuser and confirm that the services are running and Crontab UI is bound to loopback only:

systemctl is-active crontab-ui nginx cron
sudo ss -tlnp | grep -E ':8000|:443 |:80 ' | sed 's/users:.*//'

All three services report active, and Crontab UI listens on 127.0.0.1:8000 only. nginx is the only component exposed on :80 and :443.

Run the built-in self-test. It reads this VM's credential and proves the full round trip over TLS. An unauthenticated request is refused, an authenticated request succeeds, and a cron job is created through the API, written to the crontabui user's real crontab, then removed:

sudo /usr/local/bin/crontab-ui-selftest

nginx terminates TLS on port 443 and redirects plain HTTP on port 80 to HTTPS. Confirm the redirect, confirm that an unauthenticated request is refused, and confirm that a request carrying this VM's credential succeeds:

curl -s -o /dev/null -w 'port 80 -> HTTP %{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'unauthenticated -> HTTP %{http_code}\n' https://127.0.0.1/
U=$(sudo grep '^CRONTAB_UI_USER=' /root/crontab-ui-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^CRONTAB_UI_PASS=' /root/crontab-ui-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'authenticated -> HTTP %{http_code}\n' -u "$U:$P" https://127.0.0.1/

Port 80 returns 301, an unauthenticated request returns 401, and a request with this VM's credential returns 200. The self-signed certificate is regenerated per VM on first boot, with the VM IP and hostname in its Subject Alternative Names.

The pinned version and this VM's credential summary are recorded on the VM. The command below redacts the password line. Read the full value from the root-only file in Step 3:

cat /opt/crontab-ui/VERSION
sudo sed 's/^CRONTAB_UI_PASS=.*/CRONTAB_UI_PASS=<redacted per-VM secret>/' /root/crontab-ui-credentials.txt | grep -E '^CRONTAB_UI_'

The per-VM certificate is self-signed, so browsers warn on first use. For a public deployment, put a real certificate in front. The simplest approach is to point a DNS name at the VM and obtain a free certificate with Certbot:

# Point https://<your-domain> at this VM first, then:
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Alternatively, terminate TLS at an Azure Application Gateway or a load balancer in front of the VM, and forward to port 443.

• Back up and restore. Use the Backup button in the toolbar to snapshot your jobs, and the Backups menu to restore a previous snapshot, so a mistaken edit is never final. Export downloads the job database and Import uploads it, which is handy for moving jobs between servers.
• Import an existing crontab. If you already have jobs in the crontabui user's crontab, click Get from crontab to import them into the interface.
• Review the managed crontab. By default Crontab UI manages the crontab of the unprivileged crontabui service account, which is the least-privilege default. The service definition is at /etc/systemd/system/crontab-ui.service. Its environment (bind address, autosave, database path and the per-VM credential) is in /etc/crontab-ui/crontab-ui.env.
• Rotate the credential. Edit BASIC_AUTH_USER and BASIC_AUTH_PWD in /etc/crontab-ui/crontab-ui.env and restart the service. Alternatively, place your own identity-aware proxy in front.

• Find the Crontab UI listing in AWS Marketplace. Choose Continue to Subscribe, then Continue to Configuration, then Continue to Launch.
• Select the Ubuntu 24.04 delivery option, your region, an instance type (m5.large or larger) and your EC2 key pair.
• In the security group, allow inbound 443 from your users and restrict 22 to your management network.
• Launch the instance. When it is running, browse to https://<instance-public-ip>/.

Launch the image from the command line and restrict access with a security group of your own. Replace the example values with your own:

aws ec2 run-instances \
  --image-id <ami-id-from-listing> \
  --instance-type m5.large \
  --key-name my-key \
  --security-group-ids sg-yourgroup \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=crontab-ui}]'

When the instance is running, get its public IP and browse to https://<instance-public-ip>/.

Authentication is on by default. Each instance generates its own admin username and password on first boot and writes them to a root-only file. Read the file over SSH:

ssh ubuntu@<public-ip> 'sudo cat /root/crontab-ui-credentials.txt'

The file contains the CRONTAB_UI_USER, CRONTAB_UI_PASS and CRONTAB_UI_URL for this instance. Keep it secret. The credential lives only in this root-only file and in the service environment file, and is never baked into the image.

Browse to https://<instance-public-ip>/. The certificate is self-signed per instance, so your browser shows a certificate warning the first time. Accept it to proceed, or place a CA-signed certificate in front as described in Step 10. Sign in with the username and password from Step 3.

Crontab UI opens the Cronjobs dashboard. It is a table of every scheduled job with its name, command, schedule and last modified time. A toolbar lets you create jobs, back up, import, export, preview, and write the jobs to the real crontab.

Click New to open the job form. Give the job an optional name and enter the command to run. Set the schedule with a quick preset (Every Minute, Every 5 Min, Hourly, Daily, Weekly and so on), or enter the minute, hour, day, month and week fields directly. The Job preview shows the exact crontab line that will be written.

Autosave is enabled on this image, so saving a job writes it straight to the crontabui user's real crontab. You do not need to click Save to crontab. Use that button only if you prefer to apply a batch of changes at once.

Each row in the dashboard has controls to Edit the job, Run now (run it immediately), Disable (pause it without deleting it), Duplicate and delete. Edit reopens the job form pre-filled with the job's current name, command and schedule.

Tick Enable error logging to have Crontab UI capture each run's standard output and error to per-job log files. You can view them from the dashboard to see why a job failed.

Click Preview crontab at any time to see exactly what Crontab UI will deploy to the system crontab, including the logging wrappers it adds around each command. This is the real crontab content for the crontabui service account.

You can confirm the same content from the shell. On the instance, list the crontabui user's crontab:

sudo crontab -u crontabui -l 2>/dev/null | head -20 || echo "(no jobs scheduled yet - add one in the web UI)"

Confirm that the services are running and Crontab UI is bound to loopback only:

systemctl is-active crontab-ui nginx cron
sudo ss -tlnp | grep -E ':8000|:443 |:80 ' | sed 's/users:.*//'

All three services report active, and Crontab UI listens on 127.0.0.1:8000 only. nginx is the only component exposed on :80 and :443.

Run the built-in self-test. It reads this instance's credential and proves the full round trip over TLS. An unauthenticated request is refused, an authenticated request succeeds, and a cron job is created through the API, written to the crontabui user's real crontab, then removed:

sudo /usr/local/bin/crontab-ui-selftest

nginx terminates TLS on port 443 and redirects plain HTTP on port 80 to HTTPS. Confirm the redirect, confirm that an unauthenticated request is refused, and confirm that a request carrying this instance's credential succeeds:

curl -s -o /dev/null -w 'port 80 -> HTTP %{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'unauthenticated -> HTTP %{http_code}\n' https://127.0.0.1/
U=$(sudo grep '^CRONTAB_UI_USER=' /root/crontab-ui-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^CRONTAB_UI_PASS=' /root/crontab-ui-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'authenticated -> HTTP %{http_code}\n' -u "$U:$P" https://127.0.0.1/

Port 80 returns 301, an unauthenticated request returns 401, and a request with this instance's credential returns 200. The self-signed certificate is regenerated per instance on first boot, with the instance public IP and hostname in its Subject Alternative Names.

The pinned version and this instance's credential summary are recorded on the instance. The command below redacts the password line. Read the full value from the root-only file in Step 3:

cat /opt/crontab-ui/VERSION
sudo sed 's/^CRONTAB_UI_PASS=.*/CRONTAB_UI_PASS=<redacted per-instance secret>/' /root/crontab-ui-credentials.txt | grep -E '^CRONTAB_UI_'

The per-instance certificate is self-signed, so browsers warn on first use. For a public deployment, put a real certificate in front. The simplest approach is to point a DNS name at the instance and obtain a free certificate with Certbot. Run these commands on the instance after your domain resolves to it:

# Point https://your-domain at this instance first, then:
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain

Alternatively, terminate TLS at an AWS Application Load Balancer or CloudFront in front of the instance, and forward to port 443.

• Back up and restore. Use the Backup button in the toolbar to snapshot your jobs, and the Backups menu to restore a previous snapshot, so a mistaken edit is never final. Export downloads the job database and Import uploads it, which is handy for moving jobs between servers.
• Import an existing crontab. If you already have jobs in the crontabui user's crontab, click Get from crontab to import them into the interface.
• Review the managed crontab. By default Crontab UI manages the crontab of the unprivileged crontabui service account, which is the least-privilege default. The service definition is at /etc/systemd/system/crontab-ui.service. Its environment (bind address, autosave, database path and the per-instance credential) is in /etc/crontab-ui/crontab-ui.env.
• Rotate the credential. Edit BASIC_AUTH_USER and BASIC_AUTH_PWD in /etc/crontab-ui/crontab-ui.env and restart the service. Alternatively, place your own identity-aware proxy in front.