Documentation
Install it, connect it, understand it.
Getting started, the concepts behind health and jams and misses, and a reference for the API, the Copilot and MCP.
Install
One command on any Linux server. The package name is supplied by the owner.
Install script
Linux, x86 or ARM. Verifies the signature, then installs.
curl -fsSL https://get.syncio.live/runtime | shPackage manager
Debian, Ubuntu and the Red Hat family.
sudo apt install [[RUNTIME_PACKAGE_NAME]]Docker
Run it beside the app it watches.
docker run -d --name syncio-runtime \ --pid host --network host \ -v /:/host:ro \ ghcr.io/syncio.live/runtime:latestKubernetes
One agent per node, as a DaemonSet.
helm install syncio oci://ghcr.io/syncio.live/charts/runtime
Quickstart
Install the Runtime on a server, connect it to a project, and see your first results within a couple of minutes. Nothing you do here changes the server: the first run only reads.
- 01Create an account and a project.
- 02Install the Runtime with one command.
- 03Connect it with a code or a project token.
- 04Watch the overview fill in.
Concepts
Health is a 0 to 100 score with the reasons behind it. Jams are things that are slow, stuck or saturated. Misses are things that failed or did not happen. Findings are specific issues a check turned up. Incidents are confirmed problems with a timeline. Every one of these is defined in full in the table below.
Connect a server
Install the Runtime, run the login command, and approve the code in the dashboard — or use a project token for automation. Either way the server belongs to one project, and you choose its access level. You can preview exactly what the server would send before you connect it, and you can stay in local mode where nothing leaves the machine at all.
Organizations and projects
An organization is the home for a team or a client. A project is a system inside it, grouping servers, tokens, alerts and settings. Settings inherit from the organization to the project to the server, so you set a default once and override it only where it needs to differ. Every inherited value shows where it came from, and every change is recorded in the audit log.
Tokens
Create tokens inside a project for a server, an SDK, the API or an assistant. Each has limited permissions and an expiry you choose, and you can revoke any of them instantly. A token is shown once when it is created; only a hash is stored, and a recognisable prefix makes a leaked key easy to spot in a log or a repository.
Access and safety
The Runtime is read-only by default. You set the access level per server, approve every change, and can undo it. A change runs against a snapshot, is verified by the same checks that found the problem, and leaves a receipt. Approvals, receipts and undo are described in full on the Trust page.
Troubleshooting
If a server has not reported, check that the Runtime is running and that it can reach the network. The server's own page shows the last time it was heard from and its last known health, so a gap is visible rather than silent. A server that has gone quiet is treated as a miss, not as a healthy server with no data.
Glossary
Health, jams, misses, incidents, findings, scans, fixes, access levels, receipts and pre-mortems — each defined the first time it appears, and collected here so a term never has to be guessed.
Concepts, defined.
The vocabulary the rest of the product uses, in one table. A term is defined here and used consistently everywhere else.
- Health
- A 0 to 100 score for a server, project or organization, with the points each problem is costing you and the fix that would recover them.
- Jam
- Something slow, stuck or saturated: CPU waiting in line, a disk that has gone slow, a network at its limit. Slowness you can still act on.
- Miss
- Something that failed or did not happen: a failed request, a backup that skipped, a certificate that lapsed. An absence, made visible.
- Finding
- A specific issue a check turned up, with the evidence and the suggested fix. Findings become approvals; approvals become receipts.
- Incident
- A confirmed problem, with a timeline of what happened, who was told, and what was done. It closes with a written note.
- Scan
- A pass over a server or an application looking for a class of problem — security posture, exposure, stale packages, leaked secrets.
- Fix
- A prepared change that addresses a finding. It is shown in full, approved by a person, run against a snapshot and verified.
- Access level
- How much Syncio may do on a server: Observe, Operate, Console or Agent. You set it per server and can lower it at any time.
- Receipt
- The record of a change: what it was, what it touched, the before and the after, and a one-click way to undo it.
- Pre-mortem
- The weekly ranking of the few things most likely to break next, so you fix them on a calm afternoon instead of a bad night.
Copy and paste.
The four blocks a new project needs: install, ask the API, call the SDK, and connect an assistant. Each is complete as written.
# Install the Runtime (Linux, x86-64 or ARM64).
curl -fsSL https://get.syncio.live/runtime | sh
# Sign the server in and approve it in the dashboard.
sudo syncio login
# Or connect unattended with a project token.
sudo syncio connect --token "$SYNCIO_PROJECT_TOKEN"curl https://api.syncio.live/v1/projects/prj_7f2/health \
-H "Authorization: Bearer $SYNCIO_TOKEN"import { Syncio } from "@syncio/sdk";
const syncio = new Syncio({ token: process.env.SYNCIO_TOKEN });
const health = await syncio.projects.health("prj_7f2");
console.log(health.score); // 86
console.log(health.reasons[0].fix); // "Free 5 points: clear disk on web-02"{
"mcpServers": {
"syncio": {
"url": "https://api.syncio.live/mcp",
"headers": { "Authorization": "Bearer $SYNCIO_MCP_TOKEN" }
}
}
}API reference.
The endpoints a first integration reaches for. Every list paginates the same way, every write takes an idempotency key, and every error has the same shape.
The Runtime CLI.
The commands the Runtime installs, and what each one is for. The one you will reach for most is preview: it prints exactly what would be sent before anything is.
syncio loginSign a server in and approve it from the dashboard.syncio connect --token <token>Connect unattended, for automation.syncio statusShow what the Runtime is doing right now.syncio doctorCheck connectivity, permissions and the service.syncio previewPrint exactly what would be sent, before sending it.syncio uninstallStop collection and leave nothing behind.
Questions the docs get.
The things a reader asks before the first install, answered here so they do not have to open a ticket.
Does the Runtime need root?
No. It installs as a normal service and asks for the least privilege it needs. Anything that would need more is surfaced as a request, not done quietly.
Which Linux distributions are supported?
Ubuntu, Debian, the Red Hat family including Alma and Rocky, and Amazon Linux. Other Linux distributions usually work; the install script tells you if it cannot.
Can I try it without an account?
Yes. Local mode runs the Runtime on its own and reports without an account. Nothing leaves the machine, and you can preview what would be sent before you connect it.
How do I keep a server out of the dashboard?
Leave it in local mode, or set its access level to Observe. You can also refuse remote control from a switch on the server itself.
What happens if the Runtime stops reporting?
The server is shown as quiet, and a quiet server counts as a miss. You are told, rather than seeing a stale green dot.
Is there a sandbox to try the dashboard?
Yes. A public demo project is available so you can look around the real interface without connecting a server of your own.
Something missing?
The docs grow with the product. If a page you need is not here, tell us and we will write it.