Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/pixlcore/xyops/llms.txt

Use this file to discover all available pages before exploring further.

Welcome to xyOps

xyOps is a next-generation system for job scheduling, workflow automation, server monitoring, alerting, and incident response—all combined into a single, cohesive platform. Built for developers and operations teams who want to control their automation stack without surrendering data, freedom, or visibility.
xyOps is open source and BSD-licensed. No paywalls, no telemetry, no vendor lock-in.

Why xyOps?

Most automation platforms focus on workflow orchestration—they run tasks, but they don’t really help you see what’s happening behind them. xyOps takes it further:

Unified platform

Job scheduling, workflow orchestration, server monitoring, alerting, and ticketing in one place. Everything talks to everything else.

Real-time visibility

Watch logs stream live, track resource usage, and see exactly what’s running on which server at any moment.

Integrated feedback loop

When an alert fires, emails include running jobs. One click opens a snapshot showing processes, CPU load, and network connections.

Built for scale

Deploy lightweight satellite workers across your infrastructure. Supports Docker, Linux, macOS, and Windows.

Core concepts

Events and workflows

An event defines what to run (a plugin plus parameters), where to run it (servers or groups), when to run (triggers), and how to control and react (limits and actions). Each time an event runs, it launches a job.Use events for simple automation tasks like scheduled backups, health checks, or maintenance scripts.Learn more about Events
A workflow is a visual graph that chains jobs with control flow. A workflow run becomes a parent job that launches sub-jobs on its nodes. You can fan out, join, repeat, multiplex across servers, and attach limits/actions per node.Use workflows when you need orchestration, branching, or parallelism.Learn more about Workflows

Triggers: when jobs run

Triggers control when events and workflows are allowed to run:
  • Manual: Allow a user or API to launch on demand
  • Schedule: Specify hours/minutes/days like cron, with optional timezones
  • Interval: Run every N seconds starting from a timestamp
  • Single Shot: Run once at an exact time
  • Plugin: Custom trigger logic provided by a plugin
  • Range and Blackout: Permit or block launches between specific time ranges
Triggers support catch-up mode to replay missed schedules, delays to defer launch, and second-level precision for time-sensitive tasks.

Plugins: what runs

Event Plugins are the code that runs your jobs. Built-in options include:
  • Shell Plugin: Run arbitrary shell scripts/commands
  • HTTP Request Plugin: Call HTTP(S) endpoints
  • Docker Plugin: Run scripts inside containers
  • Test Plugin: Emit sample data/files for testing flows
You can write your own plugins in any language. Plugins read a JSON job context on STDIN and write JSON status updates to STDOUT. Plugin documentation

Actions and limits

Limits

Self-imposed constraints such as:
  • Max Run Time
  • Max Output Size
  • Max CPU/Memory
  • Max Concurrent Jobs
  • Max Queue
  • Max Retries
Limits can apply tags, send notifications, take snapshots, and optionally abort jobs.Limits documentation

Actions

Reactions to job outcomes:
  • Start, success, error, warning, critical, abort
  • Tag-based triggers
  • Alert state changes
Action types include email, web hook, run job, ticket, snapshot, and more.Actions documentation

Architecture overview

xyOps uses a distributed architecture designed for reliability and scale:
1

Conductor servers

Run the full xyOps stack: scheduling, routing, storage, and UI/API. Multi-conductor setups support automatic failover with primary election.
2

Satellite workers (xySat)

Lightweight agents that run on your servers. They execute jobs, collect metrics, and maintain persistent WebSocket connections to conductors.
3

Storage backends

Choose from SQLite (default), S3-compatible storage (MinIO, AWS S3), or other engines. Multi-conductor setups require external storage.
Conductor servers must be addressable on your network by hostname. This is how worker servers connect to the platform.

Key features at a glance

Job scheduling

Beyond cron: intervals, single-shot, blackout windows, catch-up, and second-level precision.

Visual workflows

Graphical editor to connect events, triggers, actions, and monitors into pipelines.

Server monitoring

Define exactly what to monitor. Get notified the moment things go wrong.

Smart alerts

Rich alerting with full customization and complex triggers. Link alerts to jobs and tickets.

Built for fleets

Scales from five servers to five thousand. Auto-failover, load balancing, and server groups.

Developer-friendly

Full REST API, plugin system in any language, expression-based queries, and comprehensive docs.

Next steps

Ready to get started? Here are some suggested paths:

Quickstart guide

Get xyOps running locally in minutes with Docker. Create your first event and run your first job.

Self-hosting guide

Deploy xyOps on your infrastructure. Covers Docker deployment, worker setup, TLS, and storage backends.

API reference

Explore the complete REST API for programmatic control of events, jobs, servers, and more.

Configuration

Deep dive into xyOps configuration options, environment variables, and advanced settings.

Open source commitment

xyOps will always be open-licensed and OSI-approved. No rug pulls. Read our Longevity Pledge and Governance Model to learn how we preserve openness, reliability, and fairness.
Licensed under BSD-3-Clause. See the LICENSE for details.

Build docs developers (and LLMs) love