01 · Group
Group machines into @sets
Gather machines into named @sets — by role, by function, however you actually run the fleet. A set is both your rollout target and your canary boundary.
§ 00 · Architecture
One binary. Three roles. Two planes that never mix.
The technical deep-dive for the team evaluating Syncronis. How a change travels from your console to thousands of machines, where every byte of your data lives, and what it costs to run.
~/syncronis
# Install agent on any Linux box (illustrative)
$curl -fsSL https://syncronis.net/install | sh
# Same binary, three roles
$syncronis server --config /etc/syncronis/server.json
$syncronis vault --config /etc/syncronis/vault.json
$syncronis agent --config /etc/syncronis/agent.json
Illustrative. Agents enrol with a one-time token issued from your console. No shared secrets, no public endpoint to attack.
§ 01 The core loop
From intent to landed, in one loop.
No agents to babysit, no cluster to reconcile. You describe what should happen; Syncronis makes it happen, where and when you said.
02 · Define
Build it in the editor
Pick the package and target, then set the schedule window, timeout, on-failure policy and process signals, all in the console, no DSL to learn. Every rollout is plain JSON underneath, so you can script it through the API whenever you want automation.
03 · Publish
Publish and it goes
Pushed over gRPC the moment you commit, not on a poll interval. Agents pull packages from your vault over HTTPS, run your scripts, and stream results back.
04 · Watch
Watch it land, live
Per-machine progress, failures surfaced immediately, and a full attributed history of who changed what.
The deployment unit
A package is a folder with a bash entry script.
Arbitrary files — configs, templates, binaries — plus the script the agent runs. The package is the script's path: deploy-nginx/setup.sh and deploy-nginx/rollback.sh are two packages sharing one folder, each with its own deployments, versions, targets and blocked-version tracking.
No .deb or .rpm to build, no manifest schema. Your package is opaque to the platform: Syncronis schedules, distributes and runs it, but never parses or rewrites your files.
vault · packages/
$tree packages/
packages/
├── deploy-nginx/
│ ├── setup.sh # a package
│ ├── rollback.sh # 2nd package
│ └── templates/
│ └── nginx.conf
└── monitoring/
└── install.sh
§ 02 Two planes
Two planes that never mix.
The control plane decides where and when. Your vault holds what (packages, logs, credentials) on hardware you own. You (or your auditor) can see exactly where data lives, because the line between the two planes is the whole design.
Cloud-hosted
Control plane · our cloud
server Control plane
gRPC sessions, HTTP API, rollout intent. Managed by us —
and it stores no tenant data.
gRPC config · sessions
Your infrastructure · data stays here
agent Managed machines
Any Linux box. Config sync, package download, script
execution, driven by the rollout.
HTTPS packages · logs
vault Vault
Packages, logs, and credentials on a tenant-controlled
HTTPS file server. Never leaves your hardware.
Self-hosted · same binary
Control plane · your hardware
server Control plane
The same binary, run by you: gRPC sessions, HTTP API,
rollout intent — behind your own firewall, no phone-home.
gRPC config · sessions
Your infrastructure · data stays here
agent Managed machines
Any Linux box. Config sync, package download, script
execution, driven by the rollout.
HTTPS packages · logs
vault Vault
Packages, logs, and credentials on a tenant-controlled
HTTPS file server. Never leaves your hardware.
Self-hosting ships with Enterprise. Same binary in both modes, so moving later is a configuration change, not a migration.
On the wire
Control-plane traffic carries rollout intent, config and machine status — never your payloads. Packages, logs, credentials and rendered secrets stay on your vault.
Identity
Every agent↔server connection is mutually authenticated with client certificates. No shared secrets sprayed across the fleet.
Secrets
Per-machine secrets are rendered on your own infrastructure at build time. They never round-trip through the control plane.
§ 03 The numbers
Runs on the hardware you already have.
No cluster to stand up, no runtime to keep patched, no platform team to operate it. One small binary you can drop on a Raspberry Pi or a datacenter server. Measured on a live host, not modeled.
~25 MB
agent memory, runs alongside your workloads, not instead of them
~13 MB
one binary to ship, nothing else to install
0
runtime dependencies to patch or break
1
process and one file to back up: the whole control plane
And it stays flat as the fleet grows.
A fleet is only as manageable as its slowest page. These are the operations that decide whether ten thousand machines feel like ten.
10k
machines on one server, held against a single SQLite file
~10 ms
to read all 10,000 machines and their last result for the console
~0.4 s
of database work for the whole fleet to re-register after a restart
~1.5 µs
per heartbeat to decide whether a machine's config has changed
Storage-layer benchmarks over a 10,000-machine dataset on a mid-range
desktop CPU, not end-to-end page loads — the server's own
go test -bench suite, run on every change.
Your numbers will differ with disk and CPU; the shape won't.
§ 04 Compared
How Syncronis compares.
The three categories teams weigh Syncronis against. Where each tool sits is a design choice. Read it as positioning, not a verdict.
vs. configuration management
| Syncronis | Ansible | Puppet | Chef | |
|---|---|---|---|---|
| What you write | The bash you already have. The rollout is built in the console. | YAML playbooks + Jinja templates | Puppet DSL manifests | Ruby DSL recipes |
| New language to learn | None | YAML + Jinja | Puppet DSL | Ruby DSL |
| Hand-edited config files | None — JSON underneath, for the API when you want it | Yes, that is the interface | Yes, that is the interface | Yes, that is the interface |
| Agent model | Persistent (push) | Agentless (SSH) | Agent (pull) | Agent (pull) |
| Access into the machine | None inbound — the agent dials out, identity is a client certificate | Inbound SSH from a control node, with keys to distribute | None inbound — agent dials out | None inbound — agent dials out |
| Change reaches fleet | On publish, near-instant | When you run it | Poll interval | Poll interval |
| Machines that were offline | Catch up by themselves on reconnect | Fail the run — you write and schedule the retry | Catch up on next poll | Catch up on next poll |
| What you get back | A console view, backed by one JSON line per event — still filterable months later | Run output, verbose by default | Agent run reports | Agent run reports |
| Package delivery | Built-in, delta transfer | Copy / modules | File-based | File-based |
| Config templating | Yes (vault build) | Yes (Jinja2) | Yes | Yes |
| Desired-state / drift correction | On demand, fleet-wide: a version bump re-runs it. Not on a timer. | Whenever you run it | Continuous | Continuous |
vs. fleet / edge management
| Syncronis | Mender | Balena | qbee | |
|---|---|---|---|---|
| Built for | Linux fleets, any size | Embedded OTA | Container edge | IoT / embedded |
| Change reaches fleet | On publish, near-instant | Poll interval | Poll interval | Poll interval |
| Your data on your infra | Yes (vault) | Vendor / hosted | Vendor cloud | Vendor hub |
| Self-host | First-class, same binary | On-prem (enterprise) | openBalena (partial) | Enterprise only |
| Delivers | Scripts + packages | A/B image OTA | Containers | Declarative config |
| Package format | Folder + bash entry script | Signed artifact (.mender) | Container image | Declarative bundles |
| Transport | Push (gRPC) | Pull | Pull | Pull (HTTPS) |
| Behind a 443-only proxy | Yes — ports are yours to set, agent honours HTTPS_PROXY | Yes | Yes | Yes |
| Rollout control | Targeting, windows, canary, version history | Phased rollouts (Ent) | Release pinning | Group config |
| Deploy preview | Simulate targets first | — | — | — |
vs. GitOps
| Syncronis | Argo CD | Flux | |
|---|---|---|---|
| Built for | Linux fleets, any size | Kubernetes clusters | Kubernetes clusters |
| What it manages | The host itself — config, packages, scripts | Cluster resources, declared as manifests | Cluster resources, declared as manifests |
| Needs a cluster | No — one binary on the machine | Yes | Yes |
| Change reaches fleet | On publish, near-instant | Poll, 180s by default — instant with a webhook | Poll, 1m from bootstrap — instant with a webhook |
| Your data on your infra | Yes (vault) | Yes — your repo, your cluster | Yes — your repo, your cluster |
| Source of truth | Rollout in the console, JSON underneath | A Git repository | A Git repository |
| Drift correction | On publish, and on a version bump | Continuous reconcile | Continuous reconcile |
| Runs where there is no cluster | Yes — that is the case it is for | No | No |
| Agent footprint | ~13 MB static binary | In-cluster controllers | In-cluster controllers |
Syncronis renders per-machine config from templates, inheritance and secrets, but it deploys on publish rather than continuously reconciling state. It is not infrastructure-as-code and not a container orchestrator: it delivers your packages and runs your scripts, where and when you decide.
Run the architecture yourself.
Create your organization and start free. Your first 5 machines are on us, no card required. Any Linux host with systemd, amd64 or arm64.