Cron jobs

For example: a nightly cleanup, a report at 6am, a queue worker tick, or php artisan schedule:run.

---

How it works

The panel decides when a job fires. The run itself is tracked by the agent on the server: restarting the panel, upgrading Deplo or losing the dashboard for ten minutes never kills a run in flight. While the panel is down, nothing new starts.

At each occurrence Deplo resolves the target container live, from the Compose service you named, and runs your command in it. It never remembers a container id, so a redeployed app keeps working. With no service named, the job runs in the app's own container: the service its domain routes to.

The command runs in a plain sh -c (or bash -c), with the container's own environment and PATH. No login shell, no profile files.

Each job runs in its own timezone, unlike a backup schedule, which is UTC. A job that says 03:00 Europe/Rome means 03:00 in Rome, in summer and in winter.

---

Turn it on

Cron jobs are opt-in per app and per database, and the switch is also the pause button for everything underneath it.

For a database it is the same, in Settings -> Advanced of that database.

---

Create a job

---

Reading the run history

Six statuses, and the distinctions matter:

Retries share one row, so a job with three attempts is one run with an attempt counter, not three rows. The stored output is the last attempt's final 16 KiB. Run now produces a run marked as manually triggered.

---

See also