Syncle

Overview

Syncle keeps databases in sync — live, across engines. You connect databases, draw a bridge from a source to one or more destinations, and Syncle moves rows across it: once, on a schedule, or the moment they change.

It speaks five engines — PostgreSQL, MySQL/MariaDB, SQLite, MongoDB and Redis — and any of them can sit on either end of a bridge. A relational table can feed a document store, a document collection can feed a key-value cache, and an HTTP endpoint can stand in for a database on the receiving side. Everything runs on your own machine, under the MIT licence, with a web interface as the only way you touch it day to day.

The shape of it

An installed Syncle is four containers: the web interface, the API, and a PostgreSQL and Redis instance of its own — the first for Syncle's metadata (connections, bridges, job history), the second for the job queue. Your databases stay wherever they already are; Syncle connects out to them.

Three words carry most of these docs:

  • A bridge is the saved sync path — the source table or query, the column mapping, the destinations, and the trigger.
  • A job is one execution of a bridge.
  • A delivery is one row (or batch) delivered within a job — the unit the live timeline shows, and the unit you can retry or skip.

Installing

Docker with Compose v2 and curl are the only requirements. One command downloads the newest release, starts it, and opens the interface:

curl -fsSL https://syncle.dev/install | sh -s -- up

The installation page explains what the script actually does, the manual Docker Compose route if you would rather not pipe curl into sh, and how updating and uninstalling work.

Where to go next

  • Installation — The one-command install, the syncle launcher, the manual Docker Compose route, ports, and updating or removing an install.
  • Quickstart — From syncle up to a first working bridge: the setup token, connecting a database, and reading the delivery timeline.
  • How bridges work — Bridges, jobs and deliveries; the three trigger modes; delivery guarantees; destinations; and the tuning knobs.
  • CDC setup — Per-engine prerequisites for real-time change data capture, what Syncle provisions for you, and the honest limitations.
  • Database workbench — Browsing and editing tables, the query editor, schema and ER diagrams, DDL, backup and restore, and SSH tunnels.
  • Configuration — Every environment variable with its default, the in-app settings, and where the config files live.
  • HTTP API — The REST API under /api: authentication, response envelopes, and every endpoint for connections, bridges and jobs.
  • Self-hosting & security — Running Syncle beyond localhost: the security posture, encryption, what to back up, and a troubleshooting list.

About these docs

These pages document Syncle 1.0, and every command, endpoint and default in them is taken from the source repository rather than from memory. Where the honest answer has a limitation — SQLite has no change log to capture, Redis change events are not durable — the limitation is written down next to the feature. If you find a place where the docs and the software disagree, that is a bug: please report it.