01 · Group
Group machines into @sets
Gather machines into named @sets, by role, function, however you actually run. 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 — and 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
§ 04 Compared
How Syncronis compares.
The two 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 | |
|---|---|---|---|---|
| Language | Bash + JSON | YAML | Puppet DSL | Ruby DSL |
| Agent model | Persistent (push) | Agentless (SSH) | Agent (pull) | Agent (pull) |
| Change reaches fleet | On publish, near-instant | When you run it | Poll interval | Poll interval |
| 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 | Partial | Partial | Yes | Yes |
vs. fleet / edge management
| Syncronis | Mender | Balena | qbee | |
|---|---|---|---|---|
| Built for | Linux fleets, any size | Embedded OTA | Container edge | IoT / embedded |
| 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) |
| Rollout control | Targeting, windows, canary, version history | Phased rollouts (Ent) | Release pinning | Group config |
| Deploy preview | Simulate targets first | — | — | — |
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.