Cronhoster

Scheduled scripts, self-hosted. A folder of crons, mirrored to your own server.

crons/
  digest/                          →  one cron
    cronhoster-cron-handler.js     →    the entry point the server runs
    cronhoster-cron-settings.json  →    when it runs, and how many may overlap
    node_modules/                  →    its own bundled dependencies
  backup/                          →  another cron
    cronhoster-cron-handler.js
    cronhoster-cron-settings.json
  _next/                           →  staged next version (leading _ = local only)

Each directory is one self-contained cron: a handler, a settings file, and whatever it needs.

How it works Get started

How it works

Create and test your crons locally, and when you are ready the local scripts mirror them up to the server, which runs each on its schedule.

A cron is a directory

A directory with a cronhoster-cron-handler.js and a cronhoster-cron-settings.json. The settings name the cron's runs; the handler is what runs. No crontab, no dashboard.

Your own runner

The server reads the clock once a second and runs a cron's handler when its settings match, inside a dedicated Node application, not the box's system cron. Times are UTC.

Named runs, controlled overlap

Each cron lists named runs, each a schedule of month, day, hour, minute and second. A cron runs one handler at a time by default, or up to a maxConcurrent you set.

Self-contained, versioned by rename

Every cron is a complete little world of its own: no common scripts, no shared libraries to reason about across crons.

Everything in one directory

The server runs cronhoster-cron-handler.js; every library, config or vendored module it imports sits right beside it. A cron is uploaded once, whole, and then never re-synced, so there are no shared files to version.

A new version is a new directory

Stage the next version as _<name>; the leading _ keeps it local while you test. Drop the underscore to go live, then remove the old directory. No in-place edits to a running cron.