Game servers & data
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.
#Schedules have three actions
Legacy server schedules support exactly three task actions: power (start, stop, restart — suspension-aware), backup (creates a Beacon backup), and command (sends a console command with a 30-second budget). Tasks run sequentially with leases, continue-on-failure gates, and per-task run records.
#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 serves SFTP on :2022 by default with an ed25519 host key, strict ciphers, and idle, lifetime, and connection limits. Panel usernames take the form user.server-id, and every login is verified against the panel — including per-session authorization, quotas, and read-only mode. Keep the bind loopback-only or apply narrow firewall policy.