Commands
Two surfaces: the client CLI you run on your own machine to sync your folder, and the service commands you run on the server to manage the API and the runner. The client is the one you touch daily; the server commands are for setup and the occasional check-in.
node client/sync.js — the sync client
Reads your config.json, compares your
cron folder with the server, and uploads what changed. Every invocation
needs --config; the rest are optional.
node client/sync.js --config config.json --watch| Flag | Meaning |
|---|---|
--config <path> | Path to the JSON config holding
apiBase, apiToken and contentRoot. Required. |
--watch | Stay resident and re-sync whenever a file in the content root changes. The natural mode while authoring. |
--interval <dur> | Instead of watching, re-sync on a fixed timer
(e.g. 30s, 5m). Useful under a supervisor that expects a long-running
process but where filesystem events are unreliable. |
--dry-run | Show exactly what would upload — new, changed and ignored paths — and exit without touching the server. |
--verbose | Log every path considered and the sync decision for it, plus
the commit handshake. Pair with --dry-run to debug ignore rules. |
--pull-logs | After syncing, mirror the server's per-run logs
(stdout/stderr, start/stop/duration/exit-code) back into your content root
so you can read how each job behaved. |
A plain
--config run does a single sync and exits. Add
--watch or --interval to keep it running. See
Usage → Client for the workflow these flags support.Server-side services
The installer lays down two systemd units. Manage them with ordinary
systemctl; they run as a dedicated non-root user.
# is the sync API healthy?
systemctl status cronhoster-api
# is the scheduler running your jobs?
systemctl status cronhoster-runner
# restart after an upgrade or a config change
sudo systemctl restart cronhoster-runner| Command | Purpose |
|---|---|
systemctl status cronhoster-api | Health of the localhost sync API that the client uploads to. |
systemctl status cronhoster-runner | Health of the scheduler that discovers entry points and runs them on time. |
systemctl restart cronhoster-api | Restart the sync API — e.g. after the token or Caddy config changes. |
systemctl restart cronhoster-runner | Restart the scheduler. In-flight runs stop; missed ticks are skipped, not backfilled. |
journalctl -u cronhoster-runner | The service's own logs — scheduling
decisions, promotions, per-run start/stop. Per-job stdout/stderr is
captured under the server's log directory and mirrored back with --pull-logs. |
Run logs are written server-side under the content root's log area and pulled to your machine with --pull-logs; retention is one of the open logging questions.