• Common Lisp 61.2%
  • Go 20.3%
  • Shell 14.6%
  • Makefile 1.7%
  • HTML 1.6%
  • Other 0.6%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Pascal J. Bourguignon fec5f8a764 docs: add poseidon continuation note for demo/test setup
Hand-off for the Claude Code instance on poseidon (Linux): build/run
cheatsheet, the demo-server topology (nginx terminating TLS in front of
loopback-bound ota-server instances, one per demo/test subdomain), the
known Woo-sendfile-under-TLS risk that motivates proxy TLS termination,
and the project hard rules to respect.

The repo is otherwise clean and synced across origin/github/local at
v1.7; this note carries no code change.

Signed-off-by: Pascal J. Bourguignon <pjb@informatimago.com>
2026-06-27 18:32:25 +02:00
.github/workflows Cut v1.0.2 2026-05-09 21:17:33 +02:00
admin release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
client release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
docker Cut v1.0.3 2026-05-09 21:52:51 +02:00
docs docs: update user manual for v1.3-v1.7 features 2026-05-11 00:11:43 +02:00
examples/hello Phase 0: contracts, scaffolding, vendor tooling 2026-05-01 16:48:53 +02:00
issues/open docs: add poseidon continuation note for demo/test setup 2026-06-27 18:32:25 +02:00
marketing marketing: refresh delta-ota.html with v1.x feature wins 2026-05-10 18:37:34 +02:00
schemas Phase 0: contracts, scaffolding, vendor tooling 2026-05-01 16:48:53 +02:00
server release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
tests/e2e release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
tools release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
vendor Fix CI: portable vendor hashes, Dockerfile.dev pkgs, subshell cd 2026-05-01 17:17:21 +02:00
.gitignore .gitignore: cover every tests/e2e/run-*/ working dir with a glob 2026-05-10 02:38:20 +02:00
.gitlab-ci.yml release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
CHANGELOG.md release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
CLAUDE.md Fix CI: Dockerfile.dev parse error, DAG-mode verify jobs 2026-05-01 17:12:02 +02:00
LICENSE Establish delta-ota project: spec, plan, scaffolding 2026-05-01 16:40:32 +02:00
Makefile release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00
README.md ota-agent: implement list, show, verify, prune 2026-05-10 01:35:40 +02:00
VERSION release-1.7: opt-in client emails + upgrade-notification webhook 2026-05-11 00:04:33 +02:00

Ogamita Delta OTA logo

Ogamita Delta OTA

delta-ota is an over-the-air software-distribution system for large packages (≥ 2 GB). After an initial full download, every upgrade transfers only a binary delta (bsdiff in v1) between the user's installed release and the targeted release — typically a few percent of the full payload.

Owned and distributed by Ogamita Ltd.


Executive summary

Shipping software to thousands of users with multi-GB binary artefacts is hard. Vanilla auto-updaters re-download the whole payload every release. CDNs make it cheap to distribute, but they do nothing about the time and bandwidth that each user loses every time. Users on flaky Wi-Fi or constrained corporate links fall behind, get stuck on broken intermediate states, or simply stop updating.

Ogamita Delta OTA gives you a binary-delta upgrade pipeline that ships the change between two releases, not the whole release. A typical 2 GB monthly upgrade transfers about 20 MB — roughly 1 % of a full re-install. The client-side library is a single self-contained binary per OS (Windows, macOS, Linux), with no DLL hell, no admin rights required, no runtime to install. Failed downloads or interrupted patches never break the running installation: the agent only flips the active distribution once the new bytes have been fully validated on disk.

The system is dual-licensed: AGPL-3.0-or-later for open-source use, commercial licences from Ogamita Ltd. for proprietary distribution. See Licensing below or contact sales@ogamita.com.


Features

  • Binary deltas via bsdiff (default) or xdelta3, content-addressed by SHA-256.
  • Deterministic blobs (byte-identical builds) so deltas stay tight.
  • Atomic on-disk switch-over on the client: a failed download or patch never breaks the running installation.
  • Multiple releases coexist on the server as long as any client still uses them; users may skip releases.
  • Server-side classifications and channels (stable / beta / canary / per-customer) for staged rollouts.
  • Recovery tool with multi-step rollback to known-good "anchor" versions.
  • Server in Common Lisp (SBCL + Woo) with kernel-level sendfile(2) for GB-class blobs.
  • Client (libota + ota-agent) in Go, single static binary per OS, no runtime dependencies, no cgo, no DLL hell.
  • Self-contained: bsdiff, xdelta3 and tar implementations are vendored under permissive licences (MIT / BSD / Apache-2.0) and built into the project — no system tools required at runtime.
  • HTTPS / mTLS, Ed25519 manifest signatures, replay/downgrade protection.
  • Deployable as a single dedicated server or as a Kubernetes workload with PostgreSQL + S3-compatible blob storage.

Architecture

+---------------------------+        +-------------------------+
|   Developer workstation   |        |   User workstation      |
|   (Win/macOS/Linux)       |        |   (Win/macOS/Linux)     |
|                           |        |                         |
|     ota-admin CLI         |  HTTPS |    ota-agent + libota   |
|     (publishes releases)  +------->+    (installs / upgrades)|
+---------------------------+        +-------------------------+
              |                                    ^
              |                                    |
              v                                    |
   +-------------------------------------------------+
   |                ota-server (Linux)               |
   |   HTTP/JSON API · Woo + sendfile · SQLite/PG    |
   |   bsdiff / xdelta3 patch builder · Ed25519      |
   |   blobs/patches on local FS or S3-compatible    |
   +-------------------------------------------------+

Datasheet

System limits, operational figures, boundaries, compatibility commitments and standards live in docs/delta-ota-datasheet.org. A printable PDF is generated by make docs-pdf (output in build/docs/delta-ota-datasheet.pdf).

Status

Pre-1.0. See docs/ota-implementation-plan.org for the phased delivery plan.

Documentation

Quick start (development)

Requires Docker.

git clone https://gitlab.com/ogamita/delta-ota.git
cd delta-ota
make vendor-verify           # check vendored sources are unmodified
docker compose -f docker/docker-compose.yml up --build

Once the stack is up:

# publish a sample release from a developer workstation.
# OTA_ADMIN_TOKEN must match the value the server was started with —
# the docker-compose dev stack uses the built-in default "dev-token".
# For production deployments, see docs/operations.org §Authentication.
OTA_SERVER=http://127.0.0.1:8443 \
OTA_ADMIN_TOKEN=dev-token \
  make publish DIR=./examples/hello \
               SOFTWARE=hello VERSION=1.0.0 \
               OS=linux ARCH=amd64

# install it from a user workstation
client/build/linux-amd64/ota-agent install hello \
    --server=http://127.0.0.1:8443

For a non-Docker development setup (SBCL + Go installed locally):

make setup           # check toolchain, install Lisp deps via Quicklisp
make build           # build server, admin, libota, ota-agent
make test            # unit + integration tests (server + admin + Go)
make run-server      # start ota-server on localhost:8443

The build artefacts land at:

server/build/ota-server                # standalone executable
                                       #   subcommands: serve | migrate | gc | shell | version | help
admin/build/ota-admin                  # standalone executable
                                       #   subcommands: publish | mint-tokens | version | help
client/build/<os>-<arch>/ota-agent     # standalone executable (Go, static)
                                       #   subcommands: install | upgrade | revert | doctor | watch
                                       #               list | show | verify | prune
                                       #               version | licenses

Each binary parses its own arguments (./ota-server help, ./ota-admin version, etc.) — there is no SBCL invocation or wrapper script to remember.

Convenience targets that wrap the admin CLI:

# Publish a release. Required: DIR, SOFTWARE, VERSION, OS, ARCH.
# Optional: OS_VERSIONS, CLASSIFICATIONS, SERVER.
# OTA_SERVER and OTA_ADMIN_TOKEN are honoured by the binary.
OTA_ADMIN_TOKEN=dev-token \
  make publish DIR=./examples/hello SOFTWARE=hello \
               VERSION=1.0.0 OS=darwin ARCH=arm64

# Mint install tokens in bulk from a CSV. Required: CSV.
# Optional: CLASSIFICATIONS, TTL ("7d"…), OUTPUT, SERVER.
OTA_ADMIN_TOKEN=dev-token \
  make mint-tokens CSV=users.csv CLASSIFICATIONS=stable TTL=7d

# Build the single-host server install tarball (debug / test / eval only —
# production deployments use the published container image).
make dist-server VERSION=1.0.2

Deployment

Two supported topologies:

  1. Single dedicated host — typical for customer-hosted deployments in their own data centre. SQLite catalogue, filesystem blob storage, systemd unit, OS-managed TLS certificates.

  2. Kubernetes — for cloud deployments. PostgreSQL for the catalogue, S3 / S3-compatible (MinIO, AWS S3, Scaleway, OVH, …) for blobs and patches, the server image scales horizontally behind a load balancer.

The same container image (registry.gitlab.com/ogamita/delta-ota/server) serves both topologies; the storage and database backends are selected in ota.toml.

The server image is published as a multi-arch manifest for linux/amd64 and linux/arm64, so it pulls natively on x86_64 cloud hosts and on Apple-silicon (macOS arm64) developer machines under Docker Desktop.

Hosting and contributing

The GitLab repository is authoritative. Pull requests on the GitHub mirror are accepted but rebased onto the GitLab pipeline.

Contributions require a Developer Certificate of Origin sign-off (git commit -s). See CONTRIBUTING.md once published.

Licensing

delta-ota is dual-licensed:

Open source — AGPL-3.0-or-later

delta-ota is released under the GNU Affero General Public License, version 3 or later (AGPL-3.0-or-later). See LICENSE. In short:

  • you may use, study, modify, and redistribute the software;
  • if you run a modified version on a server that is reachable over a network, you must offer the corresponding modified source to the users of that service;
  • derivative works must themselves be licensed AGPL-3.0-or-later.

The AGPL applies to the delta-ota server, the admin CLI, ota-agent, and libota in their entirety. Linking your own application against libota makes that application a derivative work under the AGPL. Read the licence text for the precise terms.

Commercial

If the AGPL is incompatible with your distribution model — for example, if you ship libota as part of a proprietary application, or run a modified server without offering source to its users — commercial licences are available from Ogamita Ltd.

Commercial licences also typically include:

  • the right to ship libota linked into proprietary applications;
  • support and maintenance options;
  • guaranteed response times for security fixes;
  • on-premises deployment assistance and customisation.

Contact: sales@ogamita.com — please include a brief description of your intended deployment and distribution model.

Trademarks

Ogamita and Ogamita Delta OTA are trademarks of Ogamita Ltd. The AGPL grants no trademark rights; see LICENSE and the relevant trademark policy.

Copyright © 2026 Ogamita Ltd. and contributors. All rights reserved.