Six years automating a fleet like yours. I wrote the software that ran it. It still runs.
Syncronis is not a first attempt. Before it there was one client and six years of automating their estate: market after market across four continents, tens of thousands of machines. The fleet ran on a mature configuration-management system that predated me. I worked inside it for eighteen months before concluding the architecture itself was the limit. The purpose-built agent I wrote to replace it was working in three weeks, and the four years after that were migration and tuning. That system is still in production a decade later, years after I stopped working on it.
That engagement is under a confidentiality agreement, so this page carries numbers instead of logos — the same discretion you would want about your own estate. Syncronis is not their software: it is a new product, written from scratch years after that engagement ended, and nobody else has a claim on it.
The fleet was never tidy. That is the part that taught me the most.
Three kinds of drift at once
Enterprise x86 servers alongside several generations of single-board ARM devices, each generation on a different Linux. Uniform hardware on a uniform image is the easy case, and almost nobody has it.
Scale that arrived market by market
Four continents, tens of thousands of machines, and every new market a fresh set of servers to stand up. The work that mattered was making the second one cost nothing.
From an afternoon to a coffee break
One update pass across the servers in a single country — over 1,400 of them — took about two hours forty with off-the-shelf tooling, and that was the good case, every machine online. The system I built did the same pass in five to fifteen minutes, unattended.
Syncronis is not that system. It is what those years taught me, rebuilt for everyone else.
The earlier system belongs to the client who paid for it, and it was built for one environment. Syncronis is a new product, written from scratch and general-purpose, which is why it has to do considerably more than the original ever needed to.
What carried over is not code. It is knowing which things break at three thousand machines that look fine at thirty: that a run which needs babysitting is a run nobody does on a Friday, that the fleet is never homogeneous, however much the inventory says it is, and that the moment your packages and credentials live on a vendor's infrastructure you have acquired a problem you cannot fix from your side.
Those three convictions are why Syncronis pushes instead of polls, why a package is a folder with a bash script instead of a new language, and why your data stays on hardware you own even on the hosted plan.
Nothing in your fleet waits on us.
The question behind "how big is the company" is really a question about continuity. Syncronis answers it in its architecture rather than its headcount.
Agents don't wait for a server
State stays enforced even when no control plane is reachable at all. A machine that cannot see the console carries on doing exactly what it was last told to do.
Self-host is the same binary
Not a stripped-down build, not a different product — same code, same console, running on your own hardware. It comes with an Enterprise agreement, and once it is yours there is no service anyone can switch off.
Your data is already yours
Packages, logs and credentials sit on machines you own, on the hosted plan too. There is no vendor-held copy to lose access to.
On top of that, you reach the product directly: support answers come from whoever wrote the code you are asking about, and there is no sales layer between your problem and the fix.
Ten minutes, and you can stop at two.
I will show you the console driving real machines. If two minutes in you can see it is not for you, we stop there and neither of us has lost an afternoon. Or skip me entirely: the first 5 machines are free and need no conversation at all.
Timotei Campian
· Founder and architect, Syncronis LLC
info@syncronis.net