Security
Designed so you never have to trust it blindly.
Xtic touches your most sensitive systems, so its security model is written down, testable and conservative: nothing resident on your servers, keys that stay with you, and a record of everything.
§01On your servers
Agentless, pinned, least-privileged.
Xtic connects over SSH with a key per server or environment and refuses any server whose host key differs from the one an administrator approved. A reviewed onboarding script creates a backup user that may run exactly one thing as root: a small helper that validates its input and executes a fixed command line.
- 01Pinned host key
- 02Restricted backup user
- 03Helper: fixed verbs
- 04Native tools
- 05Stream to Xtic
| Verb | Validation | Runs |
|---|---|---|
tar-create | Paths canonicalised and checked against the read allow-list | GNU tar writing to the SSH stream |
tar-extract | Target must be a new restore directory inside the write allow-list | GNU tar extracting, never absolute paths |
docker-volume-export / import | Volume names validated | A helper container pinned by digest: no network, read-only, all capabilities dropped |
docker-pause / unpause | Container id or validated name | docker pause / unpause |
kill | Job id; pid file owned by root | Stops the job's process group |
version | — | Prints the helper version for the preflight check |
§02Inside Xtic
Identity and access
- TOTP authenticators and passkeys for every account; step-up re-authentication before sensitive actions.
- Built-in roles, custom roles and scopes that limit people to environments, servers and plans (Business).
- Four-eyes approvals for restores and administrative changes (Business).
- API tokens are hashed at rest and scoped like people.
Secrets and keys
- A master key outside the database (Docker secret or file) wraps every other key; without it Xtic refuses to start.
- SSH keys, database passwords and storage keys are envelope-encrypted with AES-256-GCM and are write-only in the UI.
- Backup file keys are wrapped by the key ring and, independently, by your offline recovery key.
- Keys rotate without re-uploading backups; old versions are never destroyed while a backup needs them.
Backups at rest
- Four encryption modes per plan, including public-key encryption that even the Xtic server cannot decrypt.
- BMENC v1, the platform-key format, is published with test vectors and a reference implementation.
- Separate storage credentials for writing and deleting; S3 Object Lock for immutable copies (Business).
- Every run is verified and its manifest signed, so a changed or truncated backup is detected.
Audit
- Every administrative action, secret access and restore in a hash-chained audit log: a removed or edited entry breaks the chain.
- A tamper check verifies the chain on demand; the log exports for your SIEM (Business).
§03What we see
We never see your backups.
Xtic runs on your infrastructure and stores to your storage. INTELLIENS INFOCOM LLP receives only licence and count data from licence check-ins — never backup content, hostnames or credentials. The Free edition sends an optional anonymous weekly ping you can switch off. Details in the privacy policy.
§04Vulnerability disclosure
Found a problem? Tell us.
Write to security@xtic.in with what you found, how to reproduce it and the version affected. Please do not include exploit code in the first message, and give us a reasonable time to fix it before you publish.
Our security.txt is at /.well-known/security.txt.
Draft policy
In scope: the Xtic product, xtic.in and my.xtic.in. We will not pursue good-faith research that respects users' data and privacy, avoids service disruption and stops at the proof needed. Response targets are published with the final policy.