Exordos Core

📚 Documentation: exordos.github.io/exordos_core

Exordos Core is an open-source NoOps platform for managing corporate infrastructure and software ecosystems. It provides a unified platform layer — from bare metal and virtual machines all the way to applications and services — designed to be operated by both humans and AI agents.

What Exordos Core does

Exordos Core is the next step beyond classic DevOps. Instead of a collection of disconnected tools requiring constant manual coordination, it gives your organization a single declarative platform layer where infrastructure, policies, and service lifecycle are managed as one coherent system.

Key capabilities:

• Declarative management — describe the desired state; the platform reconciles reality to match it automatically (self-healing). No more configuration drift or manual correction after every change.
• Image-based provisioning — fast, repeatable, and predictable delivery of environments and services. Rollouts and recovery become straightforward operations, not fire-fighting exercises.
• AI-ready architecture — the platform is designed from the ground up to be controlled by an AI agent, reducing manual toil and letting teams operate at the level of intent rather than low-level steps. An MCP server runs alongside the User API for agents to connect to directly.
• Unified lifecycle management — infrastructure, internal services, and application lifecycle all managed through a single control plane. One system instead of a zoo of tools.
• Sovereign deployment — run entirely within your own on-prem or private cloud perimeter with no dependency on external services. Full control over data, access, and the operational boundary.
• Element ecosystem — install and manage ready-to-use software elements (databases, messengers, internal services, and more) directly from the platform marketplace, just like an app store for enterprise software.

For a full overview of architecture, configuration, and advanced usage, visit the documentation.

🚀 To start using Exordos

Install the CLI tools with a single command:

curl -fsSL https://repo.exordos.com/install.sh | sudo sh

Then follow the instructions in the terminal, or refer to the documentation for a full setup guide.

💡 Contributing

Contributing to the project is highly appreciated! However, some rules should be followed for successful inclusion of new changes in the project:

• All changes should be done in a separate branch.
• Changes should include not only new functionality or bug fixes, but also tests for the new code.
• After the changes are completed and tested, a Pull Request should be created with a clear description of the new functionality. And add one of the project maintainers as a reviewer.
• Changes can be merged only after receiving an approve from one of the project maintainers.

Disk placement

Disk specifications and standalone volumes accept tier (COLD, WARM, HOT) and ephemeral (true or false). Both default to WARM/true, which identifies local qcow2 storage. The scheduler prefers an exact tier match and falls back to another tier with enough space, while always preserving ephemeral. Persistent disks must request ephemeral: false.

The chosen storage pool is retained for reuse and resize; an existing disk is never moved merely because another pool has more free space. Changing tier or ephemeral after creation is unsupported.

This branch requires the matching gcl_sdk branch feat/disk-scheduling (PR #211) before it can be merged and released. The SDK must provide DiskTier, the disk policy fields, and select_storage_pool; a released SDK without these APIs is insufficient.

Until that SDK release is published, uv.lock pins the development SDK commit 2987730b84e090666ecf46b64a6e6cecdfaf1872 through tool.uv.sources. This makes uv sync --locked reproducible without resolving an older SDK from PyPI. Image builds can still use LOCAL_GENESIS_SDK_PATH.

The disk scheduling migration also converts existing local hypervisor driver configuration to the list-of-pools schema. Update the CLI together with the SDK and core so new hypervisor registrations use that schema too.

Disk policy changes on existing node disks are rejected before persisting API or manifest updates. Resizing a disk with its existing policy remains supported. The curated MCP node tools expose tier and ephemeral too.

The disk scheduling JSON migration supports downgrade: it removes the added policy fields, restores single local-pool names, and invalidates resource hashes for rebuilding by the previous release. A local hypervisor with multiple pools cannot be represented by the old schema; downgrade refuses that configuration rather than silently discarding pool assignments.