How Osiris is actually built
Osiris 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.
Osiris 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, licence 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 Osiris 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. The project defines a release checklist that goes beyond the build loop's own tests: migrations against both an upgrade and a fresh install, health endpoints, a full backup-and-restore run with a byte-for-byte hash comparison against a real Microsoft 365 tenant and a real IMAP server, a restore proven from the standalone restore tool with no Osiris server running, every supported storage backend written to, read from and scrubbed, and a container vulnerability scan. As of 0.303.0, only the dependency audit and the PostgreSQL test suites run automatically in CI; the live-tenant, IMAP-server, standalone-restore, storage-target and image-scan checks are not automated yet, and no release has yet been tested against a live Microsoft 365 tenant. Testing so far has used simulated Graph/IMAP servers. Each release's changelog "Verification" section states exactly what actually ran for that release, not what the checklist eventually intends to cover.
Open source, so you don't have to take our word for any of this
The core (backup, restore, the audit log) is AGPL-3.0 (with a plugin exception); the Business and Service Provider modules are planned as separate, proprietary code unlocked by a licence key, not a different openness promise for the same thing. The repository atgithub.com/lcsfls/osirisholds the licence and project description today; the source code itself ships with the first public release, and until then development happens in a private repository. That's stated here plainly rather than implied otherwise by a link that looks further along than it is. Once it's public, the tests described above, the restore evidence, and the storage format are all things you can check yourself instead of trusting this page. Seeopen source for the licence details, including why the paid editions' key is a fair-play mechanism and not DRM.