Recipe: scheduled / cron job

There's no systemd in the guest; the boot hook is /etc/rc.local. Launch your recurring work from there with a sleep-loop, or apt-get install cron for true crontab scheduling. The VM survives reboots because rc.local re-launches it.

Run something on a schedule — a nightly report, a polling sync, a cleanup task. The base VM has no systemd (vm-init is PID 1), so you wire recurring work through the boot hook /etc/rc.local, which runs on every boot.

One prompt

run this script every hour on a small VM

Your agent chains:

1. create_vm (the tiny or small tier is plenty for a periodic job).
2. upload your script to e.g. /root/job.sh.
3. exec to install the boot hook.

Pattern A — sleep loop in rc.local

Simplest, no packages. /etc/rc.local runs under /bin/sh, so keep it POSIX-clean:

#!/bin/sh
# launch the hourly loop in the background so boot continues
( while true; do /root/job.sh >> /var/log/job.log 2>&1; sleep 3600; done ) &

Make it executable (chmod +x /etc/rc.local). On every boot the loop restarts automatically.

Pattern B — real cron

For calendar schedules (0 3 * * *), install cron:

apt-get update && apt-get install -y cron

Add your crontab entry, then ensure cron starts on boot by appending service cron start to /etc/rc.local (there’s no systemd to enable it).

Watch it run

tail the logs on vm-abc123

Your agent calls tail_vm_log (or exec tail -f /var/log/job.log).

Notes

• A periodic job doesn’t need to run 24/7, but remember stopped VMs still bill (VM tiers) — for infrequent jobs, weigh keeping a tiny VM running vs. destroying and recreating.
• One-off “run once then self-destruct” work? Set a ttl on create_vm — the VM hard-deletes when it expires (no graveyard).