Deeploy: Decentralized Container Orchestration

• Deeploy is a decentralized container orchestration framework that distributes control across edge and cloud nodes rather than relying on a single central scheduler.
• It employs diverse architectures such as blockchain, peer-to-peer networks, and component-aware overlays to optimize QoS parameters including latency, cost, and energy consumption.
• Real-world evaluations and simulations suggest that decentralized decision-making and predictive scaling can significantly enhance deployment efficiency and resource management.

Decentralized container orchestration, often discussed under the label “Deeploy” in parts of the recent literature, denotes orchestration schemes in which deployment, resource discovery, admission control, placement, monitoring, and lifecycle management are not concentrated in a single central scheduler or master node. Instead, control is distributed across edge devices, resource agents, peer-to-peer coordination layers, smart contracts, oracle nodes, or in-container control elements, depending on the architecture. In the cloud-edge continuum, this shift is motivated by heterogeneous hardware, dynamic workloads, multi-provider deployment, and the need to align placement decisions with application QoS goals such as latency, bandwidth, cost, energy, and reliability. Recent work spans a fully decentralized, event-driven edge framework using blockchain, IPFS, MQTT, Docker, and predictive vertical scaling; an application-centric swarm-inspired orchestrator for cloud-edge microservices; a decentralized managed orchestration layer embedded in a broader blockchain-based AI meta-OS; and a component-aware orchestration stack that decouples software-component lifecycle from container lifecycle while retaining Docker Swarm or Kubernetes as the execution substrate (Özyar et al., 2022, Ullah et al., 1 Apr 2025, Damian et al., 5 Sep 2025, Bogo et al., 2020).

1. Conceptual scope and definitional boundaries

A recurrent premise in this research area is that conventional container orchestrators optimize containers as the principal unit of control, whereas decentralized orchestration attempts to distribute decision-making across a wider control surface. In the cloud-edge continuum, Swarmchestrate is presented as a decentralised, application-centric orchestration architecture “inspired by the self-organising principles of Swarms,” with the explicit goal of optimizing deployment for a submitted application’s QoS goals rather than for a resource provider’s local efficiency. Its Orchestration Space has no central control and is built from Resource Agents and Swarm Agent networks, with the deployment phase validated in simulation (Ullah et al., 1 Apr 2025).

A second line of work frames Deeploy as an end-to-end decentralized orchestration framework for containerized applications at the edge. Here, each node runs its own orchestration stack, images are delivered through IPFS and blockchain metadata, and coordination is event-driven through MQTT publish/subscribe. The decomposition into Monitor, Deployer, Analyzer, and Forecaster follows a MAPE-K-style loop, so decentralization applies both to deployment admission and to run-time optimization (Özyar et al., 2022).

A third formulation appears in Ratio1, where Deeploy is the decentralized managed container orchestration layer of a larger AI meta-OS. In this design, orchestration is “analogous to a cloud controller but without any central server,” and placement is consensus-driven through smart contracts, oracle nodes, and an internal oracle blockchain. This is a trust-minimized, licensed orchestration model rather than an anonymous open marketplace (Damian et al., 5 Sep 2025).

By contrast, component-aware orchestration for enterprise applications is best understood as an adjacent but not fully decentralized approach. It argues that Docker Swarm and Kubernetes treat containers as “black-boxes” and therefore cannot manage the lifecycle of the components running inside them. The proposed Manager–Unit scheme decouples component lifecycle from container lifecycle, but the control architecture remains manager-centered rather than peer-to-peer (Bogo et al., 2020).

Taken together, these systems show that “decentralized container orchestration” is not a single architectural pattern. It includes fully distributed edge control loops, hybrid peer-to-peer orchestration with centralized aggregation at an initiating agent, blockchain-mediated consensus control planes, and component-aware overlays that preserve a central coordinator. This suggests that the term is best treated as a family of control architectures rather than a single protocol class.

2. Architectural patterns and control substrates

The main architectures differ in how they distribute authority, where state is stored, and what object is being orchestrated: containers, components, applications, or AI services.

System	Main control elements	Coordination substrate
Deeploy edge framework (Özyar et al., 2022)	Monitor, Deployer, Analyzer, Forecaster	blockchain, IPFS/IPDR, MQTT, Docker, cgroups
Swarmchestrate (Ullah et al., 1 Apr 2025)	Resource Agents, Swarm Agent networks, Knowledge Management, Orchestration Space	P2P-like RA network, distributed knowledge base, Kubernetes execution
Ratio1 Deeploy (Damian et al., 5 Sep 2025)	decentralized REST API, UI/UX console, SDK, smart contracts, OracleSync, dAuth, CSTORE/ChainStore, R1FS	internal oracle blockchain, on-chain proofs, oracle consensus
Component-aware orchestration (Bogo et al., 2020)	Manager, Unit, Supervisor, tini, Packager	REST API, XML-RPC, Docker Compose, Docker Swarm, Kubernetes translation

In the edge Deeploy framework, decentralization is achieved by placing orchestration logic on-device. Blockchain stores trusted application metadata and ownership; IPFS, via IPFS-Backed Docker Registry, provides decentralized image storage; MQTT carries asynchronous orchestration events; Docker and Linux cgroups provide runtime enforcement. The Analyzer acts as a decentralized resource manager, working with the Forecaster so that admission and scaling decisions depend on predicted future availability rather than only instantaneous measurements (Özyar et al., 2022).

Swarmchestrate’s architecture is explicitly application-centric. Applications are described in TOSCA and include container/component specifications, resource requirements, QoS goals, and monitoring specifications. Resources are exposed through a two-level abstraction of Resources and Capacity, and the distributed Knowledge Management layer stores resource capabilities, descriptions, interactions, and decision-related information. The Orchestration Space is defined as the confluence of decentralisation, swarms, and intelligence, with Resource Agents serving as the interface layer and Swarm Agent networks managing individual application swarms after deployment (Ullah et al., 1 Apr 2025).

Ratio1’s Deeploy is structurally different because orchestration is embedded in a broader trust stack. dAuth verifies the relationship between the KYC/KYB’d owner wallet, the Node Deed license NFT, and the associated Edge Node; CSTORE/ChainStore supplies decentralized in-memory state synchronization; R1FS provides content-addressed storage; EDIL supports encrypted decentralized inference and learning; OracleSync attests telemetry, uptime, and completion; and smart contracts mediate escrow, rewards, and enforcement. Deeploy is therefore not a standalone scheduler but the orchestration surface of an authenticated, state-synchronized, proof-driven system (Damian et al., 5 Sep 2025).

The component-aware architecture addresses a different granularity. TOSCA models applications as service templates whose topology templates are typed directed graphs composed of node templates and relationship templates. The Packager transforms the CSAR and optional configuration into “toskosed” images and a Docker Compose artifact; each component-hosting container receives a Unit bundle, while a Manager container exposes a RESTful API and forwards lifecycle operations to Units via Supervisor’s XML-RPC interface. Existing orchestrators still provide placement, networking, scaling, and recovery (Bogo et al., 2020).

3. Orchestration workflows and lifecycle semantics

Swarmchestrate defines a deployment workflow from application submission to deployment. A TOSCA-based application description is submitted to the Orchestration Space interface. A Resource Agent, denoted RA-X, is selected to initiate orchestration; in the prototype this choice is random. RA-X broadcasts requirements to all Resource Agents in the P2P network. Each Resource Agent checks its Capacity through Knowledge Management and reports partial, full, or zero coverage. RA-X then generates all unique combinations of RA-component matches such that each application component appears exactly once in a candidate offer, ranks these offers according to QoS objectives and reliability, selects a Lead Resource to host the lead Swarm Agent and the Kubernetes control plane, and proceeds with swarm formation and application deployment. The broader vision includes monitoring, self-organization, lead-resource replacement, dynamic resource addition, and reconfiguration, but runtime reconfiguration is not implemented in the reported study (Ullah et al., 1 Apr 2025).

The edge Deeploy framework separates application delivery from application orchestration. In the delivery path, a developer uploads a Docker image to IPDR/IPFS, receives an image hash, and registers image metadata and optional resource limits through a blockchain smart contract. In the orchestration path, a user or IoT device submits a deployment request through the Deployer REST API; the Deployer retrieves the image hash and resource metadata from the blockchain, pulls the image from the registry/IPFS, and publishes a deployment analysis request over MQTT. The Analyzer evaluates feasibility using predicted resource availability. If accepted, the Deployer launches the container with target limits; if rejected, it may retry with lower base limits. Runtime monitoring then feeds optimization requests back into the system so that CPU and memory limits can be adjusted through Docker (Özyar et al., 2022).

Ratio1 Deeploy adds licensing, escrow, proof, and settlement to the lifecycle. A participant undergoes KYC/KYB, buys a Node Deed using R1, associates an Edge Node with that deed on-chain, and passes dAuth verification. A user or dApp submits a container app or AI microservice through the Deeploy API or SDK. For Proof-of-AI jobs, a smart contract escrows the minimum prepayment before execution. A set of orchestrator/oracle nodes then determines placement through randomized selection, round-robin allocation, and resource availability checks; the mapping from containers to nodes is written to the internal oracle blockchain. Selected Ratio1 Edge Nodes execute OCI-compliant apps and legacy migrated containers, while heartbeats and telemetry are collected and aggregated by OracleSync for epoch finalization and reward settlement. If service expectations are not met, penalties may be applied and the job may be transferred (Damian et al., 5 Sep 2025).

The component-aware workflow begins from a TOSCA CSAR. The pipeline validates the TOSCA specification, optionally validates and completes a Toskose configuration file, enriches the model with aliases, ports, Manager settings, and runtime metadata, generates build contexts for Units and the Manager, builds multi-stage Docker images, and emits a Docker Compose deployment artifact. Deployment can proceed directly on Docker Swarm, or on Kubernetes after translation via Kompose or Compose-on-Kubernetes. Once running, the Manager API can issue lifecycle operations such as create, configure, start, stop, and delete to individual components without stopping their hosting containers (Bogo et al., 2020).

Across these workflows, the operational meaning of decentralization varies. In Swarmchestrate, evaluation is distributed across Resource Agents but ranking is aggregated at the initiating RA. In the edge Deeploy framework, each node independently participates in the control loop and cluster placement emerges from comparing device-local views of availability. In Ratio1, placement is decentralized through consensus and proofs. In the component-aware system, lifecycle control is finer-grained than standard container orchestration, but authority is centralized in the Manager. A plausible implication is that “decentralized orchestration” can refer either to the locus of scheduling authority or to the granularity at which lifecycle control is exposed.

4. Scheduling logic, predictive control, and formal models

Swarmchestrate’s decision logic is QoS-oriented. Each Resource Agent uses a first-fit matching strategy when mapping components to capacity, with components sorted by CPU requirement; to avoid bias, half the Resource Agents sort in ascending CPU order and the other half in descending order. After feasible offers are generated, ranking proceeds through normalized QoS attributes and reliability-aware scoring. For each attribute $q \in Q$, the paper normalizes raw data $r_q$ as

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$

and computes

$$\text{total\_cost}_i = \sum_{q \in Q} p_q \cdot \text{normalised}_{q,i}.$$

Reliability is then incorporated additively as $\text{total\_cost}_i - R_i$ or multiplicatively as $(1-R_i)\cdot \text{total\_cost}_i$. The Borda formulation uses

$S_i = \sum_{q \in Q} p_q \cdot \text{score}_q(i),$

with reliability added as $$\text{score}_R(i) + \sum_{q \in Q} p_q \cdot \text{score}_q(i)$$ or multiplicatively as $R_i \sum_{q \in Q} p_q \cdot \text{score}_q(i)$. The decision criteria explicitly include latency, cost, bandwidth, energy consumption, and reliability (Ullah et al., 1 Apr 2025).

The edge Deeploy framework formalizes admission and vertical scaling around predicted resource availability. Deployment is accepted if

$L^{target}_{r,c} \le P^{avail}_{r,S},$

where $r_q$0 is the target resource limit for resource $r_q$1 of container $r_q$2, and $r_q$3 is the predicted available resource $r_q$4 on system $r_q$5. The Forecaster uses ARIMA(5,1,0), trained on hourly aggregated resource data, to predict future utilization. Predicted utilization is adjusted as

$r_q$6

and availability is updated after optimization by

$r_q$7

CPU upscaling and downscaling follow

$r_q$8

or

$r_q$9

with throttling-aware correction through

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$0

and a post-downscale safety rule

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$1

where the implementation fixes the buffer at $$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$2 (Özyar et al., 2022).

Ratio1 Deeploy does not provide a dedicated placement optimizer or pseudocode scheduler, but it does formalize the incentive environment that constrains orchestration. The oracle selection principle is stated as minimizing failure probability subject to a cost budget. Reward is proof-driven:

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$3

Availability-based minting is specified as

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$4

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$5

with

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$6

and

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$7

Oracle-consensus-derived availability is written as

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$8

and Proof-of-AI execution rewards are given by

$$\text{normalised}_q = \begin{cases} 0, & \text{if } \max(r_q)=\min(r_q) \ \frac{r_q-\min(r_q)}{\max(r_q)-\min(r_q)}, & \text{otherwise} \end{cases}$$9

These equations do not define placement directly, but they formalize the availability and execution-proof regime in which placement occurs (Damian et al., 5 Sep 2025).

The component-aware system is less mathematical, but it introduces a formal TOSCA metamodel. A service template comprises a topology template and the types needed to build it; the topology template is a typed directed graph whose node templates model components and whose relationship templates model relations among them. The operative lifecycle interface is “create, configure, start, stop, delete,” and each such operation is mapped to a Supervisor program section exposed via XML-RPC from inside the container (Bogo et al., 2020).

5. Execution substrates, heterogeneity, and empirical validation

The heterogeneity targeted by these systems is substantial. Swarmchestrate addresses cloud-edge resources from providers such as AWS or Azure, grouped into Capacities and discovered through the distributed knowledge layer. The prototype was implemented in the DISSECT-CF-Fog discrete-event simulator, extended with Resource Agent, Capacity, orchestration behavior, and offer collection and ranking. The simulated infrastructure contained 8 capacities, each represented by one Resource Agent, a mix of cloud-like and edge-like nodes, Resource Agent nodes consuming 1 CPU core and 1 GB RAM of host capacity, and a Docker Hub-like image registry with 1000 Mbps bandwidth. Six applications were submitted simultaneously, each with four components—three compute and one storage—and capacity settings varied by location, provider, CPU, RAM, storage, power, latency, and price. Evaluation reported Simulation Time, Total Price, Avg. Deployment Time, and Total Energy. Priority-aware ranking improved the targeted metric; the cost-based method often produced the best values for the most prioritized QoS objective; Borda voting was competitive but generally weaker in the reported experiments; bandwidth-aware selection performed especially well in deployment efficiency; latency-aware selection reduced deployment time; and energy-aware selection shifted load patterns and energy accumulation over time (Ullah et al., 1 Apr 2025).

The edge Deeploy framework was evaluated on Raspberry Pi 4 Model B hardware with a 64-bit quad-core Cortex-A72 CPU and 8 GB LPDDR4-3200 SDRAM, while the orchestration stack was constrained to a slice with 1 CPU and 1 GB memory and swap disabled. CPU usage of most framework components was negligible, the Forecaster used all available CPUs during forecasting, IPFS used about 50–250 mCPU on average, and the total framework memory footprint was about 400 MB. The experiments covered five workload patterns—slowly rising/falling, drastically changing, on-off, gently shaking, and real-world—instantiated as five memory-dominant and five CPU-dominant workloads. With ample limits, optimization converged resource limits toward actual usage within a few cycles. With very low limits, memory workloads often failed initially, while CPU workloads were accepted but throttled until optimization raised limits. Interleaved deployment showed that the system could adapt to new containers without disrupting stabilized ones. In a 3-device cluster, deployments were distributed according to the decentralized resource-availability rule, and the paper reports no noticeable latency overhead beyond one additional event over the cluster/deploy topic (Özyar et al., 2022).

The component-aware architecture was validated through the “Thinking” application, consisting of MongoDB, a Java REST API on a Maven container, a NodeJS GUI, and a Logsniffer sidecar. The Packager generated a Docker Compose file including the Manager container, wrapping the Maven and Node containers with Unit support and leaving MongoDB as a standard container. Deployment was demonstrated on Docker Swarm over a 4-VM cluster and on Kubernetes via Kompose and Compose-on-Kubernetes. The Manager API then created, configured, and started the API, pushed default data, created and started the Log component, and created, configured, and started the GUI. Crucially, the API could be stopped and restarted without stopping the Maven container, while the Log component remained running (Bogo et al., 2020).

For Ratio1 Deeploy, performance discussion is more architectural than experimentally specific to orchestration. The paper states that horizontal scaling is expected by adding more Ratio1 Edge Nodes, that ideal execution time can decrease roughly as $$\text{total\_cost}_i = \sum_{q \in Q} p_q \cdot \text{normalised}_{q,i}.$$0 for parallelizable workloads, and that overheads arise from network communication, coordination, and encryption. It also reports under-10% slowdown for encrypted inference in some latent-space experiments and near-linear throughput in a synthetic training workload over 10 RENs, although those observations are discussed more in the EDIL context than in Deeploy alone. Deeploy itself is described as supporting OCI-compliant containers, legacy container migration, privileged container execution, low-code app deployment, SDK-driven container launch, tunneling such as ngrok for NAT/firewall traversal, and AI inference and training on heterogeneous devices ranging from laptops and smartphones to cloud VMs and servers (Damian et al., 5 Sep 2025).

6. Limitations, misconceptions, and research trajectories

A common misconception is that decentralization automatically implies a fully peer-to-peer, production-complete, and permissionless control plane. The literature does not support that simplification. Swarmchestrate is explicit that the reported work covers only the deployment phase; runtime reconfiguration and live self-organization remain under development, the system is still a proof-of-concept, and scalability, robustness, trust, security, and dynamic connectivity handling require further validation beyond simulation. Future work includes finalizing self-organization, implementing the framework fully, and prototyping on four real industrial use cases (Ullah et al., 1 Apr 2025).

The edge Deeploy framework is fully decentralized in control structure, but its optimization scope is limited to vertical scaling based on system metrics—CPU utilization, memory utilization, and CPU throttling percentage—rather than application-level signals. Its cluster load balancing rule is deliberately simple: each device selects the node with the most available resources, and ties are broken by the smallest IP address. This suggests a design optimized for lightweight edge coordination rather than globally optimal placement (Özyar et al., 2022).

Ratio1 Deeploy is decentralized, but not open-anonymous. Only licensed Node Deed holders can participate, node ownership is tied to EVM-compatible identity, and oracle supervision and deactivation policies are built into the trust model. The paper does not fully specify Deeploy’s internal scheduling algorithm, does not provide a formal placement optimization objective or bin-packing model, and relies on oracle honesty assumptions, with the claim that consensus remains valid if fewer than one-third of oracle nodes are Byzantine. It also assumes baseline hardware requirements and acknowledges that consumer-grade edge nodes can be tampered with if not hardened, motivating future work on secure boot, code signing, and integrity attestation (Damian et al., 5 Sep 2025).

The component-aware architecture resolves a different limitation—container-level opacity—but remains manager-centered. The administrator must currently issue lifecycle operations in the correct sequence, component-aware scaling and self-healing are still future work, and Kubernetes deployment depends on translation tools such as Kompose or Compose-on-Kubernetes. It is intentionally not a replacement for production orchestrators, but a higher-level control layer that reuses their scheduling, overlay networking, scaling, and recovery mechanisms (Bogo et al., 2020).

These differences also clarify the relation of Deeploy-style systems to adjacent work. Swarmchestrate explicitly situates itself against mF2C, Oakestra, HYDRA, Caravela, and decentralized fog placement approaches, emphasizing a hybrid decentralized architecture with P2P Resource Agents and swarm-based application management. Ratio1 contrasts Deeploy with decentralized compute platforms such as iExec and Golem, and with decentralized container marketplaces such as Akash/Aethir-like systems, arguing that orchestration must be integrated with authentication, storage, privacy, monitoring, and settlement to support AI pipelines. Component-aware orchestration, in turn, shows that finer-grained lifecycle control can be layered on top of Docker Swarm and Kubernetes even when the control plane itself is not decentralized (Ullah et al., 1 Apr 2025, Damian et al., 5 Sep 2025, Bogo et al., 2020).

The broader research trajectory points toward three converging themes. First, decentralized orchestration increasingly treats application requirements, not just infrastructure efficiency, as the optimization target. Second, trustworthy execution requires more than placement; it also requires authenticated nodes, auditable state, and proof-based monitoring or settlement. Third, heterogeneity forces orchestration to operate across multiple abstraction levels: components inside containers, containers across devices, and applications across the cloud-edge continuum. This suggests that Deeploy, in its various forms, is best understood as a shift from centralized scheduling toward distributed control regimes in which placement, adaptation, and verification are jointly orchestrated rather than separately engineered.