Tangle: a browser pipeline builder that runs components as containerized command-line programs
Tangle is a web app that allows the users to build and run Machine Learning pipelines without having to set up development environment.
At a glance
- What is it?
- Tangle is a web app for drawing ML pipelines on a canvas and executing them as containerized command-line programs, either locally through a Docker launcher or on HuggingFace Jobs. The interesting part is not the canvas, it is the ComponentSpec format and the execution cache underneath it.
- Who is it for?
- Adopt Tangle if you already write components in the ComponentSpec/component.yaml format, or want to, and you need a canvas and a run history more than you need a cluster scheduler. Skip it if you need Kubernetes-native orchestration with per-step autoscaling, or if a $9/month HuggingFace Pro subscription is not an acceptable dependency for running pipelines.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The setup tax Tangle is trying to remove
Most pipeline tools assume you have already solved the environment problem. You install an orchestrator, a database, a container runtime, an artifact store, and a scheduler, then you write a pipeline. Tangle inverts that order. The README describes it as a system that helps users "create and run ML experiments and production pipelines," and the first feature listed is starting to build pipelines right away through a visual drag-and-drop interface with no registration required to build. That is a real distinction: the canvas is usable before any credentials exist. Execution is the point where identity becomes necessary, and the README is explicit that submitting a pipeline for execution requires login. The target user is someone who has a batch workflow with a beginning and an end, wants it expressed as a graph, and does not want to spend a week on infrastructure before the first run. Data scientists moving from notebooks, and small teams that have outgrown a shell script but not outgrown a single machine, are the natural audience.
What actually executes: components, not notebook cells
The README's concepts section is the part worth reading twice. A component describes a command-line program inside a container. Its specification covers the signature (inputs and outputs), metadata (name, description, annotations), and the implementation, which names the container image, the program to start, and how inputs and outputs map onto the program's command-line arguments. A pipeline is a graph of interconnected component tasks. The orchestrator's job is to execute that graph of containerized programs, locally or remotely, and to move data between them. Two consequences follow. First, components can be written in any language, and the README points at sample components in Python, Shell, R, Java and C#. Second, the interface between steps is the command line and the filesystem, not a Python object graph, which is why the format travels. The README states that the ComponentSpec/component.yaml format is compatible with Google Cloud Vertex AI Pipelines and Kubeflow Pipelines, and that pre-built components are available in the Ark-kun/pipeline_components repository. That compatibility claim is about the component format, not about Tangle's own runtime, and the README does not describe a path for exporting a Tangle pipeline graph into either of those systems.
How the HuggingFace deployment splits storage and compute
The multi-tenant architecture is described in more detail than most of the README. A central tenant database holds user IDs, access tokens and orchestrator configs. Each tenant gets its own SQLite database in the persistent storage of the main TangleML/tangle HuggingFace Space. Pipeline execution happens through that user's HuggingFace Jobs, and the execution logs and output artifacts land in the user's own private HuggingFace Dataset repo, named user/tangle_data, with clickable links in the UI to both the artifacts and the Jobs. That is a clean separation: Tangle holds orchestration state, HuggingFace holds compute and identity, and the user's data stays in a repository the user controls. The single-tenant path is a Space duplication plus a HuggingFace token, which puts the database in your own Space persistent storage. Duplicating into an organization produces what the README calls a single-tenant multi-user deployment, where team members can see each other's pipeline runs and share an org-wide cache. Note the word cache. The README claims successful and even running executions are reused from cache, and in an org deployment that cache is shared, which is a meaningful behavioural difference from the personal instance and one the README does not expand on.
Running it locally: two clones and a launcher script
The local path is short. Install Docker and uv, then clone two repositories, not one: the backend from TangleML/tangle on the stable branch into tangle/backend, and the UI from TangleML/tangle-ui on the stable_local_build branch into tangle/ui_build. The directory names matter because the launcher expects them. On Linux and macOS you run cd tangle && backend/start_local.sh; on Windows, cd tangle && backend\start_local.cmd. When the terminal prints the orchestrator start message, you open http://localhost:8000 and click New Pipeline. The Google Cloud Shell route uses the same two clones and the same script, then the devshell proxy URL on port 8000. The split repository layout is worth flagging: the UI is consumed as a prebuilt artifact from a separate branch rather than built from source, so a UI change means waiting for that branch to be updated. The README also states that the architecture allows Tangle to run anywhere and that the list of installation recipes is expanding, which is an admission that local Docker and HuggingFace are currently the documented targets.
The cache and the clone-run loop
Tangle's iteration story is a loop: create pipeline, submit run, monitor run, clone run, edit pipeline, submit run. Cloning a run produces a new editable pipeline, and the README states that all runs are kept forever on your machine, including graph, logs and metadata, so re-running an old pipeline takes two clicks. The caching layer is the mechanism that makes the loop cheap. Successful executions are reused, and the README goes further by saying running executions are reused too. That second claim deserves scrutiny. Reusing an in-flight execution means a second submission of an equivalent graph attaches to work that has not finished, which is a different guarantee from reusing a completed result, and the README does not explain how equivalence is determined or what happens when the earlier run fails after the reuse decision. Reproducibility rests on containers and what the README calls strict component versioning. That is only as strict as the image tags you pin. A component.yaml pointing at a floating tag will not reproduce, and nothing in the material suggests Tangle rewrites tags for you.
Where Tangle is the wrong choice
The HuggingFace path carries a hard dependency the README states plainly: running your pipeline requires a HuggingFace account with a Pro subscription at $9/month. Building is free and registration-free, but building is not running. For an individual that is a small line item; for a team pricing seats, or for anyone in an organization that will not route credentials through a third party, it is a blocker, and the alternative is the local or self-hosted deployment. The second limitation is scale. The README describes execution on your local machine or on HuggingFace Jobs. There is no mention of cluster scheduling, per-step resource requests, autoscaling, or gang scheduling. A pipeline whose steps need a GPU node pool is outside what the documented deployment options cover. Third, the local deployment stores runs on your machine and the README says they are kept forever, which is a retention policy by default and a disk management problem eventually. There is no documented pruning command.
Alternatives and the actual difference
The README names two compatible systems: Google Cloud Vertex AI Pipelines and Kubeflow Pipelines. The difference is where the graph lives. Vertex AI Pipelines and Kubeflow Pipelines are services or cluster components you deploy first; you author a pipeline in Python with a DSL, compile it to a specification, and submit it to a managed or self-hosted control plane that schedules pods. Tangle is the control plane you are looking at in the browser, and its unit of reuse is a component.yaml rather than a compiled pipeline package. That means you can take a component written for Tangle and use it in Vertex or Kubeflow, but the reverse is not described in the README: a compiled Kubeflow pipeline is not something Tangle loads. If your team already runs Kubeflow and wants a visual editor on top, Tangle is not that editor. If your team has a folder of component.yaml files and no orchestrator, Tangle is closer to what you want. The honest framing is that Tangle competes with the setup work, not with the schedulers.
Licence, maintenance and what to check before adopting
Tangle is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. It also includes an explicit patent grant. That is the licence text, not legal advice; if you plan to redistribute a modified Tangle, have counsel read the NOTICE requirements. On maintenance, the repository is not archived and the last push recorded is 2026-09-09. No releases were retrieved, so there is no version number to pin against and no changelog to read. That matters more than usual here because the local install clones two repositories on branches named stable and stable_local_build rather than tags, so a fresh clone is not a fixed artifact. The first thing to verify is whether those branches move under you between installs. The second is whether your existing component.yaml files load without edits. The third is whether the org-wide cache behaves the way your team expects when one member resubmits a graph another member is already running.
Editorial conclusion
Adopt Tangle if you already write components in the ComponentSpec/component.yaml format, or want to, and you need a canvas and a run history more than you need a cluster scheduler. Skip it if you need Kubernetes-native orchestration with per-step autoscaling, or if a $9/month HuggingFace Pro subscription is not an acceptable dependency for running pipelines. Before committing, verify three things: that the stable branch of both the backend and tangle-ui repositories clones and that backend/start_local.sh reaches the orchestrator start message on your machine, that your existing component.yaml files load without edits, and that your private HuggingFace Dataset repo (user/tangle_data) is actually created on your first Job run.
Community notes