# Running a sync

> How a reviewed run is queued, executed, verified and retried.

## Queued and durable

![Sync page with the Scope, Review and Run steps for a cross-account run](console:sync)

A run is queued in PostgreSQL and executed by the sync worker, a separate
process. When you queue it, the run **binds** the selected non-secret
configuration; when it starts, it checks that configuration and the AWS
identity again. A changed setup refuses rather than running something you did
not review.

One sync is queued or running at a time, across all users. While one is, a
new run is refused with `409 sync_run_active`. A queued run that is already
marked for cancel does not count.

Runs support cancellation, deadlines and partial-failure accounting. Failed
resources are recorded so you can retry only those.

## Concurrency

Mappings run with bounded, CPU-aware concurrency. The default caps per service
are ECR 4, S3 3, CodeCommit 3 and DynamoDB 3, and can be overridden with
environment variables.

## Verification, per service

| Service | What is verified |
|---|---|
| ECR | Root digest and descriptor-set equality after every tag write |
| S3 server-side copy | A destination HEAD bound to the copy receipt |
| S3 local upload | What actually landed |
| CodeCommit | Final source and destination ref parity |
| DynamoDB | Strong per-item reads |

The S3 worker relay does not read back uploaded bytes; it keeps a per-object
upload journal. S3 Batch records a waybill whose content verification is
marked `not_checked`.

## S3 worker relay limits

The relay stages all selected bytes before upload. A run is refused when the
selected bytes plus a 1 GiB reserve exceed the free space, and each mapping has
a one-hour cooperative deadline. For larger moves, use server-side copy or
[S3 Batch Operations](/docs/douklar/s3-batch-operations).

## Notifications

The console shows an inbox, a bell and a status pill, driven by a status-only
WebSocket. There are no external notifications: no email, webhook, Slack or SNS.

## Nothing runs on its own

There is no scheduling of any kind on the server. A run happens only when a
person starts it or a queued job is picked up.

Source: https://douklar.app/docs/douklar/running-a-sync (Douklar docs, last checked 2026-10-23)