xyOps: Workflow Automation and Server Monitoring for Modern Ops Teams

xyOps unifies job scheduling, workflow automation, monitoring, and incident response into a single, self-hosted control plane for your infrastructure.

xyOps is an open-source, self-hosted platform that combines job scheduling, workflow automation, server monitoring, alerting, and incident response into one cohesive system. Developed by PixlCore, it is designed for teams that want full control over their automation stack without surrendering data ownership or accepting vendor lock-in. Instead of stitching together separate tools for cron, health checks, on-call alerting, and ticketing, xyOps offers a unified control plane that keeps operational context, telemetry, and actions in one place.

At its core, xyOps targets a common pain point in DevOps environments: fragmented tooling that makes it hard to see how scheduled jobs, server health, and incidents relate to each other in real time. By connecting job execution with monitoring data, alert rules, and tickets, xyOps creates a feedback loop where failures and anomalies can automatically open incidents, attach server snapshots, and trigger remediation workflows.

Core Architecture Overview

xyOps runs as a service built on the pixl-server framework for Node.js, with the core conductor responsible for scheduling jobs, orchestrating workflows, serving the web UI, and exposing a REST API. The development guide specifies Node.js v16 or later as a requirement, alongside Git and a local workspace for building and running the service. Internally, the server is organized into components such as engine.js for the scheduler, job.js for job lifecycle management, workflow.js for the workflow engine, and schedule.js for trigger evaluation, reflecting a modular design that separates orchestration, execution, and scheduling concerns.

For persistence, xyOps uses pixl-server-storage with SQLite and filesystem backends, caching JSON records in memory for performance. Default Docker deployments store data under /opt/xyops/data in a named volume, with configuration JSON files under /opt/xyops/conf, so state and configuration are decoupled from the container filesystem. The scaling guide documents configuration options for SQLite caching and automated backups, allowing operators to tune cache sizes and enable compressed backup rotation for the embedded database.

The web interface is a single-page application built with jQuery, the pixl-xyapp framework, CodeMirror, Chart.js, and xterm.js, providing a rich UI for managing events, workflows, servers, monitors, alerts, and tickets entirely through the browser. All user interactions ultimately go through the REST API, which exposes endpoints for events, jobs, servers, monitors, alerts, tickets, users, and admin operations.

Distributed Agent and Satellite Architecture

xyOps uses a distributed architecture with one or more conductor servers and lightweight satellite agents (xySat) deployed on managed hosts. The conductor is the central control plane that stores configuration, schedules jobs, renders the UI, and evaluates monitors and alerts. xySat runs on each target server as a job runner and data collector, executing tasks on behalf of xyOps and streaming back metrics for CPU, memory, disk, and network usage.

Self-hosting documentation describes how worker containers can be launched using the ghcr.io/pixlcore/xysat:latest image, configured via the XYOPS_setup environment variable that points to an installation URL on the conductor.[9][15] For bare-metal or VM deployments, the xySat repository provides a one-line installer that is copied from the xyOps UI, using a curl | sh pattern to fetch and install the agent with the appropriate authentication token.[14] This design allows operators to scale out compute and monitoring without installing heavy dependencies on each node, because xySat is designed to be lean and self-contained.

Unified Operations Features

Job Scheduling and Workflow Automation

xyOps provides a comprehensive job scheduler that supports traditional cron syntax, fixed intervals, single-shot timers, and blackout windows to prevent execution during maintenance periods. Concurrency control and retries can be configured per job, making it suitable for critical batch processes and long-running workloads where precise timing and error handling are required. Events in xyOps define what to run, where, and when, including shell scripts, containerized tasks, or plugin-driven actions, and can be triggered on a schedule or manually via the UI or API.

On top of basic job scheduling, xyOps offers a visual workflow editor that lets operators model multi-step automation as directed graphs. Workflows can chain multiple jobs, add conditional branches, handle errors, and pass data between steps, effectively turning scripts into reusable, observable runbooks. This allows complex deployment pipelines, incident remediation procedures, or data-processing chains to be expressed in a way that is both executable and auditable.

Server Monitoring and Metrics

Once xySat agents are connected, xyOps automatically collects system metrics across all connected servers, including CPU, memory, disk, and network utilization. The Servers section of the UI displays real-time views of these metrics, along with historical trends, so operators can track resource usage and capacity over time. Monitors are defined using an expression language that can reference metrics and time windows, such as expressions that alert when average CPU load exceeds a threshold for several minutes.

The expression language and monitor engine support building higher-level checks that combine multiple signals, enabling more intelligent alerting than simple threshold-based systems. Because monitoring data is stored in the same platform that schedules jobs, it becomes straightforward to correlate job executions with spikes in resource usage or failures, aiding in root-cause analysis.

Smart Alerting and Incident Tickets

xyOps includes a flexible alerting system that can trigger on complex conditions defined by monitor expressions, time windows, and server groups. When conditions are met, alerts can send notifications, open tickets, or launch remediation jobs, making it possible to implement closed-loop incident responses that start with telemetry and end with automated action.

An integrated ticketing module allows incidents to be tracked directly inside xyOps, linking tickets to the jobs, alerts, and server snapshots that caused or were affected by the issue. This keeps operational context close to the underlying events and telemetry, reducing the need to jump between separate ticketing and monitoring tools during an outage.

Plugins, Secrets, and Extensibility

xyOps exposes a plugin system that allows extending behavior in any language, with a marketplace for discovering and installing community plugins. Plugins can act as event handlers, data processors, or integration bridges to external systems such as cloud providers and storage services. For example, the xyplug-s3 plugin on npm provides tools for uploading, downloading, and managing objects in AWS S3 as part of xyOps jobs and workflows.

Secrets management is built into the platform, providing secure storage for credentials that can be injected into jobs and plugins at runtime. This avoids hardcoding secrets into scripts or environment variables, and integrates with the automation and monitoring workflows so that sensitive data is handled in a controlled way.

Installation Guide

System Requirements and Deployment Model

For development or manual installation, the documentation lists Node.js v16 or later, Git, and a suitable code editor as prerequisites, reflecting the Node-based core. Production deployments are typically run via Docker, using the ghcr.io/pixlcore/xyops:latest image, with the container configured to expose ports 5522 and 5523 and to mount persistent volumes for data and configuration. The server or container hosting xyOps must be reachable on the network by a stable hostname, because worker servers and satellites connect back to the conductor by hostname rather than raw IP.

Storage requirements depend on job volume and retention policies, but the scaling guide assumes SQLite as the primary datastore with configurable cache limits and automated backup options, making it feasible to run xyOps comfortably on modest virtual machines and scale up as needed. RAM and CPU sizing guidance in the scaling documentation focuses on concurrent job counts and fleet size, encouraging operators to treat xyOps as a lightweight control plane that can be replicated for high availability.

Quick-Start with Docker (Recommended)

The quickest way to deploy xyOps is via a single Docker container that bundles the conductor, embedded storage, and web UI. The official quick-start command runs the ghcr.io/pixlcore/xyops:latest image with --detach, --init, and --restart unless-stopped, mounting a named volume xy-data to /opt/xyops/data, binding the Docker socket, and exposing ports 5522 and 5523.

A typical quick-start command looks like this (simplified for clarity):[9]

docker run \
  --detach --init --restart unless-stopped \
  --name "xyops01" --hostname "xyops01" \
  -v xy-data:/opt/xyops/data \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e XYOPS_xysat_local="true" \
  -e TZ="America/Los_Angeles" \
  -p 5522:5522 -p 5523:5523 \
  ghcr.io/pixlcore/xyops:latest

After the container starts, the web interface is available at http://localhost:5522 (HTTP) and https://localhost:5523 (HTTPS), with default credentials admin / admin for the initial login. The quick-start configuration also enables a local xySat worker inside the container via the XYOPS_xysat_local flag, so jobs can run immediately without provisioning external agents.

Docker Compose and Multi-Conductor Setups

For more robust deployments, hosting documentation provides a Docker Compose example that defines the xyOps service with the same image, hostname, environment variables, volumes, and port mappings as the single-container example. Multi-conductor topologies are supported by specifying multiple hostnames in the XYOPS_masters environment variable, allowing Nginx or a dedicated xyOps Nginx image to load-balance and fail over between conductor nodes.

An accompanying xyops-nginx container can be run using the ghcr.io/pixlcore/xyops-nginx:latest image, mounting TLS certificates and pointing at the conductor hostnames and port, with a built-in health check daemon that dynamically reconfigures Nginx based on conductor availability. This pattern enables operators to expose xyOps over HTTPS with proper certificates while keeping the conductors on an internal network.

Manual Installation (Non-Docker)

For environments where Docker is not preferred, xyOps can be installed manually by cloning the GitHub repository, installing Node.js dependencies, and running the provided installation script. The changelog documentation references a bash install.sh flow executed under /opt/xyops, reflecting a conventional Node.js service layout on Linux servers. Once installed, xyOps is configured via JSON files in /opt/xyops/conf, with overrides and environment variables offering additional control for production tuning.

Initial Configuration and Security Hardening

The configuration system is centered around a primary JSON file at /opt/xyops/conf/config.json, with UI-driven changes stored in overrides.json, layered on top of the base config. This allows operators to maintain a clean, version-controlled base configuration while still adjusting settings dynamically through the UI without editing files by hand.

Self-hosting guides strongly emphasize ensuring that the xyOps hostname is resolvable and stable, because worker servers rely on this DNS name for connecting to the API and receiving configuration. TLS configuration is typically handled by running xyOps behind a reverse proxy such as the provided Nginx image, which terminates HTTPS using operator-supplied certificates and forwards traffic to the conductor on port 5522.

From a security perspective, default credentials should be changed immediately after initial login, and access should be restricted via network controls and role-based user accounts, taking advantage of xyOps’ built-in user and API key management. API keys can be created via the UI, scoped with specific privileges, and passed in headers or query parameters, enabling secure integration with CI/CD systems, chatops bots, or external tooling.

Usage and Configuration Walkthrough

Adding Servers and xySat Agents

To add servers, administrators start in the xyOps UI, open the Servers section, and use the “Add Server” flow, which generates an installation command tailored to the target platform. For Linux servers, the xySat documentation shows a one-liner that downloads and executes the installer script from the xyOps API endpoint with an authentication token, installing the agent and registering the server. Once xySat is running, the server appears in the Servers view with live metrics, and can be assigned to groups for targeted job execution and monitoring.

Creating Your First Monitoring Check

With servers online, the next step is to define monitors using the expression language. A simple example in the documentation alerts when average CPU load exceeds 2.0 for five minutes, expressed as cpu.avgLoad > 2.0 with an appropriate time window. Monitors can be attached to specific servers or groups, and configured with alert thresholds, severity levels, and notification channels, allowing fine-grained control over when alerts fire and who gets notified.

Because monitoring and job execution share the same platform, operators can correlate monitors with specific jobs or workflows, for example to alert if a nightly ETL job pushes load beyond acceptable limits or fails to complete in time. Over time, monitor definitions can evolve into codified SLOs that tie directly into automated remediation workflows.

Building an Automated Workflow (Trigger–Action Logic)

The quick-start workflow guide walks through creating an event that runs a simple shell script, scheduling it, and then building a workflow to orchestrate a multi-step process. Workflows are composed in the visual editor by dragging nodes that represent events, conditions, and actions, then connecting them to define order and branching. Actions can include running jobs on specific servers or groups, sending notifications, invoking webhooks, or interacting with plugins, enabling rich trigger–action chains.

A typical operations workflow might start with a monitor firing, which in turn triggers an alert configured to open a ticket and launch a remediation workflow that gathers diagnostics, restarts a service, and posts a status update to chat. Because xyOps links jobs, alerts, monitors, and tickets, the entire history of the incident—including telemetry snapshots and remediation steps—remains visible in one place for post-incident review.