Atraxis

One console to inspect containers, certificates and metrics, then prepare and test automation rules through the independent Atropos service.

Atraxis 1.0.3 runs on your own infrastructure. It provides authenticated web, command-line and Textual interfaces, with access scoped to your organizations and resources. It distinguishes fresh observations, retained history and unavailable sources instead of treating unknown values as zero.

Website (EN) · Site (FR) · User guide · Contributing · Roadmap

How it fits together

Arrows show who calls whom. Atraxis reads the configured Monit-Docker and CertLord APIs directly. Alternatively, Atraxis queries Prometheus; Prometheus scrapes Covenant's metrics endpoint, and Covenant reads its configured source APIs. Query responses return in the opposite direction: Prometheus does not push inventory observations into Atraxis.

Start with the direct adapters. Neither Covenant nor Prometheus is required for container or certificate inventory. Add Atropos when you need rule management; Atraxis calls its authenticated API through atropos-client. Atropos can submit explicitly authorized jobs to Auton and send configured notifications to Alertmanager. Prometheus can also send metric alerts to Alertmanager separately. Saving, testing or activating a rule never starts a workflow automatically.

What you can do

• Inspect container, certificate and selected metric observations in one inventory.
• Search the resources you are authorized to read, with explicit freshness and source availability rather than an invented global health score.
• Create rule drafts, test exact revisions and review activation through Atropos. Saving, testing and activating a rule never dispatch an intervention by themselves.
• Manage access and configuration through reviewed, authorized operator flows.
• Use each underlying tool independently; Atraxis preserves its own local controls.

Try the public demo

Open the demo (EN) · Ouvrir la démo (FR)

No account is required. Read three real metrics from the public monit-docker demo, collected by Covenant and Prometheus: inventory container count, HTTP collection outcome and the source observation timestamp. This read-only view refreshes every 30 seconds and marks retained values as historical when collection fails or data becomes old. Successful HTTP collection does not establish workload health.

The demo also shows Prometheus alert states and actual receipts from a local Alertmanager webhook receiver. Its marked pipeline check uses a time-limited synthetic signal; no email, SMS or chat notification is forwarded. See metric alerts and Alertmanager delivery to configure your own notification path.

A separate section lets you explore six synthetic resources, inspect retained observations and try a local CPU-threshold example. These scenarios are not connected to an Atropos engine and do not trigger interventions. The public feed contains only selected numeric measurements and timestamps; private pilot pages and APIs remain authenticated. Install Atraxis for the actual service-backed inventory and rule-management interfaces.

Release 1.0

1.0.0 is the first stable Atraxis package for the documented reference profile. See supported configurations, limits and upgrades. Atropos engine and client 1.0.1 are independently published on PyPI as atraxis-atropos and atropos-client. Atraxis 1.0.0 still pins client 0.1.0a10 for its optional rules extra. This main checkout is 1.0.3 and pins the published client 1.0.0. The engine is installed in its own environment. See the component compatibility note. Direct Monit-Docker and CertLord adapters require neither Covenant nor Prometheus.

Container image

See the Docker image guide for image availability, configuration, persistent state and TLS. Pull the published Linux amd64 image with docker pull decryptus/atraxis:1.0.3. The full Compose installation downloads Atraxis, Atropos and NGINX images, including the optional execution/simulation worker profiles.

Install from PyPI

Use Python 3.11 or 3.12 with the system libmagic library installed.

python -m venv .venv
. .venv/bin/activate
python -m pip install atraxis==1.0.3
atraxis --help

The Atraxis package on PyPI provides the supervision platform. For the interactive installer, see the setup guide.

Install from source

To install the same release from its Git tag:

git clone https://github.com/decryptus/atraxis.git
cd atraxis
git checkout v1.0.3
python -m venv .venv
. .venv/bin/activate
python -m pip install .

Follow the operator journey to prepare login, scoped access and recovery, then the setup guide before starting the daemon. To use rule features, install the independent Atropos client and connect to an explicitly configured Atropos service.

Discover monit-docker in video

A three-minute tour of Docker monitoring, cron and serve modes, and the web and terminal interfaces.

• Français — découvrir monit-docker
• English — discover monit-docker
• All our videos on Decryptus

Status

Atraxis 1.0.3 is stable for its documented reference profile, under GNU GPL version 3. It provides read-only HTTP collection, an in-memory inventory, an authenticated API and an optional web rule workbench. Readiness requires current observations from every configured source. The public demo remains experimental and read-only; the stable package does not imply a hosted production service, arbitrary deployment qualification or high availability.

A remote rule service, local rule operator CLI/TUI and rule API integration now support scoped drafts, tests and explicit active versions through an independent Atropos service. Atraxis contains no rule engine or rule storage. Rule control remains separate from inventory collection and executes no interventions.

Source adapters and dependencies

Use direct access by default: monit_docker for containers and certlord for certificates. Neither requires Covenant nor Prometheus. Prometheus is optional for Atraxis inventory collection; each configured kind selects its read path.

Both complete inventory adapters through Prometheus require Covenant's dedicated observation plugins. Prometheus and Covenant become required dependencies of those configured sources. They preserve native identities and freshness rules, with additional scrape/transport checks and delay. The generic prometheus adapter provides metric resources; it does not reconstruct container or certificate inventories.

Resources are discovered automatically within each source API's inventory. Configure one connection per upstream instance, not one per container or domain. Covenant's observation plugins export every returned resource; additions, changes and removals appear after collection, scraping and Atraxis polling. Numeric metric selection with prometheus remains explicit. Inventory permissions and collection limits still apply.

Direct inventory access can coexist with a separate Covenant/Prometheus path for metric history and alerting. Choose one inventory route per upstream instance: configuring both under different source IDs creates separate inventories, not automatic deduplication or failover. A failed source retains historical data and cannot supply current observations. Full observation transport also has explicit size and Prometheus storage costs.

A direct Covenant JSON relay into Atraxis is not implemented. The supported Covenant observation path currently passes through Prometheus. See source configuration for credentials, limits and adapter selection, and metric alerting for the optional Prometheus → Alertmanager path.

Related software

Each tool keeps its own configuration, credentials and protections. Atraxis does not replace a source's monitoring, a metrics database, or Atropos's authoritative rule storage. DWho, HTTPdis and Sonicprobe provide shared implementation libraries; normal installation resolves the declared Python dependencies.

Name

Adrien selected the name Atraxis on 4 October 2026. It is inspired by the Atraxi from Doctor Who. This project is independent of the historical anatolsommer/atraxi Node.js HTTP monitoring tool.

HTTP daemon and YAML

For guided inventory deployment, the terminal wizard can prepare files, start Docker Compose, or install a native systemd user service.

Start with the setup and diagnostic guide: atraxis setup previews a validated starter configuration, and atraxis doctor explains local configuration problems and optionally checks current source observations.

See runtime configuration and Docker notes. Validate with atraxis check-config --config /etc/atraxis/atraxis.yml and start with atraxis serve --config /etc/atraxis/atraxis.yml. Commands are explicit; no automatic TUI startup. Source collection runs with the daemon. Use atraxis status or atraxis inventory with a separate client configuration to consult the API; see CLI usage and exit codes.

For a single-host installation, follow the Docker Compose guide. It covers separate verified TLS connections, persistent data, cold restoration and explicit guarded-worker profiles for simulation and approved execution.

Source destinations, credentials and collection budgets can now be checked offline; see source configuration. The daemon periodically reads configured sources and retains the last valid snapshot when a source fails.

The bounded read-only HTTP transport is implemented and tested with synthetic fixtures. See collection and inventory for scheduling, freshness, API fields and limitations.

Documentation

• Users: installation and diagnostics, Docker Compose, configuration and operation in the user guide.
• Contributors: architecture, tests and development.

Textual terminal interface

See the Textual guide for installation, navigation and operation confirmations.

The capture below shows the actual interface with synthetic demonstration data.

Web inventory

Open /ui on the running daemon to view authenticated source, container and certificate and metric snapshots. The page distinguishes current, historical and unknown observations and refreshes on request. See web inventory for access, navigation and the current read-only scope.

The optional web rule explorer reads rule history, active state and revision YAML from Atropos using server-side account mappings and engine-enforced permissions.

With an explicitly configured browser origin, the web rule workbench also edits existing YAML drafts and runs scenarios against an exact revision. Atropos owns validation, rights, versions and reports; saving or testing does not activate rules or execute actions.

Draft editor preview · Scenario report preview

A passing report can open an explicit activation review. Confirmation pins the tested revision and current active generation; Atropos enforces rights and records the change.

Optional browser source configuration provides reviewed source changes for explicitly authorized installation administrators. Defaults stay disabled; saved changes require an explicit daemon restart.

The base package also offers local source and inventory administration: inspect, review and apply source changes or scoped read grants using an explicit OS identity. CLI use does not require enabling web administration or installing Textual.

Use the offline retention report to inspect account archive and configuration audit capacity without modifying evidence.

Roadmap and license

See the public roadmap for current capabilities and planned scope. Project-owned code and documentation are licensed under GNU GPL version 3 only (LICENSE, SPDX GPL-3.0-only). Dependencies retain their own licenses.