Oxmgr: A Lightweight PM2 Alternative Written in Rust

A deterministic, cross-platform process manager for Node.js, Python, Go, Rust, and any executable.

The Problem With PM2 in Mixed-Language Environments

PM2 earned its place. For Node.js teams who needed a quick way to keep services alive, restart on crashes, and tail logs from a single CLI, it solved a real problem. It still does.

But production infrastructure rarely stays pure.

A team starts with a Node.js API, then adds a Python worker for ML inference, a Go binary for a performance-sensitive service, and a few shell-based cron jobs. Suddenly PM2 is managing things it was never designed for, and the configuration becomes a mixture of workarounds, undocumented flags, and institutional knowledge that lives only in someone's terminal history.

That is the gap Oxmgr is designed to fill.

What Oxmgr Is

Oxmgr is a process manager written in Rust for running and supervising long-lived services on Linux, macOS, and Windows. It is language-agnostic by design, which means it works equally well for Node.js applications, Python services, Go binaries, Rust executables, and arbitrary shell commands.

It is available on GitHub and installable via npm, Homebrew, Chocolatey, or APT.

The core design principle is that process management should be declarative and reproducible rather than dependent on operator memory and runtime commands. That shift in model is what makes Oxmgr genuinely different from a cosmetic PM2 reimplementation.

Declarative Configuration and Idempotent Apply

The centerpiece of Oxmgr's operational model is oxfile.toml, its native configuration format. Instead of managing services through a sequence of CLI commands, you describe the desired state:

version = 1

[[apps]]
name = "api"
command = "node server.js"
restart_policy = "on_failure"
max_restarts = 10
health_cmd = "curl -fsS http://127.0.0.1:3000/health"

Then you apply it:

oxmgr validate ./oxfile.toml --env prod
oxmgr apply ./oxfile.toml --env prod

oxmgr validate catches invalid or inconsistent configuration before it reaches production. oxmgr apply is idempotent — if nothing changed, unchanged services are left untouched. If something did change, only the affected services are reconciled.

This matters operationally. Config lives in Git, is reviewable in pull requests, and is safe to run repeatedly in CI/CD pipelines without risk of bouncing services unnecessarily.

Production-Grade Supervision Features

A serious PM2 alternative needs to do more than restart failed processes. Oxmgr includes the supervision primitives that production environments actually require.

Health checks run a configurable command on a schedule. After a defined number of consecutive failures, Oxmgr automatically restarts the service. This is more reliable than restart-on-exit alone because it catches processes that are alive but non-functional — the kind of failure that daemon restarts cannot detect.

Crash-loop protection prevents infinite restart storms. If a service crashes repeatedly within a short window, Oxmgr applies a configurable cutoff and stops automatic restarts, surfacing the problem rather than masking it behind an endless loop.

Resource monitoring tracks CPU and RAM per process. On Linux, Oxmgr optionally enforces hard limits through cgroup v2, which means resource constraints are applied at the OS level rather than relying on application-level cooperation.

Graceful shutdown respects configurable stop signals and timeout escalation, giving services the opportunity to drain connections cleanly before being forcibly terminated.

Per-process log management captures stdout and stderr to separate files with rotation, keeping logs organized across fleets of services.

All of this is visible through a built-in terminal UI (oxmgr ui) that provides a fleet summary, real-time metrics, and keyboard-driven controls for inspection and lifecycle operations.

Migrating From PM2

A PM2 alternative is only useful if adoption does not require rewriting everything at once. Oxmgr addresses this directly.

It supports PM2's ecosystem.config.json format as a migration bridge. Existing teams can import their current configuration, evaluate Oxmgr against familiar workloads, and convert to oxfile.toml when they are ready:

# Import existing PM2 config
oxmgr import ./ecosystem.config.json

# Convert to native format for long-term use
oxmgr convert ecosystem.config.json --out oxfile.toml

This incremental path matters because most teams do not switch operational tooling in a single migration event. They evaluate in parallel, adopt gradually, and formalize the switch once confidence is established.

The Day-to-Day Workflow

For teams that care about operational simplicity, the daily workflow in Oxmgr looks like this:

oxmgr validate ./oxfile.toml --env prod
oxmgr apply ./oxfile.toml --env prod
oxmgr status api
oxmgr logs api -f
oxmgr pull api

The last command — oxmgr pull — is worth highlighting. For git-backed services, it fetches the latest changes and reloads or restarts the service only if the commit actually changed. This avoids unnecessary disruption on unchanged deployments and fits naturally into webhook-driven update workflows.

Why Rust?

Rust was a deliberate choice, not a trend. Oxmgr runs as a long-lived system daemon, and that context has specific requirements: a small runtime dependency surface, predictable memory behavior, a single native binary, and consistent cross-platform support without requiring a runtime installed on the target host.

Rust satisfies all of these. The choice is not about raw performance benchmarks — it is about building a durable, predictable daemon that behaves consistently across Linux, macOS, and Windows without surprising operators.

Where Oxmgr Fits

Oxmgr is designed as a host-level process manager. It fits well on application servers, virtual machines, and dedicated service hosts running mixed-language workloads — anywhere a team wants clear, auditable operational behavior in place of ad hoc scripts or language-specific tooling.

It is not designed to replace Kubernetes or container orchestration. It operates at a different layer and solves a different problem: keeping services running on a single host with predictable, inspectable behavior.

Honest Limitations

Infrastructure tooling should be transparent about its boundaries. Currently, Oxmgr's cluster mode targets Node.js command shapes rather than acting as a universal clustering abstraction for every runtime. That is a deliberate tradeoff. Explicit scope is preferable to ambiguous behavior.

Getting Started

Oxmgr is open source under the MIT license.

# npm
npm install -g oxmgr

# Homebrew
brew tap empellio/homebrew-tap && brew install oxmgr

# APT
echo "deb [trusted=yes] https://vladimir-urik.github.io/OxMgr/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/oxmgr.list
sudo apt update && sudo apt install oxmgr

Full documentation, the Oxfile specification, and deployment guides are available in the GitHub repository.

Vladimir-Urik / OxMgr

Oxmgr is a modern, lightweight process manager written in Rust, a fast, deterministic alternative to PM2 for managing any executable across platforms.

Oxmgr

Oxmgr is a lightweight, cross-platform Rust process manager and PM2 alternative.

Use it to run, supervise, reload, and monitor long-running services on Linux, macOS, and Windows. Oxmgr is language-agnostic, so it works with Node.js, Python, Go, Rust binaries, and shell commands.

Latest published benchmark snapshots: BENCHMARK.md and benchmark.json

Why Oxmgr

• Language-agnostic: manage any executable, not just Node.js apps
• Cross-platform: Linux, macOS, and Windows
• Low overhead: Rust daemon with persistent local state
• Practical operations: restart policies, health checks, logs, and CPU/RAM metrics
• Config-first workflows with idempotent oxmgr apply
• PM2 ecosystem compatibility via ecosystem.config.json
• Interactive terminal UI for day-to-day operations

Core Features

• Start, stop, restart, reload, and delete managed processes
• Named services and namespaces
• Restart policies: always, on-failure, and never
• Health checks with automatic restart on repeated failures
• Log tailing, log rotation, and per-process stdout/stderr logs
• Best-effort zero-downtime reloads
• Git pull and webhook-driven update workflow
• Import and export bundles…

View on GitHub