Architecture

How it actually works

The short version of the whole design: we are built so that holding your backups gives us as little as possible. This page is the long version, and it is written so you can check the claims on the rest of the site rather than take them.

Execution

Three paths, and one axis that varies

In all three the artifact ends up in storage under the same encryption and the same retention. What actually differs is custody of the source: who connects to it, and where the credential for it lives.

One vaultsame encryption,same retention,same artifact01Your CI/CDcron, pipeline, scriptYOU RUN IT, YOU PUSH IT02Your workeryour hardwareWE SCHEDULE IT03Our workerour infrastructureWE RUN ITMORE HANDED OVER AS YOU GO DOWN. THE RIGHT-HAND SIDE NEVER CHANGES.

Push

You produce the file in your own automation and submit it. There is no source type, because there is no source we ever connect to. We are purely a vault.

Who executes
You do
Source lives
We never see it
Schedule
Yours

Scheduled on your hardware

You run a worker; we hold the schedule and drive it. The connection details live in the worker's own config file and are rejected if sent to our API.

Who executes
Your worker
Source lives
Your worker's config, only
Schedule
Ours

Fully managed

You hand over a connection and we execute the backup. The whole payload, connection facts and credentials together, goes to a secrets manager and is read only at run time.

Who executes
We do
Source lives
A secrets manager, only
Schedule
Ours
Lifecycle

What happens to one backup

01Producedon your machine02Encryptedyour key03Uploadeddirect to storage04Sealedunder a lock05Expiredon scheduleTHE NETWORK IS CROSSED HEREUNREADABLE FROM HERE
  1. 01

    Produced

    The bytes are generated where the data already lives: your CI runner, your worker, or ours. Nothing is streamed to us in the clear at any point.

  2. 02

    Encrypted

    Your public key is applied on that same machine, before anything crosses the network. We hold public keys only and there is no key escrow.

  3. 03

    Uploaded

    Ciphertext goes directly to object storage against a short-lived, scoped URL. Bulk data never passes through our orchestration; only metadata does.

  4. 04

    Sealed

    The artifact is checksummed, sized, recorded, and stamped with the hold in force the day it was written. Editing the policy tomorrow cannot reach back and shorten it.

  5. 05

    Expired

    A sweep removes what has aged out of policy. Under-deletion is the safe direction: an object whose record is gone is left alone rather than guessed at.

Properties

Four decisions that are hard to reverse

These are the ones that shape everything else, and the ones worth disagreeing with us about if you are going to.

A CRON JOBworker restartsthe run is gone, and nothing says soA DURABLE RUNresumes from the step it reachedcompletes

Our database holds no source payload

For any path. Not the host, not the port, not the database name, and certainly not the credential. What we persist is metadata: a name, a kind, a source type, a schedule, a retention policy, a key fingerprint. The trade is deliberate and we would rather state it than hide it: after a refresh the dashboard cannot re-display a connection, so you re-enter it or keep your own config.

Runs are durable, not best-effort

Execution is driven by a durable engine rather than a timer. A run survives a worker restart, a network partition or a redeploy, and resumes from where it stopped instead of starting over. This is the difference between a schedule and a cron entry that silently stopped firing in March.

The two execution planes are separate

Backups you execute and backups we execute are driven by two independent orchestration clusters. A customer-side worker never joins the cluster that runs our own systems, and its failure domain is its own.

Metering never fails the backup

Usage accounting runs after the artifact is sealed, and a failed accounting write is logged and dropped. A backup is not worth trading for a billing row, so under-billing is the direction we accept.

Destinations

Where the artifact lands

A workspace defines destinations and an artifact lands in each of them. Copies in our storage are billed as more stored bytes; storage you own is not billed by us at all.

one artifactencrypted onceOUR CUSTODY, BILLED AS STORAGEPrimaryrestores prefer thisSecondarya different providerYour own bucketyour account, your custodyoutside our custody, so wecharge nothing to store it

Primary

Our storage. The default, and the one restores prefer.

Secondary

Our storage at a different provider. This sells provider independence, not a cheaper tier: it is ordinary storage rather than a cold class, because cold classes charge for retrieval and one real disaster-recovery restore can cost more than a year of storage.

Your own bucket

Artifacts land in storage you own, in your account. You keep custody; we orchestrate, verify and track every run against it. For a compliance-heavy buyer this is often the only acceptable shape, and it removes our largest recurring cost, so the incentives point the same way.

Recovery

You can open an artifact without us

Every artifact records its own format, compression and encryption. The procedure to unpack one by hand uses tools that are already on your machine, and it is documented rather than implied. The CLI has a restore command, and it is a convenience, not a dependency.

This matters more than it sounds. A backup you can only open through a vendor is not a backup, it is a subscription with your data as collateral. Getting your data out works in every account state, including one that has run out of credit, and it is metered like any other transfer.

your artifactself-describingsaved restoreconvenient, and optionalgpg -d | tar -xzf -tools already on your machineusyour data backeither wayTHE LOWER ROUTE NEVER TOUCHES US