How Restow is actually built
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, from the most recent completed pass over the beta (internally "iteration 1"): 12 features were built and accepted, and 13 separate issues raised by the review step were fixed before release, not 13 features with bugs shipped anyway, 13 rounds of "this doesn't hold up yet, fix it" before the tag went out. As of the current release (0.303.0), the full automated suite that has to pass green: 4,168 tests in total, including 536 dedicated PostgreSQL integration tests across 45 test files 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. As of this page's last update, the next iteration is on hold, sequenced to start after the current release ships. 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 beta release shipped 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 release 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 "restore actually tested" 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, images built for amd64 and arm64 on native runners, and a release smoke run that gates the release, so nothing is published unless it passes. 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, and imports and exports mail files. Only after that are the images signed with cosign and given an SBOM.
Its limits are stated here rather than hidden. The Microsoft 365 check runs against a developer tenant and only when credentials for it are configured; it has not yet been run against a real tenant, and earlier testing used simulated Graph and IMAP servers. The upgrade from the previous release cannot run for 0.1.0, because there is no earlier public release. The endpoint check runs on Linux only. 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 AGPL-3.0 with the Restow Module
Exception, an additional permission for combining the core with
modules. The Business and Service Provider features live in
ee/, in the same repository, under the source-available
Restow Enterprise License, a separate license, 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.