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.
Its architect spent six years automating one client's estate and wrote the fleet-management software that ran it — deployed market after market across four continents, tens of thousands of machines. That system is still in production a decade later. Syncronis is a new product, written from scratch. Who builds this →
For teams running tens to thousands of Linux machines, with no platform team to staff it:
-
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. Pushed the moment you publish, and 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
If you run one of these, it was built for you.
Why it pays
What one console is worth to the business.
1 engineer
does the work of a whole team — describe a change once, ship it to the entire fleet. Headcount you save instead of hire.
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 each machine should have, whether that's one box 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. Boxes run by hand leave no trail.
Security & data →
The number under all four: 10,000 machines on one server, measured on the product's own benchmark suite — not a model. See the numbers →
§ 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 replaces all of it with 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 — and every guarantee below follows from that line.
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 records 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.
The downside, if it doesn't work out
Trying it is a small, reversible decision.
-
The first 5 machines are free for good
Not a trial that expires into an invoice. No card, no call, and nothing to cancel if you walk away.
-
Prove it on the real fleet, not a sample
A 14-day trial takes any number of machines. No charge until day 14 — cancel before then and you are never billed.
-
There is no data of yours to get back
Packages, logs and credentials sit on your own vault from day one, hosted plan included. Leaving costs you a migration nobody has to run.
-
Nothing in your fleet waits on us
Machines keep running what they were last told to run with no control plane reachable at all — and the whole stack can move onto your own servers, same binary. What keeps running →
§ 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 →
Public sector & critical infrastructure
Estates that have to stay inside the institution's own perimeter, on hardware it owns.
Read more →
Where it sits among the tools you know is a deliberate choice. Two axes place it: who triggers delivery, and where your data lives. GitOps scores what we score on both, so it shares our corner here — what separates us is what has to be running underneath.
your hardware their cloud you run it lands on publish
Ansible & peers
config management
Edge platforms
embedded / IoT clouds
Argo CD · Flux
gitops · in-cluster
Syncronis
fleet orchestration — nobody builds here —
GitOps reached this corner first, inside a cluster. Syncronis is the same corner for the machines that will never be in one.
-
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
Direct founder support
Onboarding, and answers from the person who wrote the code
§ 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. It installs the agent, enrols it with a mutual-TLS identity, and 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