Distributed execution as a language property, not an infrastructure job
How Mélodium spreads a program across machines with no containers, images, or deployment plan
Running a program across several machines today means cutting it up by hand first. You define software components, entry points in the code, you create containers, you build system images with the right interpreter and the right dependencies, and you configure the orchestrator with the list of elements it can call and how to instantiate them. Each software element is tied to a specific context, each machine has to host an environment compatible with what it runs. Two software blocks that need to exchange data, that gets designed and coded carefully, and it takes operational work.
Mélodium removes this separation. Instead of adjacent, isolated software components, each software element is a node in its own right, with its inputs and outputs, written into the larger program, and the Mélodium execution engines share the work among themselves at runtime.
Distribution without friction
A first engine is launched with the identifier of a node (“treatment” in Mélodium) as its entry point, the way any program is launched from a “main function” in other languages. Parameters can be supplied depending on what the treatment offers, just as they would for a function.
That engine then runs the treatment, which can itself be made of sub-treatments. If a sub-treatment needs resources the first engine can’t provide (more memory, disk space, processors, a graphics card, specific hardware, a particular operating system, or any other reason at all, objective or arbitrary), it can ask an orchestrator to instantiate a second engine, connect to it, and hand over the treatment concerned. The two engines then exchange the treatments’ input and output data across the connection, without changing functional behaviour. And the second engine can likewise ask an orchestrator for a new engine, and so on.
No distribution plan has to be drawn up in advance. The engines decide as execution goes. Orchestrators of various kinds (OS, Kubernetes, cloud provider APIs, OpenStack…) don’t disappear, but they no longer handle instantiating the software or preparing environments. They launch the Mélodium engines, which then share the load among themselves.
A program is a graph, not a sequence of instructions
This mechanism isn’t an infrastructure layer sitting on top of your code. It’s the programming model. A Mélodium program is a graph of treatments, compute nodes connected by typed data flows. No procedural flow, no line-by-line instructions, each treatment runs as soon as its data arrives.
Take a theoretical program. A treatment A rests on two others, B and E; B breaks down into C and D, E into F and G, and F into H and I. Here’s that composition tree:
That tree says who depends on whom, not how the data moves. In Mélodium, connections are explicit and typed, input by input, output by output. Inputs Aa and Ab of A feed Ba and Bb of B; outputs Bc, Bd, Be of B feed Ea, Eb, Ec of E; inside E, F receives on Fa and Fb and returns Fc and Fd, which G consumes before the final output.
Nothing in this definition says which engine, or machine, runs what.
A subgraph moves to another engine
Since the graph is declarative, you can carve out any subset and send it elsewhere without touching the rest. An engine M1 runs A. It hands B to an engine M2 and F to an engine M3. Data moves between engines the way it would move between treatments on a single machine: M1 sends M2 what Ba and Bb receive, M2 returns what Bc, Bd, Be produce, and so on.
The same program runs identically on one machine or on three. Only where each subgraph runs changes.
An example
The distributed_text_processing example shows the distribution capabilities. An HTTP server receives POST /process with some text and returns it uppercased. The uppercasing runs on an engine provisioned on demand, not on the machine answering the HTTP requests.
Worth pointing out that the remote treatment and the model it uses are written in the same file as the rest of the program. Nothing in their implementation needs to state that they run elsewhere. A model declares a minimal JavaScript engine:
model Uppercaser() : JavaScriptEngine {
code = "function toUpper(text) { return text.toString().toUpperCase(); }"
}The treatment that uses it decodes the received bytes, turns the string into JSON because the JavaScript engine exchanges Json values, applies the function, unwraps the result, then re-encodes:
treatment processText()
model uppercaser: Uppercaser()
input data: Stream<byte>
output data: Stream<byte>
{
decode()
wrapStr: fromString<string>()
jsUpper: process[engine=uppercaser](code="toUpper(value)")
unwrapResult: unwrapOr<Json>(default=|null())
resultStr: tryToString<Json>()
unwrapStr: unwrapOr<string>(default="")
encode()
Self.data -> decode.data,text -> wrapStr.value,json -> jsUpper.value,result -> unwrapResult.option,value -> resultStr.value,into -> unwrapStr.option,value -> encode.text,data -> Self.data
}
The connection chain reads left to right: the flow enters through Self.data, passes from one treatment to the next, exits through Self.data. The treatment.input,output notation marks the input where the data arrives, then the output it leaves from toward the next treatment.
To have processText run on another engine, all you need is to name it by its identifier in a distribution model:
model distributor: DistributionEngine(
treatment = "distributed_text_processing/main::processText",
version = "0.1.0"
)distributed_text_processing/main::processText is the treatment’s identifier. When the engine receives the treatment, it instantiates its own Uppercaser model. The JavaScript code is passed from the first engine to the second, along with the serialised implementation of the processText treatment and that of all the treatment’s dependencies.
The full project is at melodium.tech. To try it out, just clone it. Check that it’s valid with:
melodium check examples/13_distributed_text_processing/Compo.tomlAnd run it with:
melodium run examples/13_distributed_text_processing/Compo.toml --api_token "…"What travels between engines
A treatment doesn’t move as a binary compiled for a given architecture. The sending engine takes stock of the elements the treatment depends on, transcribes them into serialisable objects that carry their description and logical implementation, serialises, transmits. The receiving engine reconstructs, interprets what needs interpreting, then runs.
Because what’s carried is a logical implementation and not a native executable, engines can run on machines with different environments, operating systems and processor architectures. The engine becomes the software’s only substrate, and the program is described in terms of implementation as well as relationships between its components, which removes the need for images prepared in advance as well as for a separate infrastructure description. That’s the substance of the patents covering Mélodium technology1.
Replaying and debugging part of the program
One capability that follows from this treatment-isolation is being able to replay all or part of the graph program. A capture of a treatment with its inputs and outputs holds everything its execution depends on: its implementation, its parameters, and the data that arrived on its inputs. Those three things are enough to relaunch it, replay it, identically or with variations, and debug it.
When a treatment fails in the middle of a graph, you don’t necessarily have to re-run what comes before it to reproduce the problem, and you can also re-run just a part of it. You take the faulty section, and with the inputs it received, you relaunch, from your local machine if you like, since the treatment doesn’t depend on the hardware it runs on.
This property follows from the graph programming model. A treatment is a deterministic unit connected to its neighbours by explicit flows. Making it reproducible in isolation takes no extra mechanism, just keeping what passed through its inputs.
Parallelism is implicit
Mélodium runs tracks. A track gathers the treatments and connections wired together, which at runtime are created and disappear together, and each one is independent of the others. One track per incoming connection, one track per file found, one track per line to process, and so on.
Nothing outside models shares implicit state from one track to another, so splitting the work across several engines breaks no semantics. Parallelism and load distribution come naturally in Mélodium. So you can trigger an extra engine at any moment and for any reason, whether a processor crosses a load threshold, memory saturates, or on a programmed arbitrary condition.
stt & llm)Compared with a microservices or Kubernetes architecture, where you containerise each service and declare its deployment, here the code splits treatment by treatment, with no image build or prior assignment. Granularity runs from the whole software’s execution down to the function level, and the heterogeneity of environments and hardware is absorbed by the synchronisation between Mélodium engines.
Going further
Mélodium is free and Open-Source technology, under the EUPL licence. You can try its capabilities right now through the various examples provided, and put it to work on your own problems.
Examples of API routing, audio-to-text transcription, a CI pipeline, and distributed LLM inference are available.
Services like Cadence.CI provide orchestrators to work with your cloud providers.
The Mélodium Language and Technology Book is freely accessible.
The full standard library documentation is at doc.melodium.tech.
Patents FR3168998, EP4749449, US20260147628A1, CA3291442 (European Patent Office)