xyOps: the Cronicle successor that keeps the schedule and the server in one view

One docker command boots a conductor with a local xySat worker

xyOps splits into a conductor that owns the schedule and the interface, and workers that actually run the jobs. The shortest route to both on one machine is the disposable container the project publishes:

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

Four environment variables do the wiring. XYOPS_masters names this container as the conductor host, XYOPS_xysat_local=true asks for a worker inside the same container, XYOPS_base_app_url points the interface at the published port, and TZ decides which timezone the trial runs in. Then open the port and sign in with the username admin and the password admin.

That single command exposes the entire product surface at once: scheduling, workflows, monitoring, alerting. What it cannot give you is anything durable. The container starts with --rm, so stopping it takes the container and its data with it, which is exactly what the project means when it calls the trial intentionally disposable. Read this as a tour of the interface, not as a deployment. A persistent or production install is a different piece of work, pointed at the self-hosting guide rather than at this command.

Recurring schedules, cron expressions, intervals and webhooks feed one queue

A job in xyOps can be launched on one server, on a server group, or across an entire fleet, and its trigger can be a recurring schedule, a cron expression, a fixed interval, or an inbound webhook. Around that trigger sit the controls that decide what happens when several things fire at once: priorities, queues, and resource limits. Those are the knobs that matter on a busy fleet, because they decide whether a nightly backup gets to run at all or keeps losing to a chatty monitor.

Cronicle users will recognise the vocabulary. xyOps is written by Cronicle's creator and deliberately carries the old scheduling concepts forward, which is why the package manifest still advertises the original domain in its keyword field: cron, crontab, scheduler, monitor, webapp. That list is a fair summary of the half of the system this part covers.

What changed downstream of a trigger is the interesting part. In xyOps a multiplexed Cronicle event can be converted into a visual workflow. The scheduling primitives carried over, and the shape of what they orchestrate did not. That is the whole migration story in one sentence, and the reason existing installations can keep their job definitions while moving the orchestration somewhere a person can read.

Workflows branch, join, replay and stop for human approval

A workflow in xyOps is a graph you assemble in the interface, not a script you write. The pieces the interface gives you are branching, parallel execution, joins, human approval, reusable sub-workflows, replay, and data passing between steps. Branching and joins cover the ordinary conditional shape of an incident response: fan work out, wait for the pieces that matter, carry on.

Human approval is the part that separates this from a plain cron runner. A step can wait for a person before it fires, which is how an expensive or destructive action stays behind a deliberate click rather than firing on a timer nobody was watching.

Replay covers the other case, the workflow that did the wrong thing at three in the morning and needs to run again with the same inputs. Reusable sub-workflows mean a common sequence, a snapshot plus a ticket, gets built once and dropped into several graphs instead of copied between them.

The limits are worth stating plainly. Workflow definitions live inside the conductor, and xyCLI can sync your automation definitions with local files you can version in Git,.

An alert freezes the server state at the moment it fired

The observability half of xyOps is built around one specific move: freezing evidence. When an alert fires, the system captures the state of the relevant server at that moment, including metrics, processes, network connections, active jobs, and the alert data itself. You open the alert, you open its snapshot, and what you need is already there instead of being reconstructed after the fact from several separate tools.

The same captured state feeds the response side. Failures and alerts become actions: take a server snapshot, open a ticket, call a webhook, block launches that would be unsafe, or start remediation automatically. Blocking a launch is the one worth understanding if you are worried about a deployment racing a failing health check, because it turns a monitoring system into something that can hold a queue.

Signals are not limited to the built-in set. Custom metrics are supported alongside process inspection, network connections, and historical performance, with jobs and servers watched together on live dashboards rather than in separate views. The design has a cost that belongs to whoever runs the conductor: metrics, logs, snapshots, tickets, secrets and configuration all stay inside your own infrastructure, so retention and storage sizing are your decisions rather than a vendor's.

xyCLI ships as a separate npm package with its own dashboards

xyOps has a command line companion, xyCLI, kept in its own repository and installed with npm:

npm install -g @pixlcore/xycli

From there it brings xyOps to the terminal with colourful dashboards, monitoring charts, and readable job reports. You can launch jobs and workflows from it, follow live output while they run, investigate failures, inspect server health, and sync your automation definitions with local files you can version in Git. That last point is the one that changes how a team works day to day: the definitions stop being click-only state inside a web interface and become something you can diff, review, and roll back through your own history.

What the package is not is a copy of the server. The xyops manifest itself is marked private, its version is 1.1.12, and its entry point is lib/main.js, so there is no npm distribution of the conductor to install and no hosted fallback. Something has to be running somewhere before xyCLI has anything to talk to, and that something is the conductor you install yourself.

Node 24, three pinned overrides and a repository split by directory

The image builds on node:24-bookworm-slim and does not stop there. The apt layer installs the system tools a monitoring agent actually needs, among them procps, lsof, iputils-ping, dnsutils, net-tools, iproute2, openssh-client, curl, wget, vim, less, sudo and tzdata, plus a compiler toolchain with python3 and build-essential, and the Docker CLI so the container can talk to a Docker socket. uv is fetched from astral.sh and moved into /usr/local/bin. The application itself is copied to /opt/xyops, with XYOPS_foreground and XYOPS_color set as image defaults.

The dependency list is long and partly frozen. Three transitive packages are overridden to exact versions rather than ranges: lodash at 4.18.1, nanoid at 3.3.18, and basic-ftp at 6.2.1. Direct dependencies include pg 8.20.0 for the database, ioredis 5.10.1, jexl 2.3.0 for expressions, sanitize-html 2.18.1 and marked 4.3.0 for rendering, and the pixl-server family the conductor is built from. The overrides block is where a fork should look first when a frozen version misbehaves, since those three entries were chosen by the project rather than resolved by you.

The tree itself hints at the layout: bin/ holds the control scripts, lib/ and internal/ hold the server, htdocs/ the interface, sample_conf/ the configuration samples, test/ the suite, docs/ the bundled documentation.

Rollback, upgrades and air gaps live outside this repository

The repository root takes its own posture seriously: SECURITY_OVERVIEW.md, THREAT_MODEL.md and LONGEVITY.md sit next to CODE_OF_CONDUCT.md, CONTRIBUTING.md, TRADEMARKS.md and CHANGELOG.md. The documentation lives at docs.xyops.io.

For a persistent or production deployment, the README points to the Self-Hosting Guide at docs.xyops.io/hosting, which is where real deployment instructions begin.

Release cadence is visible from tags rather than prose: v1.1.12 landed on 29 October 2026, v1.1.11 on 25 October 2026, and v1.1.10 on 23 October 2026, with the last push to the default branch on 31 October 2026. Three releases in under a week is a fast-moving project, which is the argument for reading CHANGELOG.md before you pin a version rather than after something changes under you.

Editorial conclusion

The honest test of xyOps is cheap. Run the disposable container, schedule something against the local worker, fire an alert and open its snapshot, because that path is where this project goes further than a plain cron replacement. Before committing, read the Self-Hosting Guide, since the trial's shared admin credentials tell you nothing about hardening. Teams already running Cronicle have the shortest path, since import, compatible plugins and compatibility mode already exist.

Frequently asked questions

Official sources

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