============== Delonix Engine

.. image:: https://img.shields.io/github/v/release/ngolacloud/delonix?label=release :target: https://github.com/ngolacloud/delonix/releases/latest :alt: Latest release .. image:: https://img.shields.io/github/actions/workflow/status/ngolacloud/delonix/ci.yml?branch=main&label=CI :target: https://github.com/ngolacloud/delonix/actions/workflows/ci.yml :alt: CI status .. image:: https://img.shields.io/github/license/ngolacloud/delonix :target: https://github.com/ngolacloud/delonix/blob/main/LICENSE :alt: License

A daemonless, rootless-first, kernel-native container and microVM engine, written in Rust — the open-source engine at the foundation of the Delonix platform. It creates and manages Linux containers directly through namespaces, cgroups v2 and nftables — no supervising daemon, not even a monitor per container — plus declarative microVMs on Cloud Hypervisor or libvirt/KVM. It is homologous to Docker/Podman, with rootless operation as a first-class design goal rather than an afterthought, and it ships its own Kubernetes CRI so a kubelet can talk to it with no containerd in between.

Not a low-level OCI runtime (that's runc/crun): Delonix is a full container and VM engine — build, run, network, firewall, store, and bootstrap Kubernetes clusters, from one binary.

:Docs: https://ngolacloud.github.io/delonix/ :Contributor handbook: https://ngolacloud.github.io/delonix/handbook/ (English, Português de Angola, Français) :Rust tutorial: https://angolardevops.github.io/delonix-rust-tutorial/ (Português de Angola — Rust, containers, OCI/CRI and a from-scratch rootless runtime) :Repo: https://github.com/ngolacloud/delonix

Why it's different

.. list-table:: :header-rows: 1 :widths: 22 26 26 26

• • Docker
  • Podman
  • Delonix
• • Daemon
  • dockerd (root)
  • none (a conmon per container)
  • none — a short-lived supervisor per container (same model as conmon), which is what makes a detached container's exit code knowable
• • Rootless
  • opt-in
  • yes (a slirp/pasta per container)
  • default — one shared slirp4netns + an nftables ingress
• • VMs
  • —
  • machine (for itself)
  • first-class declarative microVMs (Cloud Hypervisor / libvirt)
• • Kubernetes
  • —
  • —
  • own CRI + kubeadm bootstrap from scratch (delonix cluster). Conformance is measured and published: 79/103 specs of the upstream critest — see Kubernetes CRI conformance_
• • Health checks
  • continuous
  • continuous (needs systemd timers)
  • continuous, without systemd — the detached container's own supervisor runs the probe
• • Custom seccomp profiles
  • yes
  • yes
  • yes (OCI JSON), and a profile it cannot fully express is refused, never silently downgraded
• • Firewall
  • basic
  • basic
  • per-container L4 (ingress/egress) + declarative kind: NetworkPolicy
• • Observability
  • stats
  • stats
  • eBPF per-container flow accounting (delonix net flow)
• • Resource limits, rootless
  • n/a (daemon is root)
  • needs a delegated cgroup
  • needs a delegated cgroup — see Resource limits need a delegated cgroup_

Resource limits need a delegated cgroup

-m / --cpus / --pids-limit only take effect when the process that starts the container owns a delegated cgroup. From an ordinary SSH session they are silently inert — and that is a cgroup v2 rule, not a limitation of this engine: rootless Podman has exactly the same requirement.

Measured on a clean Ubuntu 24.04 VM over plain SSH, with -m 128M --cpus 0.5::

cgroup: /user.slice/user-1000.slice/session-40.scope   (shared with sshd)
memory.max=max   cpu.max=max   pids.max=max

The reason is that an SSH session scope is a sibling of user@<uid>.service, not a child, and moving a process between them needs write access to their common ancestor user-<uid>.slice, which belongs to root. Namespace and seccomp isolation are unaffected — only the resource ceilings.

delonix system setup diagnoses it. It gives two remedies, in this order, because most answers online jump straight to the second one and it is usually not the one you need:

1. A delegated scope. No root, no reboot, works in the shell you are typing in. Try this first — on a distro that already delegates cpu (Ubuntu 24.04 ships Delegate=pids memory cpu on [email protected]) it is the whole fix, and editing /etc would only restate what is already there::

systemd-run --user --scope -p Delegate=yes -- delonix container run -d -m 512M myapp

…or, for anything long-lived, from a systemd user unit, which already gets a delegated cgroup::

[Service]
Delegate=yes
ExecStart=/usr/local/bin/delonix container run ...

2. A drop-in on [email protected] (sudo delonix system setup --delegate). Needs root and survives reboots. Worth writing when step 1 still reports cpu missing, or when you need --cpuset, --io-weight or the --device-* limits: container run refuses those (exit 69) while the container's cgroup lacks cpuset/io, and a scope cannot bring a controller [email protected] itself lacks. Under sudo the command reports on your user@<uid>.service, writes the drop-in and runs daemon-reload — then restart the user manager, which ends your sessions::

sudo systemctl restart user@$(id -u).service

daemon-reload alone is a false green: [email protected] lists the controllers while a new scope is still born without them. Logging out is not enough either when the user lingers or has another session open. And an SSH session-N.scope is a sibling of [email protected] and inherits nothing from it, so you still enter a scope afterwards.

Verify it took effect — this is the check worth putting in your provisioning::

systemd-run --user --scope -p Delegate=yes -- \
  delonix container run -d --name t -m 128M alpine sleep 60
# memory.max must read 134217728, not "max"

With delegation in place the engine applies the whole set: the per-container memory.max / cpu.max / pids.max, memory.swap.max=0 (so a limit bounds real memory and not just the resident set), memory.oom.group=1 (so an OOM kills the container, not one process inside it), and an aggregate ceiling on the parent sized from the host — the thing that stops N containers, none of which carry -m, from summing to more than the machine has.

Golden VM images ship no password

The golden VM images (delonix vm image pull / delonix vm image build) ship no password on any account: root and the delonix user are locked (passwd -l), and delonix has passwordless sudo. A password written in a public build recipe is not a secret, so none is baked into the published artefact.

Every supported way in authenticates with keys: cloud-init injects your --ssh-key on first boot, and delonix cluster kubeadm generates and uses its own. SSH password login is also disabled (PasswordAuthentication no, PermitRootLogin prohibit-password).

If you need the serial console (delonix vm console <name>) to accept a login — the case where a VM never got its network — that is your choice, made for your image or your VM, never a default:

.. code-block:: bash

at build time, only for the image you build

delonix vm image build --root-password '' ...

or per VM, in the cloud-init user-data you pass with --user-data

chpasswd: { expire: false, users: [{name: root, password: <...>, type: text}] }

Highlights

• No daemon. Every command is an ephemeral process that speaks straight to the kernel (clone(), namespaces, cgroups v2, pivot_root) and exits. State lives as JSON under $DELONIX_ROOT; opportunistic reapers sweep orphans (a slirp with no target, a hostfwd with no container).
• Rootless SDN. A single holder network namespace + delonix0 bridge + one shared slirp4netns, with nftables DNAT for port publishing. Because a published port is dataplane state, not container state, ports and volumes can be swapped hot, without restarting the container.
• Real pods. kind: Pod and delonix pod run N containers as one unit, sharing the pod's network namespace (same IP, localhost between them), IPC and UTS — a Kubernetes-style pod, rootless (PID sharing is a follow-up).
• Declarative microVMs. kind: VirtualMachine on a pluggable VmBackend (Cloud Hypervisor or libvirt), with per-instance cloud-init and libvirt system checkpoints (vm snapshot/restore), and vm pause/unpause to suspend vCPUs with memory intact. A remote Proxmox VE node plugs in as a third backend (see Remote providers_), and delonix provider ls says what each backend can do on this host, with the evidence for every "supported".
• Networks beyond the node. kind: NetworkZone declares a zone and its vnets on Proxmox's own SDN, kind: NetworkGateway puts aliases and rules on a perimeter firewall (OPNsense, ADR-0051), and kind: IPPool is a ledger of host addresses that routes claim instead of binding to loopback.
• An admission ceiling as code. kind: RuntimePolicy (group security.delonix.io) is the node's own limit — refuse --privileged, host networking, :latest, unlisted registries, device passthrough — checked by container run and vm create before anything is created. apply converges it like any Kind, but dropping it from the manifest does not remove it — only policy unset does.
• One workload model. kind: Workload (spec.type: container | vm | pod | microvm) is a single declarative object that lowers to Pod, VirtualMachine or Container at load time, and manages containers VMs from one imperative surface.

Kubernetes CRI conformance

delonix-cri is measured against cri-tools critest, the upstream suite, and the number is published rather than claimed: serves a kubelet is an assertion, 79 of 103 named specs is a fact somebody else can check.

::

Ran 103 of 122 Specs
79 Passed | 24 Failed | 19 Skipped        # rootless, cgroup v2

Reproduce with tests/compat/cri-conformance.sh. The full breakdown of what fails and why — including what is not ours — is in docs/cri-conformance.md <docs/cri-conformance.md>_.

Of the remaining failures, roughly half are not engine gaps: nine are AppArmor specs, which need CAP_MAC_ADMIN in the initial user namespace (Docker and containerd have exactly the same limit), and four are mount tests where the suite itself cannot mount on the host without root.

One divergence is deliberate and will not change to win a spec: a container with no seccomp profile declared runs under the engine's built-in allowlist, not unconfined. That is stricter than the specification asks for.

There is also a Docker Engine API compatibility layer, whose coverage is published the same way — delonix serve docker-api --matrix prints the routes that exist and the ones that deliberately do not, with the reason for each.

Install

One command — installs the binary and everything the runtime needs on the host (slirp4netns, uidmap/subuid ranges, nftables, VM backend), so a fresh machine is fully functional with no manual steps. Works on Debian/Ubuntu, Fedora/RHEL, openSUSE and Arch families (uses sudo for packages):

.. code-block:: bash

curl -fsSL https://github.com/ngolacloud/delonix/releases/latest/download/install.sh | bash

The installer detects your hardware (CPU features, RAM, disk, GPU) and picks the best binary for it — on x86-64, an x86-64-v3 (AVX2) build on modern CPUs and the generic x86-64 everywhere else; on aarch64 (arm64), the single native build — and applies the kernel tuning that containers, Kubernetes and VMs need (inotify limits, ip_forward, br_netfilter, overlay/tun modules, ...).

Before installing anything it verifies the release: SHA256SUMS is checked against its minisign signature with the public key embedded in the installer (minisign is installed if missing, and a missing tool or a bad signature aborts), and every downloaded binary is then checked against that SHA256SUMS. The script itself, run as curl … | bash, is not covered by this — download it first and check it against the signed SHA256SUMS if that matters to you (see docs/SECURITY-RELEASES.md <docs/SECURITY-RELEASES.md>_).

Flags (pass after bash -s --):

• --no-vm skips the microVM stack; --no-tune skips kernel tuning.
• --vm-provider <libvirt|cloud-hypervisor> is the node's default VM provider (default libvirt), written to /etc/delonix/providers.yaml (~/.config/delonix/ with --user) only when that file does not exist yet — an existing file, written by hand or by your provisioning, is never rewritten. A Proxmox VE node is added to that same file (ADR-0054).
• --no-gpu skips accelerator setup (the NVIDIA CDI spec, the render group). It is on by default and does nothing on a host without a GPU.
• --no-delegate does not write the cgroup delegation drop-in for [email protected]. Without delegation -m/--cpus/--pids-limit are inert; the installer already skips the drop-in when the distribution delegates cpu on its own.
• --no-binary configures dependencies and the host only, keeping the delonix already installed.
• --no-editor-plugin does not install the VS Code extension.
• --with-cri also installs delonix-cri (Kubernetes node).
• --low-ports allows publishing ports below 1024 (see below).
• --with-image-build installs what BUILDING VM images needs (libguestfs, a DHCP client for its appliance) and makes /boot/vmlinuz-* readable — that last step lowers a host security boundary, which is why it is opt-in and says how to revert it.
• --production raises the limits a busy node hits under load: conntrack table and hash size, ARP table, ephemeral ports, backlogs, pids, file descriptors, and LimitNOFILE/TasksMax on [email protected] (rootless containers are its children). Written to /etc/sysctl.d/99-delonix-production.conf and a drop-in.
• --performance applies, without asking, the CPU performance mode (governor, EPP, power profile), transparent hugepages in madvise plus irqbalance, and a disk GC timer (system prune --auto at 75% full, never touching volumes). Without it — and without --no-performance — the installer ASKS for each (Enter = yes); with no terminal the answer is no. The CPU and hugepage settings live in delonix-performance.service, which restores the boot-time values on stop: systemctl disable --now delonix-performance reverts them.
• --insecure-skip-signature skips the signature check — only for debugging, or a release from before signing existed. You lose the only proof that the binary came from this project.

Publishing port 80 or 443 (-p 80:80) needs --low-ports:

.. code-block:: bash

curl -fsSL .../install.sh | bash -s -- --low-ports

Without it, -p 80:80 is refused — the host-side bind is done by slirp4netns as your unprivileged user, and the kernel reserves ports below net.ipv4.ip_unprivileged_port_start (1024 by default). Rootless Podman and Docker hit the same wall. The flag is opt-in because it lowers that threshold to 80 for the whole host: from then on any local program can bind 80-1023. On a workstation that is a fair trade; on a shared or production machine, the alternative that lowers nothing is a root-owned proxy on port 80 (nginx/haproxy/systemd socket activation) forwarding to a high port. It writes /etc/sysctl.d/99-delonix-lowports.conf — delete it to revert.

Manual alternative (binaries only — you install the runtime deps yourself). delonix is one of four binaries: delonix mcp runs delonix-mcp, delonix serve api runs delonix-mgmt and delonix serve cri runs delonix-cri, each looked up next to delonix first and then on the PATH, and a server from another release refuses to start. Without them those three commands refuse; everything else works with delonix alone. Check the signature and the checksums before installing — the public key is the MINISIGN_PUBKEY line of the release's install.sh (take it from a copy you already trust, not from the same download you are verifying):

.. code-block:: bash

BASE=https://github.com/ngolacloud/delonix/releases/latest/download ARCH=x86_64 # or aarch64 cd "$(mktemp -d)" for f in SHA256SUMS SHA256SUMS.minisig
delonix-$ARCH-linux delonix-mcp-$ARCH-linux delonix-mgmt-$ARCH-linux; do curl -fsSLO "$BASE/$f" done minisign -Vm SHA256SUMS -P '<MINISIGN_PUBKEY from install.sh>' sha256sum -c SHA256SUMS --ignore-missing install -m 0755 delonix-$ARCH-linux ~/.local/bin/delonix install -m 0755 delonix-mcp-$ARCH-linux ~/.local/bin/delonix-mcp install -m 0755 delonix-mgmt-$ARCH-linux ~/.local/bin/delonix-mgmt echo 'source <(delonix completion shell bash)' >> ~/.bashrc

Add delonix-cri-$ARCH-linux the same way for a Kubernetes node.

Quickstart

.. code-block:: bash

a web service on host port 8080 — no root, no daemon

delonix container run -d --name web -p 8080:80 nginx curl localhost:8080

delonix container stats # CPU / memory / PIDs (cgroup v2) delonix container logs -f web # follow logs delonix container update web --publish-add 9090:80 # hot re-publish delonix container stop web # the port closes by itself delonix container start web # restart with the same state

Command groups

The CLI is grouped semantically; every group has --help and most accept a per-Kind manifest via apply -f. Every list command also takes -o json for stable, language-independent output (ADR-0005). Full, always-current reference (embeds the real --help) at https://ngolacloud.github.io/delonix/cheatsheet.html.

Since v2.0.0 the surface has two halves that mean the same thing. The imperative groups below are the ones you type by hand (container ps, volume ls); the generic verbs — get · describe · delete · apply · plan · diff · drift · wait · explain · api-resources — address the same resources by Kind and plural (get volumes, describe networks lab), which is what a script or a kubectl-shaped habit wants. delonix api-resources prints the whole catalogue: plural, shortnames, apiVersion, and the FORM of each Kind (primary, sugar → X, sunset → X).

.. list-table:: :header-rows: 1 :widths: 16 84

• • Group
  • What it does
• • init
  • Starts the RIGHT project for this directory: detects, says what it detected and why, and dispatches to stack init/vm init.
• • container
  • Lifecycle: run, ps, start, stop, rm, exec, logs, inspect, stats, update, apply.
• • pod
  • Real multi-container pods (kind: Pod): create, logs, exec, cp, attach, port-forward — N containers sharing netns/IPC/UTS as one unit. Listing and removal go through get pods/delete pods.
• • vm
  • Declarative microVMs: create, ls, start, stop, pause/unpause, destroy, console, ssh, apply, snapshot (create/ls/rm/restore), migrate.
• • systemcontainer
  • One-off operations on a system container (kind: SystemContainer, ADR-0058): snapshot create|ls|rm|restore, clone, move; backup create systemcontainer archives on the provider
• • workload
  • Unified compute layer over containers and VMs (ADR-0002): ls, describe, stop, rm — creation stays declarative via kind: Workload.
• • image
  • OCI images: pull, ls, remove, export, scan, sign, verify. vm image <cmd> for golden VM images (build/import/push/convert).
• • build
  • Build an image from a Dockerfile or Delonixfile (no daemon, no BuildKit).
• • oci-runtime
  • runc-compatible runtime CLI (ADR-0080): create/start/state/kill/delete a container from an OCI bundle, driving the engine's own init behind the runc contract — so it can sit where runc/crun do.
• • run · create · ps · start · stop · restart · rm · exec · · · · · · · · · · ·

Remote providers

The local VM backends (libvirt, Cloud Hypervisor) need no configuration. A remote one does — an endpoint, a node and a credential — and it is read from the environment when delonix starts. Nothing is contacted until a command selects it, and a misconfigured target prints a warning instead of stopping unrelated commands.

For Proxmox VE (one node, ADR-0008), keep the credential in the vault rather than in the shell history:

.. code-block:: bash

read -rs PVE_TOKEN_SECRET && export PVE_TOKEN_SECRET # never in argv delonix secret create pve-api --from-literal tokenId='root@pam!delonix'
--from-env tokenSecret=PVE_TOKEN_SECRET export DELONIX_PROXMOX_URL=https://pve.example:8006 export DELONIX_PROXMOX_NODE=pve # the name GET /nodes reports export DELONIX_PROXMOX_SECRET=pve-api # tokenId+tokenSecret, or username+password export DELONIX_PROXMOX_CA_FILE=/etc/ssl/pve-ca.pem # node signed by an internal CA delonix provider ls # proxmox: NotConfigured -> NotProbed delonix vm create web --backend proxmox --disk local-lvm:8

provider ls never contacts the node — the first VM operation is what authenticates. DELONIX_PROXMOX_TOKEN_ID with DELONIX_PROXMOX_TOKEN (or DELONIX_PROXMOX_TOKEN_FILE, a chmod 600 file), and DELONIX_PROXMOX_USER with DELONIX_PROXMOX_PASSWORD, are accepted too; DELONIX_PROXMOX_BRIDGE and DELONIX_PROXMOX_VLAN set how the node is cabled. DELONIX_PROXMOX_INSECURE_TLS=1 switches certificate verification off — another machine answering in the node's name then receives the credential, so prefer the CA file. The same variables register the Proxmox SDN behind kind: NetworkZone. An OPNsense appliance (kind: NetworkGateway, ADR-0051) is registered the same way through DELONIX_OPNSENSE_URL and DELONIX_OPNSENSE_CREDENTIAL (a secret with key and secret). The full list, with what reads each variable, is in docs/dev/environment-variables.md <docs/dev/environment-variables.md>_.

Languages

The CLI speaks English by default. --l18n=pt (or DELONIX_L18N=pt) switches everything — including --help — to Portuguese, served from a standard gettext catalog embedded in the binary (data/pt.po <bins/delonix-runtime-bin/data/pt.po>_). Adding a language is adding a .po file; no code changes. Containers started without --name get readable names drawn from Angolan kings, queens and places (njinga-benguela-07) — the project's naming identity.

Manifests

The declarative face, Kubernetes-style: a multi-document YAML applied in dependency order by delonix stack apply. The list of Kinds is not written here — it is printed by the engine, which is the only copy that cannot go stale:

.. code-block:: console

$ delonix api-resources NAME SHORTNAMES APIVERSION KIND ... pods po compute.delonix.io/v1alpha1 Pod ... virtualmachines vm compute.delonix.io/v1alpha1 VirtualMachine ... networks net networking.delonix.io/v1alpha1 Network ...

Each Kind lives in the group of its domain — compute, networking, gateway, storage, artifact, core, infrastructure and security (the node's own admission ceiling, RuntimePolicy), all <group>.delonix.io/v1alpha1; api-resources is the count, since any number written here goes stale with the next Kind. apiVersion: delonix.io/v1 is still accepted everywhere — a Kind takes its own group or the legacy one, and nothing else.

Four of them are not destinations: Workload and Dependency are sugar that lowers at load time, Ingress is the k8s spelling of an HTTPRoute, and Container is on its way out in favour of Pod. The FORM column says which is which, so a manifest never has to guess.

Storage, ShareVolume and Egress were removed in v0.65.0 — each was a second way to say something a surviving Kind already said. Writing one now is refused by name, with the replacement spelled out.

It converges (since v0.47.0): stack plan shows what would change and why, stack apply reconfigures ports, volumes, networks, memory and CPU hot, with the PID unchanged, and refuses — naming the field — anything that would need a recreate, unless you pass --replace. There is no state file: the last applied spec lives on the resource itself (delonix.io/last-applied) and ownership is the delonix.io/stack label, so a resource created by hand is adopted and one belonging to another stack is never touched. stack destroy removes what the stack owns, in reverse order. --detailed-exitcode returns 0/2/1 like terraform plan, which makes a drift gate in CI one command; a plan holding a resource another stack owns returns 5, the conflict the apply would refuse it with.

The schema is generated from the code (delonix manifest schema, delonix explain Pod.containers) and published, so an editor gives you completion and type checking from one comment at the top of the file. It catches a typo in a field name, a kind the engine does not know, and an apiVersion that is not that Kind's group — the editor and stack apply cannot disagree, because they read the same file.

There is a VS Code extension that wires this up and adds a template per Kind: angolardevops/delonix-vscode <https://github.com/angolardevops/delonix-vscode>_. It works in VS Code and in the forks that share its extension CLI (VSCodium, Cursor, Windsurf, Antigravity); install.sh installs it into whichever it finds, unless you pass --no-editor-plugin.

See also the stability promise <docs/cli-stability.md>, the resource structure <docs/estrutura.md> and the GitOps guide <docs/gitops.md>_.

kind: Pod is a real multi-container pod: N containers sharing the pod's netns (same IP, localhost between them), IPC and UTS — managed as a unit with delonix pod.

kind: Workload (spec.type: container | vm | pod | microvm) is a single declarative object for both compute types: it lowers to the matching Kind at load time (type: microvm pins the Cloud Hypervisor backend), so one schema covers everything. The imperative day-2 side is delonix workload ls/describe/stop/rm, which routes by name across containers and VMs.

.. code-block:: yaml

apiVersion: networking.delonix.io/v1alpha1 kind: Network metadata: { name: backend }

apiVersion: compute.delonix.io/v1alpha1 kind: Pod metadata: { name: db } spec: network: backend containers: - name: db image: postgres:16-alpine ports: - { containerPort: 5432, hostPort: 5432 } volumeMounts: - { name: data, mountPath: /var/lib/postgresql/data } volumes: - { name: data, persistentVolumeClaim: { claimName: data } }

apiVersion: networking.delonix.io/v1alpha1 kind: NetworkPolicy # L4 firewall, k8s-NetworkPolicy style metadata: { name: db-in } spec: target: db direction: ingress defaultPolicy: deny rules: - { proto: tcp, port: "5432", from: 10.219.0.0/16 }

Architecture

The crates of the workspace, in five layers (ADR-0040) — the directory a crate lives in is its layer, and scripts/arch_fitness.py fails when the two disagree — one delonix command, no residing process:

.. list-table:: :header-rows: 1 :widths: 26 74

• • Crate
  • Responsibility
• • Foundation — pure, no mechanism
• • delonix-model
  • The shared model: the error type and the DX-CDNN code dictionary, Status, firewall rules, the secret model, typestate, generated names, exit classes.
• • delonix-net-rules
  • Pure network rules with zero dependencies: CIDRs, bridge names, IPAM inside a prefix, rate parsing.
• • Contexts — use cases and ports
• • delonix-compute
  • Containers, pods and VMs: the one run specification, the Container/Vm records, the compute ports.
• • delonix-stack
  • Manifests: the Kind table, the three-way reconciler, conditions and revisions.
• • delonix-node
  • The node: the event log, host checks, local-socket peer credentials, the dispatch contract, host/process queries.
• • delonix-security-runtime
  • Security decisions: policy, the single admission point for containers and VMs, events, score, redaction.
• • Adapters — one technology each
• • delonix-linux
  • The container runtime on the Linux kernel: namespaces, cgroups v2, mounts, capabilities, seccomp, exec, reconcile.
• • delonix-sdn
  • Rootless SDN: holder netns + bridge + single slirp, nft DNAT/firewall, internal DNS, DHCP, WireGuard overlay, CNI client.
• • delonix-oci
  • OCI images: pull (digest-verified), CAS, layers, build, export, buildpacks, signatures, internal registry.
• • delonix-state
  • Persisted state: Store/JsonStore behind flock, atomic writes, the encrypted secret vault.
• • delonix-vm
  • Declarative microVMs (VmBackend: Cloud Hypervisor / libvirt), cloud-init.

See the architecture page <https://ngolacloud.github.io/delonix/arquitectura.html>_ and the C4 model <https://ngolacloud.github.io/delonix/c4.html>_ for the full picture.

Appendix — features by release

The complete, always-current changelog lives in docs/RELEASES.md <docs/RELEASES.md>_ — one section per release, newest first, regenerated automatically by the release pipeline on every published tag (source of truth: docs/releases/<tag>.md, the same notes published on GitHub Releases).

Community

CONTRIBUTING.md <CONTRIBUTING.md>_ for how to send a change (and the contributor handbook <https://ngolacloud.github.io/delonix/handbook/>_ for everything behind it — environment, build, architecture, crates, conventions), the Rust tutorial <https://angolardevops.github.io/delonix-rust-tutorial/>_ (Português de Angola) if you are new to Rust or to how containers work underneath, GOVERNANCE.md <GOVERNANCE.md>_ for how decisions get made and by whom, MAINTAINERS.md <MAINTAINERS.md>_ for who that is today, CODE_OF_CONDUCT.md <CODE_OF_CONDUCT.md>_ for how we expect people to treat each other, and SECURITY.md <SECURITY.md>_ for reporting a vulnerability privately instead of in a public issue.

License

Apache-2.0. See LICENSE <LICENSE>_.