Open: engine, API and command-line tools
The event-log, versioning and merge engine, the HTTP API and the command-line tools are published under the MIT licence in the public repository. It is early software, version 0.1, and no package has been published to crates.io.
Not open: the workspace and this website
The web workspace, the editor add-ins and this website are proprietary and live in a private repository. The public repository has no browser editors, no production configuration, no credentials and no user documents.
Your documents stay yours
Private document content you put into the hosted app does not become open source. Open source here describes the code, not the content.
OPEN SOURCE · 23 OCTOBER 2026
Open source, and what that covers.
The engine, the HTTP API and the command-line tools are open source under the MIT licence. This page says how to build them from source, which platforms they are tested on, what that testing covers and what is not published yet.
WHAT IS OPEN
Which parts you can read and run.
The public repository is the core that records and verifies history. It is not the hosted application.
BUILD FROM SOURCE
Build and test it yourself.
You need Rust at the version the repository pins. To run the tests you also need PostgreSQL 16, and the repository uses Docker and Task to start one.
- STEP 01 · get the source
git clone https://github.com/ArefinAlter/dynodoc-engine.git - STEP 02 · build everything
cargo build --workspace --locked - STEP 03 · check the command-line tool
cargo run --locked -p engine-cli -- --version - STEP 04 · run the tests (needs PostgreSQL 16)
cargo test --workspace --locked
The tests need a database login that is allowed to create databases and roles, so point them
at a throwaway PostgreSQL, never at one that holds data you keep. Running the API itself needs
a few settings and a restricted database login. The repository README gives those steps, from task up to task run. Read the README
PLATFORMS
Where it is built and tested.
Linux, macOS and Windows, on Intel or AMD processors and on Arm. Every job builds the whole workspace and runs the whole test suite against PostgreSQL.
| Platform | Tier | Tests passed | Real key store tested |
|---|---|---|---|
| Linux x86-64 | Tier 1 | Main CI workflow | Secret Service (GNOME Keyring) |
| Linux Arm (aarch64) | Tier 1 | 1,285 | Secret Service (GNOME Keyring) |
| macOS, Apple silicon | Tier 1 | 1,285 | Keychain (a temporary keychain) |
| macOS, Intel | Tier 1 | 1,284 | Keychain (a temporary keychain) |
| Windows x86-64 | Tier 1 | 1,285 | DPAPI |
| Windows on Arm (aarch64) | Tier 2, not blocking | 1,285 | DPAPI |
Tier 1: a failing build or test on that platform fails the workflow. Tier 2: built and tested, but a failure is reported without blocking, and nothing stronger is promised. Not supported: 32-bit systems, RISC-V, big-endian systems, musl, and Linux distributions older than the glibc floor below.
WHAT THE CHECKS PROVE
One run, with its date.
A row above is true for the commit its run names. The figures here come from one run of the engine repository’s platform workflow.
1,285 Rust tests passed on Linux Arm, Apple-silicon Macs, Windows and Windows on Arm. Intel Macs passed 1,284. The run started on 20 October 2026 (UTC) and all six jobs succeeded.
Each job built the workspace with a locked dependency list, ran the whole test suite against PostgreSQL, regenerated the OpenAPI file and compared it with the checked-in copy, and used the operating system’s real key store to protect a signing key, open it again and remove the stored secret. On Linux the key store job ran on both processors. On macOS it used a temporary keychain, and the login keychain was checked to stay clean.
The run, job by job (opens in a new tab) The support record (opens in a new tab)
PREBUILT TOOLS
No release is published yet.
Prebuilt command-line tools will be published as GitHub releases; none is published yet. Until one is, build from source.
The project’s release workflow has built engine-cli and engine-api natively for all six platforms, run each binary it built, unpacked each archive into a clean folder
and run it again from there. Three of the archives were also downloaded and run outside CI, one
on a Windows PC and two in Linux containers. The step that publishes a release has never run,
because running it would publish a release in the public repository. This section describes how
a release will be checked, and it is not a download page.
How a release will be verified
A release will have one archive for each of the six targets, holding engine-cli, engine-api, the licence and a short README, and one SHA256SUMS file. Compare the checksum before you run anything.
Linux
sha256sum --check --ignore-missing SHA256SUMSmacOS
shasum -a 256 -c SHA256SUMS --ignore-missingWindows (PowerShell)
Get-FileHash .\archive.zip -Algorithm SHA256On Windows, replace archive.zip with the name of the downloaded archive and
compare the result with the line for it in SHA256SUMS. A checksum shows that a
file is the one the release workflow built. It does not show who wrote the source.
The binaries will not be signed or notarised. The project has no
code-signing certificate. macOS Gatekeeper blocks a downloaded unsigned binary: once the
checksum matches, run xattr -d com.apple.quarantine engine-cli engine-api, or
open it once with a right click and Open. Windows SmartScreen shows an unknown-publisher
warning: once the checksum matches, choose More info, then Run anyway. Linux shows no
warning.
What they need from the system
| Target | Needs |
|---|---|
| Linux x86-64 and Arm | glibc 2.34 or newer, which covers Ubuntu 22.04, Debian 12 and RHEL 9. |
| macOS, Apple silicon and Intel | macOS 11 or newer. System libraries only. |
| Windows x86-64 and Arm | No Visual C++ redistributable. Windows 10 or newer is Rust’s own minimum for the target; it was not tested on a Windows 10 computer. |
CONTAINER IMAGE
Built for amd64 and arm64.
A container image of the API and the command-line tool is built and started in CI. It is not published yet.
The repository’s Dockerfile puts engine-api and engine-cli on Debian 12 (bookworm-slim) and runs them as a
non-root user. CI builds it natively for linux/amd64 and linux/arm64, on a runner of each processor. Each job checks the image’s
architecture, runs engine-cli --version, checks that engine-api refuses to start without configuration, and checks the user id. Both passed.
The images are not signed and carry no software bill of materials. The step that pushes them to a registry has not run, so there is no image to pull.
KNOWN LIMITS
What these checks do not cover.
The support record lists these too. They are repeated here so nobody has to find them.
- Windows on Arm is tier 2. It has no native PostgreSQL, so its job runs an x64 build of PostgreSQL 16 under emulation while the engine under test is native Arm. That job takes about 40 minutes.
- Windows x86-64 uses the PostgreSQL 17 that the runner image ships; every other platform uses PostgreSQL 16. The tests pass on 17.
- One latency test, which asserts that a server-sent event arrives within 100 milliseconds, runs in its own non-blocking step on Windows x86-64, Windows on Arm and Intel Macs. It failed on both Windows platforms every time it was recorded. It is not weakened, and it still blocks on the other platforms.
- Four tests are not run on any platform in the main run: a compression measurement, planning a hundred thousand commits, a million-leaf property test, and the real key store test, which has its own step.
- Tests run on the debug profile. The release binaries are only smoke tested: the version, the help text and the refusal to start without configuration.
- Not covered anywhere: real hardware and devices, 32-bit systems, big-endian systems, RISC-V, musl, Linux distributions other than Ubuntu, macOS older than 15 and Windows 10. The macOS 11 and glibc 2.34 floors are build settings, not test results.
- On Windows, the files that hold secrets for the API are not checked for permissions, and the hidden passphrase prompt is not tested in CI.
- On Linux the operating system key store needs a running Secret Service, which headless servers usually lack. A passphrase file is the tested alternative.
READ IT, RUN IT, TELL US
The code is public.
Found a problem? A security issue goes through private reporting. Anything else goes to the issue tracker.