Cowrie Research

bacalhau

4 min read

Bacalhau

  • Name: Bacalhau
  • URL: https://bacalhau.org/
  • Category: distributed compute orchestration framework / compute-over-data infrastructure / decentralized workload routing comparator
  • Summary: Bacalhau is a compute-over-data orchestration framework, not a blockchain and not a generic GPU-marketplace note. The point is straightforward: it schedules jobs near existing data and exposes the real authority surface in orchestrators, admission policy, backend choice, and operator control. Keep this note on the open framework and its scheduling mechanics; the broader managed control-plane and governance packaging around adjacent commercial workflow now lives separately in expanso.
  • What it does:
    • Runs distributed jobs close to the data source instead of requiring large datasets to be moved first
    • Uses a single binary that can operate as client, orchestrator, or compute node depending on runtime mode
    • Supports multiple execution engines and storage backends, including Docker, WebAssembly, S3, HTTP/HTTPS, IPFS, and local storage
    • Supports several workload types, including batch, ops, daemon, and service jobs
    • Allows declarative job specs via YAML as well as imperative CLI submissions
    • Publishes results to local volumes or external storage systems such as S3
    • Markets the stack for log processing, distributed warehousing, fleet management, machine learning, and edge computing
  • Key claims:
    • The official docs and current README describe Bacalhau as an open-source distributed compute orchestration framework designed to bring compute to the data, which is the clearest reason to treat it as workload-routing infrastructure rather than as a classic crypto network primitive
    • Bacalhau emphasizes data sovereignty, security boundaries, and cross-organizational computation, which makes it analytically useful where crypto systems want decentralized execution without forcing raw data into one shared network
    • The architecture is explicitly orchestrator-plus-compute-node based, so practical authority likely concentrates in scheduler policy, node admission, permissions, and deployment topology more than in token economics or consensus design
    • The framework supports several job types and pluggable storage/execution layers, which suggests Bacalhau is a generalized control plane for distributed execution rather than a single-purpose ML marketplace
    • The current README is notably cleaner about the open-source boundary than older framing: it says the repository contains open-source Bacalhau software under Apache-2.0 and that commercial terms are not required to use, modify, or distribute that code, which makes it more useful to isolate any managed workflow or SaaS packaging in a separate company note instead of smearing it back into this project note
    • Expanso’s current official materials foreground a managed control plane, agent lifecycle, governance features, and customer-facing SaaS workflow rather than the Bacalhau brand itself, which is exactly why expanso is the sharper place to track vendor-shaped control surfaces above the framework
    • Compared with Lilypad, Bacalhau appears more like a general compute orchestration substrate and less like a crypto-economic verification-and-settlement layer, making it a useful baseline for asking when decentralized compute is really just better scheduling over heterogeneous infrastructure
  • Whitepaper: No standalone Bacalhau whitepaper was located during this pass. The older framework snapshot remains ../whitepapers/bacalhau-primary-sources-2026-05-09.md; the newer project/company split is supported by ../whitepapers/expanso-primary-sources-2026-08-11.md.
  • Sources:

Internal linkages

  • Company / managed-control-plane boundary above the framework: expanso.
  • Best comparisons: lilypad for the more crypto-economic execution layer and fluence for the cloud-marketplace contrast.

Protocol / company boundary

  • Keep projects/bacalhau on the open framework itself: compute-over-data scheduling, orchestrator-versus-compute-node topology, job types, storage backends, and deployment mechanics.
  • Use expanso when the sharper question is who packages a central SaaS control plane, automatic agent updates, governance workflow, workspace controls, and the commercial easy path around near-source processing.
  • That split matters because how does Bacalhau work? and which company is trying to become the default managed operator shell around this style of deployment? are related but not identical questions.

Control surface

  • The leverage inside Bacalhau itself sits in orchestrator topology, node and job admission, backend selection, and deployment policy.

  • The adjacent vendor-shaped leverage above that framework now sits more cleanly in expanso: control-plane availability, managed updates, governance packaging, and workflow defaults.

  • So treat Bacalhau as scheduling middleware over heterogeneous infrastructure, not as a neutral compute primitive and not as a full substitute for the company note above it.

  • Last reviewed: 2026-08-11 UTC

Graph View

Backlinks