DEPLOYING

Scheduled deployments and cron

Redeploy on a schedule, and run one-off or recurring commands inside a running application.

Two different things run on a clock, and they are worth keeping straight: a scheduled deployment rebuilds and replaces the application, while a cron job runs a command inside the container that is already there.

	Scheduled deployment	Cron job
Does	Rebuilds the image and recreates the containers.	Runs one command inside the running container.
Typical use	Pick up a nightly base-image rebuild; refresh a static site.	Send a digest email, prune a table, run a report.
Permission	`apps:deploy`	`apps:exec`
Interruption	A real deployment — expect the usual container replacement.	None. Nothing restarts.

The permissions differ deliberately. A scheduled deployment is the deploy button on a timer, not a command in a shell — so it answers to the deploy authority, not to the exec one.

Scheduled deployments

Two shapes, on the application’s Schedules tab:

Recurring: A cron expression — 0 3 * * * for every night at three. Fires until you disable it.
One-shot: A single named instant. It disables itself the moment it fires — an armed-looking row that can never fire again is a lie the interface would keep telling.

Missed occurrences are skipped, not caught up. If the panel was down for three nights, it does not wake to three queued redeploys — it does the next one. Waking to a queue of catch-up work is worse than the one run you asked for.

Cron jobs

A cron job is a command, a schedule and nothing else. It runs inside the application’s container, so it sees the same filesystem, the same environment variables and the same project network as your application does:

TEXT

0 3 * * *      php artisan queue:prune
*/15 * * * *   node scripts/sync.js
0 0 * * 0      npm run weekly-report

Resolution is one minute — a schedule finer than that is not expressible, and would not be honoured if it were. Each run records its output, so a job that has been failing silently for a week is visible rather than merely absent.

Same skip-don’t-catch-up rule as above, and the same in-flight guard: a command still running when the next tick arrives is not started a second time.

Cron jobs attach to a single-container application. A Compose stack has several containers and no single obvious place to run a command, so it does not take them — use a dedicated worker application instead.

Previews take them disabled

A preview environment clones its source application’s configuration — but it is created with cron jobs disabled. A preview shares its source’s database, so a copied schedule would run an unreviewed branch’s migration or purge against real data, once per open pull request.

They can be re-enabled on a preview by hand, if that is genuinely what you want.

On several panel replicas

Both schedulers elect a single leader. Every replica holds the timer, but only one fires — otherwise the same nightly redeploy would run once per replica, on the same minute.