# Tangle is free to author and costs nine dollars a month to run on the hosted instance

> A pipeline builder that orchestrates containerised command line programs as a graph, offered three ways: a local Docker install, a free cloud shell, and a shared multi tenant instance on a model hub. The hosted path stores access tokens in a central tenant database, the local path needs two clones from two repositories on two different branches, and the resolution window is frozen to seven days old packages.

**TangleML/tangle** — Tangle is a web app that allows the users to build and run Machine Learning pipelines without having to set up development environment.

- Repository: https://github.com/TangleML/tangle
- Website: https://tangleml.com/
- Stars: 514 · Forks: 38
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/tangleml-tangle

## Building is free and running is the paid part

The hosted experience splits into two halves with different prices, and the split is stated plainly.

Creating a pipeline requires no registration at all. You open the shared instance, drag components onto a canvas, connect outputs to inputs, configure arguments, and only the submission step asks you to log in. So the authoring half of the product is free to anyone who opens the page.

Running it is not free. To submit a pipeline for execution you need an account with a paid Pro subscription, quoted at nine dollars a month. The local install has no such requirement, because there the compute is yours.

That framing explains the pitch about ownership. The feature list states that no registration is required to build and that you own your data, which is true in both halves but means different things: locally your data never leaves your machine, and on the hosted instance your artefacts go to a private repository in your own account rather than to the vendor.

The build flow itself is short enough to summarise in one line: start from the sample training pipeline or from nothing, drag, connect, configure, submit, then watch the run in real time with its artefacts and logs.

## The shared instance keeps access tokens in a central database

The multi tenant deployment is described precisely enough to be worth reading, because the architecture determines what the isolation claim means.

There is a central tenant database that stores user identifiers, access tokens and orchestrator configurations. Alongside it, each tenant gets its own SQLite database in the persistent storage of the shared space. Each user's pipelines then run as that user's own jobs on the hub, and the execution logs and output artefacts are written to a private dataset repository belonging to that user, with clickable links in the interface back to both the artefacts and the jobs.

So the compute and the artefacts are already per user, and the two things that are shared are the tenant database and the application itself. That is why the documentation pushes a self hosted route for anyone who needs isolation: duplicating the space into your own account gives you a single tenant deployment whose database lives in your own persistent storage, which is described as complete control and data isolation.

The access token in a central database is the specific thing to weigh. Whoever operates that instance holds a credential for every tenant who used it, and the token is what lets the platform act on your behalf in your own account. On a shared free instance that is a reasonable trade for a free tier, and it is the reason the duplicated space exists.

## Duplicating to an organisation buys multi user, not isolation

The duplication route has two outcomes, and they are not variations of the same thing.

Duplicating the space into your own personal account gives a single tenant deployment with your own database, described as complete control and data isolation. It needs a token from your account, which is what lets the deployment write to your storage.

Duplicating into an organisation gives a single tenant, multi user deployment for a team. Multiple members can see each other's pipeline runs, and the documentation adds that they enjoy an organisation-wide cache.

That second point is worth pausing on, because the cache is one of the product's headline features and it is now shared. If two people run the same pipeline shape, a cached execution from one is reused by the other, which saves time and compute and also means a result produced in one person's environment can be reused in another's.

The security boundary follows the storage account rather than the application. Both duplicate routes put the database in storage you control, which is what removes the shared tenant database from the picture. What you give up is the shared instance's zero setup, and what you gain is a credential store nobody else administers.

## A local install is two clones from two repositories on two branches

The local route needs Docker and a Python package manager, then two clones.

```shell
git clone https://github.com/TangleML/tangle.git tangle/backend --branch stable
git clone https://github.com/TangleML/tangle-ui.git tangle/ui_build --branch stable_local_build
```

The first clone is this repository and the second is the interface, which lives in a separate project. They are pinned to different branches: the backend to a stable branch and the interface to a branch whose name says it is the local build. So the two halves of the application are versioned separately, and the pairing that works is the one those two branch names describe.

Starting it is a script per platform, a shell script on Linux and macOS and a batch file on Windows, run from the parent directory. The application is not ready when that command returns: you wait for a specific line in the terminal, the one that says the orchestrator is starting, and only then open the local port in a browser.

The same two clones and the same start command work in a free cloud shell, where the documentation notes the weekly allowance, and the only difference is that the port is reached through the shell's proxy URL in another browser tab rather than on localhost.

Once the interface is up, the entry point is a button in the top bar that creates a new pipeline.

## The cache reuses executions that are still running

Automatic execution caching is described as saving time and compute by not redoing what is done. The sentence that matters is narrower than the headline: successful executions are reused from cache, and so are running ones.

That is an unusual choice and it cuts both ways. Reusing a completed execution is the point of a cache. Reusing one that has not finished means a second submit of the same pipeline can attach to work already in progress, which is faster and cheaper, and which also means the result you get back may not be a result anyone has seen yet.

For a fast iteration loop that is exactly what you want. The documented cycle is create a pipeline, submit a run, monitor it, clone the run into an editable pipeline, edit, submit again, and the cache makes the repeat steps cheap.

Reproducibility is the counterweight, and it is claimed on three separate grounds. All runs are kept, including the graph, logs and metadata, so an old run can be turned into a new editable pipeline in two clicks. Containers pin the environment. And component versions are described as strict, which is what makes the graph mean the same thing on a later run.

Those three claims are what make the running-execution reuse safe to do, and they are also what you would want to verify rather than inherit.

## The distribution is named cloud-pipelines-backend and depends on cloud-pipelines

The manifest does not call itself Tangle. The project name is a backend for the cloud pipelines package, at version 0.1.0, requiring Python 3.10 or later, and the description is two words long.

The dependency list is where the design shows. The pipeline SDK itself is a dependency, so this project is a layer over an existing orchestration library rather than a reimplementation. Alongside it sit a Kubernetes client, a web framework with its standard extras, an ORM, a migration tool, and a full distributed tracing stack: the tracing API, the SDK, a FastAPI instrumentation package, and two exporters, one over gRPC and one over HTTP.

Error reporting is the entry worth noticing. A hosted exception reporting service is a direct dependency of the backend, in a product whose selling point is that you own your data and can self host. That is a reasonable choice for the hosted instance and something to think about before running the backend yourself.

Two smaller details. The default branch is called master rather than main, which is still visible in the install commands. And there are no GitHub releases, so a version to pin is not available from the tag list; the manifest's own version is the only marker, and it reads 0.1.0.

## Resolution is frozen to seven day old packages, with one exemption

Reproducibility is enforced at the package manager, and the mechanism is specific.

The configuration excludes any package published within the last seven days from resolution. The index is pinned to the default package index and the secondary index list is emptied, so there is nowhere for an unexpected package to come from.

Then there is a single exemption. One named package is explicitly excluded from that seven day rule, so it is allowed to resolve past the cutoff while everything else stays behind it. Given that this package is the orchestration dependency everything else builds on, exempting exactly that one is a deliberate choice rather than an oversight: it means the layer you build on can move while the rest of your environment stays frozen.

The remaining configuration is conventional. Dependencies are grouped rather than merged, with a development group carrying a formatter, test runners and type stubs, a group for the hub client with its authentication extra, and a separate group for a cluster scheduler library. The test configuration points at a single directory and switches the import mode.

The tree matches the multi launcher story. Alongside the local start scripts for two operating systems there is a Python launcher and a second one named for a cluster scheduler, and the examples directory holds a directory for that scheduler and one for observability.

## Conclusion

Tangle is worth trying if you want to assemble machine learning pipelines out of existing components rather than writing orchestration, and the component compatibility with two well known hosted pipeline systems means you are not locked into its own ecosystem. Two decisions to make explicitly. Choose between the shared instance, where the tenant database holding your credentials is not yours, and a duplicated space, where it is. And read the caching behaviour before you rely on it, because reusing executions that are still running changes what a rerun means.

## FAQ

### Do I need a Hugging Face account to build a Tangle pipeline?

No. Creating a pipeline requires no registration; only submitting it for execution needs an account with a Pro subscription, quoted at nine dollars a month on the shared instance.

### Where does the shared Tangle instance store my data?

Execution logs and output artefacts go to a private dataset repository in your own Hugging Face account, and your pipelines run as your own jobs. A central tenant database holds user identifiers, access tokens and orchestrator configurations for everyone on the instance.

### What is the difference between duplicating Tangle to my account and to an organisation?

Duplicating to your own account gives a single tenant deployment with your database in your own storage and full data isolation. Duplicating to an organisation gives a single tenant, multi user deployment where members can see each other's runs and share an organisation-wide cache.

### What do I need to install Tangle locally?

Docker and a Python package manager, then two clones: the backend repository on its stable branch and the separate interface repository on its local build branch. Start it with the shell script on Linux and macOS or the batch file on Windows, wait for the orchestrator message, then open the local port.

### Does the Tangle execution cache reuse runs that are still going?

Yes. The documentation says successful executions are reused from cache and so are running ones, which means a resubmitted pipeline can attach to work already in progress.

### How does Tangle pin its dependencies for reproducibility?

Resolution excludes any package published in the last seven days, the secondary index list is emptied, and one named package is explicitly exempted from the seven day rule so the orchestration dependency can move while everything else stays frozen.

## Sources

- [Issues](https://github.com/TangleML/tangle/issues)
- [License: Apache-2.0](https://github.com/TangleML/tangle/blob/master/LICENSE)
- [Project website](https://tangleml.com/)
- [README](https://github.com/TangleML/tangle/blob/master/README.md)
- [TangleML/tangle on GitHub](https://github.com/TangleML/tangle)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tangleml-tangle