One operator, not a platform team
No cluster to stand up, no team to staff around it. One person describes a change once and ships it to thousands of machines — targeted with @sets, pushed the moment it's published.
§ 00 · Linux Fleet Orchestration
Production-ready · onboarding new teams
One engineer. Thousands of machines.
For teams running tens to thousands of Linux machines, with no platform team to staff:
-
One console. Configuration, packages and scripts for every machine — described once, published once.
-
Nothing new to learn. A package is a folder with a bash script — that's the entire format.
-
Landed in seconds. Push delivery the moment you publish; delta transfers move only what changed.
-
Proven identity. Mutual-TLS between every machine and the control plane — no shared secrets.
-
Your data stays yours. Packages, logs and credentials never leave hardware you own.
Up and running in minutes. Your first 5 machines are free, no card required.
syncronis · machines
A real capture of the running product. Live data, no mockups.
Built for
Why it pays
1 engineer
does the work of a whole team — describe a change once, ship it to the entire fleet. Headcount saved, not hired.
The cost of manual →
minutes
not days of machine-by-machine DevOps work: deployments, updates and mass reconfiguration in one publish.
Watch a rollout land →
1 source
of config truth: your vault builds the exact configuration for each machine — or the whole fleet. Zero drift.
How config builds →
real-time
logs, reports and alerts on every change — attributed, fleet-wide, ready for the auditor. Hand-run boxes leave no trail.
Security & data →
§ 01 The cost of manual
Running the fleet by hand costs more than it looks.
Engineering hours lost one box at a time. Config drift that becomes a 2 a.m. incident. An audit nobody can answer. Syncronis turns all of it into one place to describe a change and watch it land.
the manual way
# one box at a time
$for h in $(cat hosts.txt); do
ssh "$h" 'dpkg -i my-app_2.4.1.deb'
done
web-14: Connection timed out
web-31: dpkg: dependency problems
^C
# ...which ones actually finished?
syncronis · one publish
# describe once, publish once
$console › rollout › publish
web-01 ✓ landed
web-02 ✓ landed
web-14 offline — catches up on reconnect
# live progress, attributed history
Illustrative terminals — the shape of the problem, not a benchmark.
A bad change can't take everything down
Roll out to a single machine or a handful you pick, watch it, then widen. A mistake costs you those machines, not the whole fleet.
An answer when the auditor asks
The fleet keeps its own record: which version landed where, when, started by whom. No "which box is on which version?", no reconstructing history from memory.
A folder with a bash script. That's the entire package format.
No .deb to build, no manifest schema, no packaging pipeline. If you can write a bash script, you already know how to use Syncronis.
§ 02 The console
One pane over the whole fleet.
Pack a folder, describe a change, watch it land, keep an eye on your vault. Every screen is a real capture of the running product, from a live tenant — click any to read it full-size.
00 · The package
The whole format, in one look.
Your files, plus a bash entry script — any *.sh. Put them in a directory and it's ready to ship: point the next rollout at it and publish.
my-app · package
$tree my-app/
my-app/
├── apply.sh # any bash script
├── app.bin
├── settings.conf
└── assets/
└── dashboards.json
01 · Describe
Point a package at a target, then set the schedule window, timeout and failure policy. A structured form, no scripting required.
syncronis · rollout — new deployment
02 · Watch it land
Hit publish and watch it land: per-machine progress, completed vs. pending counts, deploy activity in real time.
syncronis · rollout — progress
03 · Vault health
Your vault as the console sees it: hardware, transfer capacity and throughput on your own server, refreshed every few seconds.
syncronis · vaults
§ 03 Centralized configuration
One source of truth, built for each machine.
Most fleets keep configuration in a dozen places: a script here, a template there, a secret pasted into a wiki. Syncronis pulls it into one place, and your own vault builds the exact config each machine should have, automatically, every time.
Set a value once at the top, and each group or environment can refine it further down. Change the source, publish, and the rendered config lands across the fleet in one pass.
org ntp_server = pool.ntp.org
↓ inherits
realm ntp_server = pool.ntp.org
↓ overrides
cell ntp_server = 10.0.40.1
↓ renders
machine ntp_server = 10.0.40.1 ✓
Inherit & override
Set a value once; each group and environment refines it. No copy-paste drift across hundreds of hosts.
Packages delivered with it
Config and the packages it needs ship together, and only the changed parts move, not a full re-download each time.
Packages, logs and credentials never leave hardware you own.
§ 04 Security & data
Built for the questions your auditor will ask.
Data ownership isn't a setting you switch on: it's the architecture. Two planes, one line between them — then every guarantee below, point by checkable point.
Control plane · ours or yours
server Coordinates
Rollout intent, config, machine status. Stores no tenant data —
your payloads never touch it.
gRPC intent ↓ · status ↑
Your hardware · data stays here
vault Your vault
Packages, logs, credentials and rendered secrets, on a server
you control.
HTTPS packages ↓ · logs ↑
agent Your machines
Run the change — and keep running if the control plane is
unreachable; agents reconnect on their own.
-
No tenant data on the control plane
Packages, logs and credentials live on a vault you control. Our servers, or yours, never store them.
-
Every machine proves its identity
Each machine and the server prove who they are to each other with client certificates. No shared secrets sprayed across the fleet.
-
Secrets that never leave your servers
Per-machine secrets are assembled on your own infrastructure. They never pass through our servers.
-
You decide who can change what
Four roles (principal, lead, engineer, observer) decide who can see and change what, down to a single realm or cell.
-
Attributed change history
Every rollout and config change carries who-changed-what. The fleet's history is accountable, not anonymous.
-
Breached-password rejection
New passwords are checked against known-breach lists and rejected if already exposed. Stronger sign-in, by default.
§ 05 Where it fits
Built for Linux fleets — and only that.
Runs on ubuntu debian rhel fedora rocky raspberry pi os — any Linux with systemd · amd64 / arm64
It earns its keep on the fleets that are painful to run by hand:
Retail & POS estates
Machines across stores and branches, rolled out together or tuned store by store, each with its own config.
Read more →
Edge & IoT fleets
Devices in the field on unreliable networks, updated without a site visit.
Read more →
Server & compute fleets
Build farms, render nodes and app tiers that have to stay in sync.
Read more →
MSPs & managed fleets
Every client's fleet behind one console: a realm per client, access scoped to it, every change attributed.
Read more →
Where it sits among the tools you know is a deliberate choice. Two axes draw it: who triggers delivery, and where your data lives.
your hardware their cloud you run it lands on publish
Ansible & peers
config management
Edge platforms
embedded / IoT clouds
Syncronis
fleet orchestration — nobody builds here —
-
vs. config management
Ansible and its peers wait for you to run them. Syncronis delivers the change itself, the moment you publish.
-
vs. edge / embedded platforms
They hold your data in their cloud. Syncronis keeps it on your vault, hardware you own.
-
what it isn't
Not Kubernetes, not infrastructure-as-code. It delivers your packages and runs your scripts, where and when you decide.
One static binary
Control plane, vault & agent — zero dependencies
Your data, your hardware
Packages, logs & secrets stay on your infra
No lock-in
Self-host the whole stack anytime, same binary
Founder support
Direct, hands-on onboarding for every team
§ 06 Get going
Live in minutes. Priced for any size.
Nothing to procure, no platform to stand up. Create your organization, enrol a machine, publish your first rollout.
5
machines free to start, no card required
$0.50
per machine / month at the largest tier
~13 MB
the whole agent, on every machine
0
runtime dependencies to patch or break
Step 01
Create your org
Sign up in a browser, no card, no sales call. You're in and ready to enrol machines.
Step 02
Enrol a machine
One command on any Linux box with systemd. It joins with a one-time token, no shared secrets.
Step 03
Publish a rollout
Target it, hit publish, watch it land live with per-machine progress.
web-01 · enrol
# From the console: Machines → Enroll machine → copy the one-liner
$curl -fsSL -H "Authorization: Bearer ••••••••••••" \
https://app.syncronis.net/install/agent/R001/C001/web-01 | sudo bash
# Token is single-use, consumed on install. web-01 shows up in Machines, online.
The exact one-liner the console generates for each machine — token redacted. Installs the agent, enrols with mutual-TLS identity, starts the systemd service.
One operator runs the fleet, from a few dollars a machine. First 5 free.
From $3 down to $0.50 per machine / month · pay annually and get two months free · evaluate your whole fleet with a 14-day trial.
Take the fleet off manual.
Create your organization and publish your first rollout today. Running a larger fleet, or want a hand setting up? Every team we onboard gets direct founder support.
Prefer the technical detail first? Read the architecture.
Click anywhere · Esc to close