Administration
Schedules, cron, mounts, and SFTP
Forge has application-side and node-side scheduling; it does not require an operator crontab entry for its normal scheduler.
#Cron truth
Forge API’s cron job service creates a robfig/cron scheduler with seconds enabled. On service start it loads enabled cron jobs from the store. A job is executed with sh -c inside the API process, and executions are recorded. Failed jobs retry when RetryCount is configured, with increasing 5-second delays. The service exposes a manual trigger path in its implementation.
The inspected service has no distributed lock or explicit missed-run catch-up policy. Avoid long-running overlapping shell jobs and test schedules after API restarts.
#No host crontab required
Do not add a crontab entry just to make Forge schedules run. Docker restart policies bring the API back; the API starts its scheduler. Beacon also starts its own scheduler for node-side tasks. The repository ships no systemd timer.
#Mounts and files
Mounts join a host directory to a workload container. Use explicit, restricted host paths; select read-only whenever writes are unnecessary. A mount must exist consistently on every destination node before migration. Browser file operations and SFTP access act on node-owned workload data, while host-file and terminal features are privileged administration tools.
#SFTP
Beacon starts SFTP from DAEMON_SFTP_ADDR and can use DAEMON_SFTP_BIND_ADDR for the low-level bind. Standalone Beacon uses host networking, so a broad bind can expose SFTP on the host. Keep it loopback-only or apply narrow firewall/proxy policy.