Cloud backup for servers
A headless client, a token per project, and a schedule. No agent framework, no console to babysit.
Servers back up differently
A workstation backup can ask a person for a decision. A server backup cannot. It has to run unattended for months, survive reboots and maintenance windows, tolerate a broken link mid-transfer, and never block the workload it is protecting. And the data is rarely just files: it is databases that must be quiesced, container volumes that outlive their containers, and configuration that is worthless if restored to the wrong host.
Setting it up
The client is a single binary for Linux and Windows Server — no runtime, no agent framework, no management server. Install it, create a write token for the project in the portal, list the paths, set a schedule. On Linux that is a cron entry or a systemd timer; on Windows Server it is a scheduled task. From then on it is quiet: encryption happens on the server, uploads are chunked and resume after a dropped connection, and the portal shows every run.
Unattended by design
Runs headless, retries on its own, and picks an interrupted transfer back up where it stopped instead of starting over.
Immutable retention
Nothing can delete a backup before its retention expires — including a compromised root account on the server itself.
Encrypted before it leaves
The server encrypts; the keys stay there. Details on the security page.
Per-project isolation
Every project has its own tokens and its own retention. A compromised host reaches its own project and nothing else.
Databases and containers
Databases: dump first, then back up the dump. Copying the data directory of a
running database at file level produces an archive that may or may not restore — the engine
was mid-write. Write pg_dump, mysqldump or the equivalent to a
directory that the client covers, and let retention age the old dumps out. The dump is
consistent, compresses well, and restores into any host.
Containers: back up the volumes, not the containers. An image is rebuildable; the volume is not. Cover the host paths behind your named volumes, and for databases running in containers, run the dump inside the container onto a mounted host path that is part of the backup set. The Docker Compose walkthrough shows the pattern end to end.
Automation and least privilege
Everything the portal does, the REST API does too: create projects, issue and revoke tokens, list runs, trigger restores. That makes fleet rollout a loop rather than a click-path, and it keeps backup configuration next to the rest of your infrastructure code.
Tokens are split by purpose: a write token can send data but cannot read it back, a read token can restore but cannot alter anything. Servers get write tokens only — so credentials lifted from a backed-up host cannot be turned around and used to exfiltrate the backups.
Start free · API documentation · Pricing
Frequently asked questions
How do I back up a server to the cloud?
Install the open-source client on the server, create a write token for the project in the portal, define the paths and a schedule, and let it run headless. On Linux it runs from cron or a systemd timer, on Windows Server from the Task Scheduler. Data is encrypted on the server before it leaves it.
Which server operating systems are supported?
Linux and Windows Server. The client is a single self-contained binary with no agent framework and no runtime to install; macOS is planned.
How do I back up a database?
Dump first, then back up the dump. A file-level copy of a running database's data directory is not consistent. Write the dump to a directory the client covers, and let the retention policy age out the old ones.
Can I back up Docker volumes and container data?
Yes. Back up the volume paths on the host like any other directory. For databases in containers, run the dump inside the container and write it to a mounted host path that is part of the backup set.