xyOps: a self-hosted scheduler that watches the machines it runs on

What xyOps adds to a plain crontab

A crontab entry knows when to start a command. It does not know whether the host has enough memory, whether the previous run is still going, or what the machine looked like when the command failed. xyOps is built around that gap. The README states the premise directly: your job scheduler should know what your servers are doing.

The target audience is operations teams running more than a handful of machines. The README lists what the platform covers: launching scripts and plugins on one server, a server group, or an entire fleet; recurring schedules, cron expressions, intervals, webhooks, priorities, queues and resource limits; visual workflows with branching, parallel execution, joins, human approval, reusable sub-workflows, replay and data passing; live dashboards, custom metrics, process inspection and network connections; and alert handling that can capture a server snapshot, open a ticket, call a webhook or block an unsafe launch.

That is a wide scope for one application, and it is the central design decision to evaluate. xyOps is not a thin cron wrapper with a web UI. It is closer to a small operations platform where the scheduler, the monitoring agent and the incident record share a data model. Whether that is a benefit or a liability depends on how many separate tools you are currently reconciling by hand.

Conductor, workers and the xySat agent model

The architecture visible in the repository is a central server plus distributed execution. The README calls the central node a conductor and the execution nodes workers. The trial command sets XYOPS_masters to the hostname of the conductor and XYOPS_xysat_local to true, which starts a local worker inside the same container. In a real deployment those are separate hosts.

The worker side runs through xySat, described in the README as lightweight workers with no Node.js requirement. That matters for heterogeneous fleets: a worker does not need the Node.js runtime that the conductor itself depends on, so you can attach machines that you would rather not install a JavaScript stack onto.

State lives outside the application process. The dependency list in package.json includes ioredis and pg, so the conductor talks to Redis and PostgreSQL. Jobs, logs, metrics, secrets, files, tickets, snapshots and configuration stay inside your infrastructure, and the README states that xyOps does not send product telemetry to PixlCore or any other telemetry service. The practical consequence is that a production deployment is three moving parts, not one: the conductor, Redis and PostgreSQL. That is a real operational commitment, and it is the first thing to weigh against a single-binary scheduler.

Trying xyOps in Docker on port 5522

The README gives a one-command trial. It starts a disposable conductor with a local worker, publishes port 5522, and mounts nothing, so the container holds all of its state.

docker run --detach --rm --init \
	--name xyops-try \
	--hostname xyops-try \
	-e XYOPS_masters="xyops-try" \
	-e XYOPS_xysat_local="true" \
	-e XYOPS_base_app_url="http://localhost:5522" \
	-e TZ="America/Los_Angeles" \
	-p 5522:5522 \
	ghcr.io/pixlcore/xyops:latest

After the container starts, open http://localhost:5522/ and sign in with the username admin and the password admin. The README notes that the trial is intentionally disposable: docker stop xyops-try removes the container and its data. Change TZ if you want a different timezone for the trial.

For anything persistent, the README points to the Self-Hosting Guide at docs.xyops.io/hosting rather than describing the production install in the README itself. If you are evaluating rather than deploying, the trial is the fastest way to see the workflow editor and the monitoring dashboards with real data flowing through them. Do not treat credentials of admin/admin as anything other than a disposable sandbox.

Alert snapshots and the two-click claim

The feature the README leads with is alert context. When an alert fires, xyOps can freeze the relevant server state at that moment: metrics, processes, network connections, active jobs and alert data. Opening the alert and then opening its snapshot gives you the evidence the README describes as already waiting for you.

This is the part that is genuinely different from bolting a monitoring agent onto a scheduler. In a typical stack, the scheduler writes logs to one system, the metrics agent samples to another, and the alert goes to a third. Reconstructing what happened at 03:14 means correlating three timelines by timestamp. xyOps captures them together at the moment of the event.

The limitation is the word can. The README describes the capability, and the snapshot is only as useful as the metrics and process data the worker was already collecting. If you have not configured custom metrics or the worker has no visibility into a process, the snapshot will be thin. The README does not document snapshot retention limits or size bounds, so capacity planning for snapshot storage is something to check in the documentation before you rely on it as your incident record.

Migrating from Cronicle, and what compatibility does not cover

xyOps is written by the creator of Cronicle and is positioned as its next generation. The README lists what existing Cronicle users can do: import Cronicle data through the xyOps interface, keep compatible plugins and familiar scheduling concepts, convert multiplexed events into visual workflows, run jobs through xySat workers, and enable Cronicle compatibility mode with optional Cronicle branding.

That is a more concrete migration story than most rewrites offer. The word compatible is doing the work, though. The README does not enumerate which plugins are compatible and which are not, so the honest position is that compatibility needs testing against your own plugin set before you commit. Cronicle's multiplexed events map onto visual workflows, which is a conceptual change as much as a mechanical one: a single event that fanned out to several targets becomes a graph with explicit branches and joins. Teams with many small events should expect to re-examine their scheduling model, not just import it.

The alternative worth naming is staying on Cronicle itself. It is still available at github.com/jhuckaby/Cronicle. The difference in approach is architectural: Cronicle is the older design that xyOps carries forward into a new one, with xySat workers, the conductor and worker split, and the alert snapshot model added. If your Cronicle installation is stable and you do not need monitoring or incident context, migration buys you features you may not use. If you are already stitching Cronicle together with a separate monitoring stack, xyOps is aimed squarely at that seam.

Licence, support tiers and the maintenance question

xyOps is released under the BSD 3-Clause licence, and the README is emphatic that there is no separate commercial build. Every application feature is in the open-source version, including Single Sign-On, OIDC integration, group-to-role mapping, multi-conductor scaling, air-gapped operation, workflows, monitoring, alerting and ticketing. Paid Professional and Enterprise plans buy human support, faster response targets and hands-on assistance; the README states plainly that they do not unlock software.

For a team evaluating this, the licence implication is straightforward: BSD 3-Clause permits modification and redistribution with the usual attribution and no-endorsement conditions, and the repository also carries a TRADEMARKS.md file, so the name and marks are handled separately from the code. That is a normal arrangement, but it means a fork you redistribute cannot use the xyOps name freely. This is not legal advice; read LICENSE.md and TRADEMARKS.md if redistribution is on your roadmap.

The maintenance picture is healthy by the only measure available here. The repository is not archived, and the last push was on 2026-09-21, one day before the release of v1.1.0 on 2026-09-20. Recent releases are frequent: v1.0.96 on 2026-09-05, v1.0.97 on 2026-09-11, v1.1.0 on 2026-09-20. The repository also includes a LONGEVITY.md file, which suggests the author has thought about the project's lifespan. The upgrade cost is where the real work sits. package.json pins an unusually specific set of dependencies, including overrides for lodash and nanoid, and the conductor depends on both Redis and PostgreSQL. Upgrades therefore mean coordinating the application version with the state stores, and the README does not document rollback, so a downgrade path is something to establish yourself before upgrading a production conductor.

When xyOps is the wrong tool

The clearest case against xyOps is scale of need. If you have three cron jobs on one server, the conductor, Redis and PostgreSQL stack is more moving parts than the problem warrants. A systemd timer or a plain crontab has no web UI to secure and no database to back up.

The second case is a team that already has a mature monitoring platform and a mature scheduler and is happy with both. xyOps competes with the combination, not with either half. Adopting it means either replacing both or running it alongside tools that overlap with it, which is the situation it was built to eliminate.

The third case is operational appetite. Running the conductor means running Redis and PostgreSQL, keeping them available, and backing them up, because the README states that jobs, logs, metrics, secrets, files, tickets and snapshots live inside your infrastructure. Self-hosting without telemetry is a genuine benefit, and it also means there is no vendor-side copy of anything when a database is lost. The README does not describe a managed offering, so that responsibility does not transfer.

Finally, contributors should read CONTRIBUTING.md before opening a pull request. The README is direct about this: feature pull requests are not accepted, though it says other forms of contribution are welcome. If your plan is to fork and upstream a feature, that plan does not fit the project's stated policy.

Editorial conclusion

Adopt xyOps if you already run Cronicle, or if you want scheduling, monitoring and alert context in one self-hosted application and are willing to run a conductor plus at least one worker. Skip it if you only need a single crontab entry, or if you cannot operate Redis and PostgreSQL alongside it. Verify first that the Docker trial starts and that your existing Cronicle plugins behave under Cronicle compatibility mode before migrating anything real.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. pixlcore/xyops on GitHub
3. Project website
4. README
5. Releases