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.
Metadata
Release files for exordos-core 0.3.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| exordos_core-0.3.3.tar.gz | 844.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| exordos_core-0.3.3-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.8 MB
Release files / exordos_core-0.3.3.tar.gz
| Download URL | exordos_core-0.3.3.tar.gz |
|---|---|
| Size | 844.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4d0af618ce88eaa2a5265b871b86eee33bfa6a7a9a98c04b6e3e65afb419d9c0
|
|
BLAKE2b-256 checksum How to use checksums |
aa85b3a3666302b7fa8cec6c631ab42c327473a965db100cbf16fad095d9c693
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency logRelease files / exordos_core-0.3.3-py3-none-any.whl
| Download URL | exordos_core-0.3.3-py3-none-any.whl |
|---|---|
| Size | 917.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
57dc6563af334a73aaf7d07553886f58d438cd60f0683ccd197ee4874c8e974c
|
|
BLAKE2b-256 checksum How to use checksums |
0fec0c37754935a907864729f3769bc9b249276fee1f54a53d88f74cbc273172
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency log
