# Multiwoven: a self-hosted Reverse ETL platform for warehouse-to-tool syncs

> Multiwoven is an AGPL-3.0 Ruby monorepo that moves modelled warehouse data into CRMs, ad platforms and support tools. It runs on Docker Compose or Helm, which is also where the operational cost sits.

**Multiwoven/multiwoven** — 🔥🔥🔥 Open source Reverse ETL -  alternative to hightouch and census. 

- Repository: https://github.com/Multiwoven/multiwoven
- Website: https://aisquared.ai/enterprise/
- Stars: 1,677 · Forks: 96
- Language: Ruby
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/multiwoven-multiwoven

## The problem Multiwoven targets: activation, not ingestion

Most data stacks are good at getting data into a warehouse and bad at getting it back out. The README frames Multiwoven as an open-source alternative to HighTouch, Census and RudderStack, and the category it names is Reverse ETL: syncing data from your warehouse to business tools. The audience is a data or platform team that already has modelled tables in BigQuery, Redshift, Databricks or Postgres and now needs those rows to appear inside Salesforce, HubSpot, Slack or an ad platform without hand-written export jobs.

The README describes the workflow in three steps: connect to sources, prepare your data by creating models, and sync with destinations. That ordering is the whole product thesis. The model step is where a warehouse team decides which columns leave the warehouse, which is a governance decision as much as a technical one. If your team does not have a warehouse, or has one but no agreement on which tables are authoritative, Multiwoven will not create that agreement for you.

## How the monorepo splits into server, ui and integrations

The README states that Multiwoven is a monorepo with three main services. The server is the backend control plane for managing data sources, models and syncs. The ui is a React frontend for configuring sources, destinations and syncs. The integrations directory is a Ruby gem that provides a framework for building connectors.

The split matters when you plan an upgrade. The repository also carries separate CI workflows for the server, integrations and ui, so the three can be built and released on different cadences even though the version tags in the release list are shared. A connector change and a UI change do not necessarily move together.

Execution is not handled by the Rails server alone. The docker-compose.yml in the repository defines a Temporal stack: a postgresql service for Temporal's own storage, a temporal service on port 7233, temporal-admin-tools, and temporal-ui on port 8080. Sync runs are therefore orchestrated as Temporal workflows rather than as background jobs inside the web process. That is a reasonable design for long-running, retryable syncs, and it is also the reason a Multiwoven deployment is not a single container.

## Local setup with Docker Compose and a first sync

The README gives a local setup sequence built on Docker Compose. The commands below are copied from it. The clone uses the SSH form shown in the README, so you need a GitHub SSH key; substitute the HTTPS URL if you do not have one.

```bash
git clone git@github.com:Multiwoven/multiwoven.git
cd multiwoven
mv .env.example .env
cp .env ui/.env
./git-hooks/setup-hooks.sh
docker-compose build && docker-compose up
```

The .env.example file supplies the defaults that make this work locally. DB_USERNAME is multiwoven, DB_PASSWORD is password, DB_HOST is db, and REDIS_URL is redis://redis:6379/0. UI_HOST is localhost:8000 and API_HOST is localhost:3000, with VITE_API_HOST set to http://localhost:3000. The README states the UI can be accessed on port 8000.

```bash
http://localhost:8000
```

One value deserves attention before you sign in. USER_EMAIL_VERIFICATION is set to false in the example file, and the surrounding comment says it is used to skip user email verification after signup, with the note that setting it to true requires working SMTP credentials. For local testing the default is the convenient choice. For anything reachable from a network, it is a setting to revisit alongside SMTP_HOST, SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME and SMTP_PASSWORD, which are all placeholders in the example.

After the stack is up, the first real use follows the README's three steps: add a warehouse source, create a model that selects and transforms the rows you want to activate, then attach a destination and configure the sync. The README does not document the field-level sync settings, so treat the in-product forms as the source of truth rather than any guess about mapping behaviour.

## What the repository does not hand you

The .env.example includes SNOWFLAKE_DRIVER_PATH pointing at /usr/lib/snowflake/odbc/lib/libSnowflake.so. That path is a container path, not something you install by running a command in the README. If you deploy outside the provided images, driver provisioning is your problem, and the README does not walk through it.

Deployment coverage is uneven. The self-hosted table lists Docker, Helm Charts, AWS EC2, and marks AWS ECS and AWS EKS (Kubernetes) as coming soon. A team standardized on ECS or EKS has no documented path in the README and would be adapting the Helm or EC2 guidance instead.

The documentation is also silent on several operational questions that decide whether a reverse ETL tool is safe to run. There is no rollback procedure for a bad sync, no documented rate-limit or backfill behaviour per destination, and no described audit trail for who changed a model. Temporal gives you retries at the workflow level; it does not tell you what a partial write to a CRM looks like. For a tool whose job is writing into systems of record, that is the gap to close with your own testing before you point it at production data.

Finally, the README's own table of contents links a section titled Development Status: Under Active Development. The repository is not archived and the most recent push recorded is 2026-09-10, with releases v0.127.0, v0.128.0 and v0.129.0 landing on 2026-08-25, 2026-09-01 and 2026-09-08. Frequent minor-version releases at that pace also mean frequent upgrade work.

## Multiwoven compared with Grouparoo and with a scheduled script

Grouparoo is the closest comparison people search for, and the difference is architectural. Grouparoo was a Node.js reverse ETL tool built around a plugin model for sources and destinations. Multiwoven is a Ruby monorepo whose connector framework lives in the integrations gem, with a React UI and a Temporal-backed execution layer. If your team writes Ruby, contributing a connector to Multiwoven means working in a language you already maintain; if your team is Node-first, that calculus flips.

The other alternative is the one most teams already have: a cron job or an orchestrator task that queries the warehouse and calls a destination API. That approach is genuinely simpler for one destination and one table, and it needs no control plane, no Temporal, and no UI. It stops being simpler the moment you have several destinations, several models, and a need for someone outside the data team to see what is syncing where. Multiwoven's value is that visibility and the shared connector layer, not the raw data movement.

A managed service such as HighTouch or Census is the third option, and the trade is explicit. You give up self-hosting and pay a vendor, and in return the vendor owns connector maintenance and destination API changes. Multiwoven's README positions self-hosting on your own cloud infrastructure as the point, which is a real advantage for teams with data residency constraints and a real cost for teams without platform engineers.

## Licence and the cost of keeping up

Multiwoven is licensed under AGPL-3.0. The practical consequence, and this is not legal advice, is that the network-use clause in that licence is broader than in permissive licences: if you modify the software and let users interact with it over a network, the licence's source-disclosure obligations can reach your modified version. Teams that embed a tool like this inside a product they sell should read the licence text in the repository, and the enterprise homepage linked from the README, rather than assume the permissive-licence habits they may have from other data tooling.

Upgrade cost follows from the release cadence. Three releases shipped in the three weeks before the last recorded push, all minor versions. The repository includes a release-notes.md file at the top level, which is where you would check what changed between tags before pulling a new image. Because the server, ui and integrations services have separate CI workflows, a version bump can carry changes in any of the three, and the docker-compose.yml pins Temporal images through TEMPORAL_VERSION, TEMPORAL_UI_VERSION and TEMPORAL_POSTGRESQL_VERSION variables that you control in .env. Those pins are worth reviewing on each upgrade rather than leaving them at whatever the example file shipped.

## Conclusion

Adopt Multiwoven if you already run a warehouse, you accept operating Postgres, Redis and Temporal yourself, and AGPL-3.0 fits how you ship software. Skip it if you want a vendor to own connector maintenance, or if your activation volume is small enough that a scheduled script would do. Before committing, verify two things in your own environment: that the destination you need is listed in the connectors section of the docs, and that your team can run the Temporal stack described in docker-compose.yml, because that is the piece that turns a sync into an operational service.

## FAQ

### What is Multiwoven and what does it do?

Multiwoven is an open source Reverse ETL and data activation platform, described in its README as an alternative to HighTouch, Census and RudderStack. It lets you sync data from a warehouse such as BigQuery, Redshift or Databricks into business tools like Salesforce, HubSpot and Slack.

### How do I install Multiwoven locally?

The README's local setup clones the repository, renames .env.example to .env, copies that file into the ui folder, runs ./git-hooks/setup-hooks.sh, and then starts the stack with docker-compose build && docker-compose up. The README states the UI is reachable on port 8000.

### What licence does Multiwoven use?

The repository is licensed under AGPL-3.0, and the README links to an enterprise homepage alongside it. Because AGPL-3.0 carries network-use obligations, teams embedding it in a product should read the licence text in the repository themselves.

## Sources

- [License: AGPL-3.0](https://github.com/Multiwoven/multiwoven/blob/main/LICENSE)
- [Multiwoven/multiwoven on GitHub](https://github.com/Multiwoven/multiwoven)
- [Project website](https://aisquared.ai/enterprise/)
- [README](https://github.com/Multiwoven/multiwoven/blob/main/README.md)
- [Releases](https://github.com/Multiwoven/multiwoven/releases)

---

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