Thanks for taking a look. Dockup is a small tool with a strict idea: the volume owns its backup policy, Dockup owns the destinations.

Development environment

• Go 1.26 (see go.mod)
• Docker with buildx for image work

$ make test     # unit tests
$ make race     # with the race detector
$ make lint     # gofmt, go vet, staticcheck
$ make build    # ./dockup

Unit tests must not require a Docker daemon. Anything that talks to Docker is tested through the small interfaces in internal/plan and internal/dockerx, or by the integration suite.

Ground rules

• No silent failures. Invalid labels, unreachable targets and failed prunes are reported (logs, dockup plan, dockup status, metrics) rather than skipped.
• No destructive defaults. Retention keeps the newest archive, encryption is opt-in per source, and only containers that carry dockup.stop are stopped.
• Labels are an API. Renaming a label or changing its meaning is a breaking change and needs a migration note in docs/labels.md.
• Secrets stay out of logs. Any new secret field must be added to internal/config/redact.go and to the redaction test.
• Errors wrap with context: fmt.Errorf("do thing: %w", err).

Tests

• Table driven unit tests next to the code.
• Retention and scheduling use an injected clock and timezone.
• Target adapters are tested against gofakes3; no network access.
• Integration tests (make integration) build the image, start MinIO and drive real deployments against the Docker daemon. Every container and volume they create carries dockup.test=true so a crashed run can be cleaned up safely.

Documentation website

The docs are also published as a site (VitePress, served by nginx). The pages are generated from docs/, README.md and CONTRIBUTING.md, so edit those — never the generated files under website/.

$ cd website && npm ci
$ npm run dev      # live preview at http://localhost:5173
$ npm run build    # what CI builds

Recipes and the landing page are hand-written in website/. When cutting a release, snapshot the docs with npm run freeze -- vX.Y; see website/README.md.

Commits and pull requests

• Conventional commits: feat:, fix:, docs:, chore:, test:, refactor:.
• One logical change per pull request, with tests and documentation.
• PR titles follow the same convention; the body explains the behaviour change and how it was verified.
• CI must be green: formatting, vet, staticcheck, unit tests, image build.

Releasing

Releases are cut from main with a vX.Y.Z tag. The CI workflow publishes multi-arch images (linux/amd64, linux/arm64) to gitea.vladfaust.com/vladfaust/dockup with the tag name and latest.