How Restow is actually built
By Lucas Flores, IT Systeme Flores UG. Last updated
Restow is built by one engineer with AI assistance, through an automated implement-review-fix loop that repeats until tests and a written specification both pass, not a one-shot generation.
Restow is built by Lucas Flores, an IT systems engineer and owner of a small managed service provider near Cologne, not a professional software developer. The code is written with AI assistance (Claude), with his own understanding of Exchange, Graph and storage, and with a testing discipline that is not negotiable for a backup tool. If you read that and think it sounds like a risk, you are right to; this page is the detail behind why we think it's a manageable one, not a reason to trust it blindly.
Engineers do not get talked out of asking how software is actually made, and they shouldn't have to take a marketing page's word for it. So here is the process, with real numbers from the current beta, not a general statement that "AI helps us build faster."
The loop, specifically
Every feature goes through the same sequence, and it is not a one-shot: an agent implements it against a written specification, and a separate review pass checks the result against that specification and against the automated test suite: lint, type checking, and the tests, run for real against a PostgreSQL database, not mocked out. If a check fails, the work goes back for another round. There is no fixed number of rounds; it repeats until the checks pass or a human stops it.
Concretely, for 0.1.0: the full automated suite that has to pass green is 7,145 tests across all packages, 918 of them dedicated PostgreSQL integration tests across 77 test files, none skipped, that exercise real database behaviour (row-level security, migrations, concurrent jobs) that a mocked database would hide. These numbers move every release. This page states the ones current as of its last update, not a fixed claim. The production build is also checked booting in an actual browser before release, not assumed to work because the dev server does.
What a human actually does
The loop does not decide what to build or ship on its own. Lucas sets priorities, approves anything that changes the product's architecture, licensing or legal wording before it is built (not after), and can hold an entire iteration until he has signed off. Decisions with legal or financial weight (pricing, license terms, what a feature is allowed to claim about GoBD compliance) are his calls, recorded and dated, not something an agent infers.
When it breaks anyway
It has. One dated example, because "we test everything" is not worth much without one: an early internal build, before the first public release, produced a production build that rendered a blank page in a real browser, caused by a circular dependency between JavaScript chunks that the development server never surfaces. It was caught, and a same-day hotfix build both fixed the immediate bug and changed the build itself to fail loudly on a circular chunk in the future, instead of silently shipping one again. That is the standard we're holding this to: when something gets through, the fix includes making sure that specific mistake cannot happen silently a second time.
Why this matters more for a backup tool than for most software
A bug in a backup product does not just misbehave: it can mean data you thought was safe isn't. That's why Restow treats "proven restorable" as the product, not a feature: a backup that has never been read back through the restore path is shown as unproven, not as done. That is why a release has to pass more than the build loop's own tests. Every release goes through one pipeline: the full CI run on the tagged commit, the agent release signed by the maintainer, both builds (the full images and the Community images) built for amd64 and arm64 on native runners, and a release smoke run for each build and architecture that gates the release, so nothing is published unless all of them pass. The smoke run starts a fresh install and checks health, signs in with a passkey in a real browser, backs up and restores an IMAP mailbox and compares every message byte for byte, receives a journal report and checks the hash chain, restores with the standalone tool while the server is stopped and the container has no network, writes to, reads from and scrubs S3, local and NFS-style storage, runs a Trivy scan, backs up and restores a folder with the endpoint agent, imports and exports mail files and, since 0.4.0, backs up, browses and restores an SMB file share served by Samba, with its permissions and a copy job and, since 0.4.4, archives an IMAP account (existing mail taken over, new mail by IMAP IDLE, copies forwarded at transport, the same mail kept once, the hash chain verified) against a Dovecot (the Community run skips the journal, archive capture and storage-target checks, which need the Business modules or a second tenant). Only after that are the four images signed with cosign and given an SBOM.
Its limits are stated here rather than hidden. The final release smoke run of 1 October 2026 passed, for the full build, 9 of its 11 checks in full, 1 partly and skipped 1; for the Community build it passed 7 in full, 1 partly and skipped 3, two of them by design (the journal check and the storage target check need the Business modules or a second tenant and run in the full build). The Microsoft 365 check was skipped in both: it runs against a developer tenant and only when credentials for it are configured, and for 0.1.0 none were. Microsoft 365 backup and restore have therefore not yet been run against a real Microsoft 365 tenant in the release checks; they are covered by tests against a simulated Graph API. The partly passed check is the install: the upgrade from the previous release cannot run for 0.1.0, because there is no earlier public release. The endpoint check ran the agent's real install script only in a Linux container; the macOS agent ships, but its installer was not part of the release checks (the agent's own tests ran natively on macOS). Critical Trivy findings that have no fix yet, which cannot be acted on, are listed in the report, not hidden. The smoke reports are attached to each GitHub release, and each release's notes carry a Verification section that says exactly what ran for that release, not what the pipeline eventually intends to cover.
Open source, so you don't have to take our word for any of this
Everything outside ee/ is open source under the Apache
License 2.0. The Business and Service Provider modules live in
ee/, in the same repository, are licensed under the
Restow license terms and are unlocked
by a license key. The source code, including ee/, is public on
GitHub,
where every release is published. Version 0.1.0, the first public
release, is out now, so the tests described above, the restore
evidence, and the storage format are all things you can check
yourself instead of trusting this page. See
open source for the license details,
including why the paid editions' key is a fair-play mechanism and
not DRM.