cronova FAQ — Frequently Asked Questions¶

Answers to the most common questions about cronova, the lightweight, self-hosted workflow scheduler and open-source Airflow / Azkaban alternative — what it is, how it installs, where it stores data, and how to run it in production.

This page expands on the short FAQ in the README. For task-by-task guides see Getting Started, DAG Reference, CLI Reference, AI Agents (MCP), Deployment, and Architecture.

What is cronova?¶

cronova is an open-source, self-hosted workflow scheduler (a.k.a. job scheduler / DAG orchestrator) written in Go. It schedules DAGs — directed acyclic graphs of tasks — on cron or interval triggers, runs each task as an OS subprocess using the host's own interpreters, and ships a web console, a REST API, a CLI, and an MCP endpoint for AI agents. Managed installs use a static scheduler plus a static standalone executor and embedded SQLite.

Is cronova an Apache Airflow alternative?¶

Yes. cronova is a lightweight alternative to Apache Airflow and Azkaban for teams who want DAG scheduling — dependencies, retries, catchup / backfill, resource pools, a web UI, and a REST API — without running a Python stack, a separate database, and a message broker. It is a compact native service pair with an embedded database. For very large, plugin-heavy data platforms, Airflow remains the richer ecosystem. See cronova vs Airflow for a feature-by-feature breakdown.

Does cronova need a separate database, a JVM, or Python?¶

No. The scheduler and web console use an embedded SQLite database (pure-Go modernc.org/sqlite, CGO-free), so there is no external Postgres/MySQL, no Redis or Celery broker, no JVM, and no Python runtime to install. Managed deployments add only the standalone executor binary. Python, Java, psql, and other interpreters are needed on the host only if your tasks invoke them.

What languages can tasks be written in?¶

Any language on the host. Tasks have a type of shell, python, sql, jar, or http, and a shell task can invoke anything on the machine — Node, Go, Rust binaries, CLIs, and more. The scheduler (Go) is fully decoupled from the task language: each task runs as an OS subprocess with the host's own interpreters. The sql and http task types run in-process (drivers/HTTP client are built into the binary) and need nothing extra installed. See the DAG Reference for every task type.

How is cronova different from cron?¶

Plain cron runs isolated commands on a clock. cronova runs DAGs: tasks with dependencies, retries, timeouts, catchup / backfill, concurrency pools, cross-DAG triggers, a web console with live log tailing, and a REST API — the orchestration you normally end up hand-rolling around a crontab. cronova still speaks cron syntax (schedule: "0 2 * * *") and also supports @every 30s intervals and manual-only DAGs.

Can AI agents control cronova (MCP)?¶

Yes. cronova ships a built-in Model Context Protocol (MCP) server (cronova mcp) that exposes ~30 tools (list_dags, create_dag, validate_dag, trigger_dag, get_task_log, retry_task, …), plus a remote JSON CLI. Agents drive cronova through the same token-authenticated, role-gated API humans use — an agent's reach is exactly its token's role (admin = full CRUD + operate, viewer = read-only), and cronova mcp -read-only exposes only the read tools. Tokens are minted locally with cronova tokens create, never via the API. Full setup: AI Agents (MCP).

Which platforms are supported, and how do I install cronova?¶

cronova runs on Linux and macOS, on both amd64 and arm64. The fastest path is the one-line installer, which downloads the matching prebuilt release, verifies its SHA256, installs the native service (systemd on Linux, launchd on macOS), and runs an interactive setup wizard:

curl -fsSL https://raw.githubusercontent.com/zoyluoblue/cronova/main/deploy/bootstrap.sh | sudo bash

Prefer to build from source? With Go 1.26.5+:

go build -o cronova ./cmd/cronova
./cronova serve                 # console at http://localhost:8090

Prebuilt binaries are on the Releases page. Full deployment guide: Deployment.

What port does the console use?¶

The web console and REST API default to 127.0.0.1:8090 (loopback only). Open http://localhost:8090 after cronova serve. Change it with -http, CRONOVA_HTTP, or the http: key in cronova.yaml. A non-loopback bind with auth disabled is refused unless the explicit dangerous override is set.

How do I upgrade cronova?¶

Run cronova update. It downloads the latest prebuilt release for your OS/arch from GitHub, verifies it against SHA256SUMS, atomically swaps both binaries, preserves customized service definitions, and restarts the scheduler without bouncing an executor that owns in-flight tasks:

cronova update                               # latest release, then restart
cronova update v0.2.1                         # pin or downgrade to a specific tag
cronova update -proxy http://127.0.0.1:7890   # download through a proxy

An unpinned update that is already current is a no-op. A pinned version always applies, so re-install and downgrade both work. update needs root and auto-elevates via sudo — set CRONOVA_NO_SUDO=1 to manage privileges yourself. It does not touch your config, database, or DAGs. Behind a restricted network, -proxy also honors CRONOVA_UPDATE_PROXY, HTTPS_PROXY, and ALL_PROXY. See Deployment → Updating.

Is the update safe if it fails halfway?¶

Yes. update backs up the old binaries and managed service definitions before swapping, then restarts and confirms the scheduler actually stays running (not just that it loaded). If the restart fails, it automatically rolls back and brings the previous version back up. Missing/incomplete SHA256SUMS, a checksum mismatch, an oversized payload, or a downgrade-to-cleartext redirect is fatal. A customized unit/plist is never silently overwritten; the new candidate is written as *.dist.

Is cronova crash-safe / production-ready?¶

cronova is designed for reliable operation. Managed installs use the decoupled gRPC executor by default, so the scheduler can restart or upgrade without killing running jobs — on recovery it re-attaches to in-flight tasks with no double execution. A manual serve with no executor target remains in-process and ends active tasks on exit. Managed services also expose executor-aware readiness, atomic self-updates with rollback, and an audit trail. See Deployment and Architecture for the execution model.

Where does cronova store its data?¶

State lives in an embedded SQLite database plus on-disk DAG YAML, task logs, and uploaded projects. For a cronova serve run from a working directory the defaults are relative: data/cronova.db (DB), dags/ (DAGs), and logs/ (task logs). Uploaded projects default to ~/.cronova/projects. When installed as a native service the paths are absolute:

Purpose	Linux (systemd)	macOS (launchd)
SQLite DB	`/var/lib/cronova/cronova.db`	`/usr/local/var/cronova/cronova.db`
DAG YAML	`/var/lib/cronova/dags/`	`/usr/local/var/cronova/dags/`
task logs	`/var/log/cronova/`	`/usr/local/var/log/cronova/`
config	`/etc/cronova/cronova.yaml`	`/usr/local/etc/cronova/cronova.yaml`
uploaded projects	`/var/lib/cronova/projects/`	`/usr/local/var/cronova/projects/`
attempt workspaces	`/var/lib/cronova/workspaces/`	`/usr/local/var/cronova/workspaces/`

Override these with the matching -db / -dags / -logs / -projects / -workspaces flags, CRONOVA_* environment variables, or cronova.yaml. Full layout table: Deployment → Platform layout.

How long does cronova keep run history?¶

90 days by default. The server automatically deletes finished runs — their database rows and their log directories — once they are older than the retention window (default 2160h, i.e. 90 days). Change it with the retention: key in cronova.yaml, the -retention flag on cronova serve, or the CRONOVA_RETENTION env var; set it to 0 to keep everything forever. Only finished runs age out — in-flight runs are never touched.

Audit records have an independent one-year default (audit_retention: 8760h / CRONOVA_AUDIT_RETENTION / -audit-retention) so shortening run-history retention does not erase the operations trail at the same time.

For a one-off cleanup (or a deployment that runs with retention disabled), use cronova prune:

cronova prune                    # delete finished runs older than 90 days (asks first)
cronova prune -older-than 720h   # custom window
cronova prune -yes               # skip the confirmation prompt (scripts / cron)

Are connection passwords encrypted?¶

Yes. Connection passwords are encrypted at rest with AES-256-GCM. On first start, cronova serve auto-generates an encryption key file — cronova.key, permissions 0600 — in its working directory (for service installs that is next to the DB, see Deployment → Platform layout); point it elsewhere with the key_file: key in cronova.yaml or the CRONOVA_KEY_FILE env var. Back this file up alongside the database — without it, the stored connection passwords are unreadable and must be re-entered. Connections saved before encryption existed (legacy plaintext rows) are upgraded in place automatically on the next server startup. To opt out, set key_file: none — passwords are then stored in plaintext and the server logs a warning at startup.

How do I run cronova behind a reverse proxy?¶

Bind cronova to localhost and terminate TLS at your proxy (nginx, Caddy, Traefik, …). The one-click wizard offers a "this machine only (127.0.0.1)" bind option for exactly this, or set CRONOVA_HTTP=127.0.0.1:8090 (or -http 127.0.0.1:8090). When serving over HTTPS, set CRONOVA_SECURE_COOKIE=true. List non-loopback proxy peers in auth.trusted_proxies or CRONOVA_TRUSTED_PROXIES; X-Forwarded-* from every other source is ignored. The console, REST API, and live-log SSE stream all share the one HTTP listener. See Deployment.

Do I need Docker or Kubernetes?¶

No. cronova is a subprocess scheduler that runs tasks with the host's own interpreters, so it deploys as two small static binaries under systemd (Linux) or launchd (macOS) — no container image to build, no runtime to bundle. Containerizing a polyglot scheduler would force you to bake every task runtime into the image; native services avoid that. If you still containerize the scheduler, keep the standalone executor on the host and point the scheduler at it over the private Unix socket. See Deployment → Why not Docker?.

How do I uninstall cronova?¶

Run cronova uninstall. It stops and removes the native service and the binary but keeps your data (config, DB, DAGs, logs), so a plain uninstall is reversible by re-installing. Add --purge to also delete the data:

cronova uninstall            # remove service + binary, KEEP data
cronova uninstall --purge    # also delete config, DB, DAGs, logs
cronova uninstall -yes       # skip the confirmation prompt (for scripts)

Like other mutating commands, uninstall needs root and auto-elevates via sudo. See Deployment → Uninstalling.

What license is cronova released under?¶

cronova is released under the MIT License — a permissive license that allows commercial and private use, modification, and redistribution.