Platform tooling · Versioned document vault

SynthVault — the regulated authority for what was approved when.

Versioned file vault designed for regulated environments. Source-control-style checkout / checkin, SHA-256 hash- chain audit, periodic integrity sweeps, webhooks for integration with build pipelines and document workflows, backup / restore. Optional 21 CFR Part 11 retention mode (license-gated). Used internally as the storage substrate beneath SynthQMS and available standalone for any organization needing versioned, audit-trailed file storage.

Not a medical device — same platform-tooling category as SynthQMS. Different role: SynthVault holds the file content; SynthQMS handles the workflow surface around it. Many customers run both together; some run SynthVault standalone for use cases that don’t need the QMS workflow.

Request a demo What SynthVault is & isn’t
What SynthVault is · Capabilities · Use cases · Integrations · Sizing · Licensing · Documentation · FAQ

The category boundary

What SynthVault is, and what it isn’t.

SynthVault is the versioned-storage substrate for regulated file content. It holds the bytes; it tracks who changed what and when; it proves nothing was tampered with. Beyond that, it deliberately doesn’t do much — the workflow surface around files lives in SynthQMS or in other systems that integrate via the webhook surface.

SynthVault IS

  • A versioned file vault
  • SHA-256 hash-chain audit
  • Integrity-verified storage
  • License-gated Part 11 mode
  • The substrate beneath SynthQMS
  • Cross-platform (Windows + Linux)
  • Standalone-licensable

SynthVault IS NOT

  • A workflow-management system (that’s SynthQMS)
  • A general-purpose collaborative DMS (that’s SharePoint)
  • A source-control system (that’s git)
  • A medical device
  • A multi-tenant SaaS (single-tenant standard)
  • A clinical document store (that’s the VNA family)

SynthVault works with all the things it isn’t. SynthQMS uses SynthVault as its storage substrate. Build pipelines pull source from git and push artifacts to SynthVault. SharePoint mirrors SynthVault content for broader collaborative reach. The VNA family stores DICOM in its own purpose-built archive that follows similar principles. Each tool, its job.

Capabilities

Versioning, audit, integrity, retention.

Eight capability areas covering the full vault surface — from the everyday checkout / checkin workflow through the hash-chain audit and integrity-sweep tooling that makes the vault defensible to regulators.

Checkout / checkin / version history

Source-control-style workflow for any file type. Lock the working state, edit, check the new version back in. Full version history retained.

  • File-locking checkout (one editor at a time per file)
  • Checkin produces a new immutable version with metadata
  • Per-file version history with diff-style comparison where applicable
  • Pre-commit / post-commit hook points for validation
  • Per-file metadata: who, when, why (required reason text)
  • Branch-style "working set" support for multi-file edit groups

Hash-chain audit log

Every checkin produces a chain entry. SHA-256 over (file content + timestamp + author + previous chain root). Tampering is detectable.

  • SHA-256 content hashing on every stored version
  • Chain entries linking each version to the previous chain root
  • Independent integrity-sweep tool re-walks the entire chain
  • Mismatch detection at any chain position
  • Audit-record export with cryptographic receipts
  • Chain-root publication for off-host tamper-evidence

Integrity sweeps

Periodic full re-verification of every stored file against its hash chain. Catches silent storage corruption and ensures the audit chain still reconciles.

  • Scheduled full-vault sweeps (configurable cadence)
  • On-demand integrity verification per file or per project
  • Mismatch quarantine with documented remediation workflow
  • Sweep-completion reports for inspections
  • Per-file integrity-state tracking (last-verified timestamp)
  • Storage-backend-agnostic (works against local FS, S3, NAS)

Webhooks

External systems get notified on every checkin. The integration surface for build pipelines, document workflows, and downstream archives.

  • Webhook subscription per project / per file pattern
  • Configurable payload (full file metadata vs minimal)
  • Retry policy with dead-letter queue
  • Webhook signing for receiver verification
  • Used by SynthQMS for document-mirror automation
  • Used by build pipelines for artifact-promotion triggers

Project + folder organization

Hierarchical organization within the vault. Per-project access control, per-folder retention policies, per-file tagging.

  • Project-level access control (project members + roles)
  • Folder hierarchy within projects
  • Per-folder retention policies (different folders, different retention windows)
  • Tag-based search across the vault
  • Project-level audit-trail filtering
  • Cross-project links for related files (e.g., MSI build references source-tree project)

Optional 21 CFR Part 11 retention mode

Part 11 mode is a license feature — not a config toggle. With the license, SynthVault enforces Part-11-friendly retention semantics: tamper-evident storage, electronic-signature support, retention-period enforcement.

  • `part11_retention_mode` license feature gates the capability
  • Without the license: RUO / generic-versioning baseline (same as the rest of the vault)
  • With the license: Part 11 §11.10 closed-system controls active, §11.50 e-signature support active, retention-window enforcement active
  • Per-folder Part 11 mode override (some folders Part-11-mode-on, others off)
  • License-feature enforcement in code (cannot be config-toggled)
  • Audit captures Part-11-mode state with every action

Backup / restore

Native backup tooling for full-vault snapshots; restore tooling for disaster recovery. Off-host backup destinations supported.

  • Full-vault backup with chain-root + content + metadata
  • Incremental backup (only changed-since-last-backup)
  • Restore-to-snapshot tooling (rolls the vault back to a previous state)
  • Cross-host restore (move the vault to a different host)
  • Backup verification (restored copy passes integrity sweep)
  • Off-host destinations: S3, NAS, tape via cron-friendly scripts

Operations & administration

Web admin UI, RBAC, observability — same family-platform shape as the rest of Synthology.

  • Web administration UI
  • Role-based access control (operator / project member / admin / auditor)
  • Real-time dashboard — checkin rate, integrity-sweep state, project sizes
  • Prometheus metrics + structured JSON logs
  • Cross-platform deployment (Windows + Linux)
  • PostgreSQL / SQL Server / Oracle catalog (no SQLite for production)

Use cases

Six deployment patterns.

From the default deployment shape (storage substrate beneath SynthQMS) through the standalone patterns where SynthVault carries the load on its own — source archives, build artifacts, regulatory submissions, legal hold, engineering specs.

Pattern 1

Storage substrate beneath SynthQMS

The default deployment shape. SynthQMS handles the QMS + CRM workflow surface; SynthVault stores the actual file content with version history + hash-chain audit. Customers running both products get the integration for free.

Flow

  1. 1 SynthQMS document-control workflow approves a new document version
  2. 2 On approval, SynthQMS checks the file into SynthVault
  3. 3 SynthVault returns a versioned URI + SHA-256 hash
  4. 4 SynthQMS stores that URI + hash in the document record
  5. 5 Any later retrieval pulls from SynthVault with integrity verification
  6. 6 Audit trail spans both products end-to-end
Pattern 2

Source-tree archive for regulated software development

Standing Synthology rule: every source file change to a Synthology product round-trips through SynthVault. Source code lives in git for working state; SynthVault holds the regulated authority for what was approved when. Customers building their own regulated software adopt the same pattern.

Flow

  1. 1 Developer makes a source-tree change
  2. 2 Pre-commit: source file checked out of SynthVault
  3. 3 Edit + test in the working environment
  4. 4 Post-edit: file checked back into SynthVault with reason text
  5. 5 Hash-chain entry written; webhook fires for build-pipeline automation
  6. 6 Build pipeline pulls the approved version of the source for the build
Pattern 3

Build artifact archive (MSI, tarball, .sha256)

Every build artifact (MSI installer, Linux tarball, container image, signed binary) checks into SynthVault with its hash. Year-later questions about "what was in version X.Y.Z" answer themselves — vault has the artifact + its provenance.

Flow

  1. 1 Build pipeline produces an artifact (MSI / tarball / etc.)
  2. 2 Artifact + .sha256 checksum file checked into SynthVault
  3. 3 SynthVault stores both with chain-entry linkage
  4. 4 Released-Versions catalog references the SynthVault URI
  5. 5 Inspections / audits / customer escalations pull the exact build artifact from the vault
  6. 6 Tombstone semantics for retired versions (kept in vault, marked superseded in catalog)
Pattern 4

Regulatory submission package vault

Regulatory submission packages contain dozens of controlled documents. SynthVault holds the canonical version of every document referenced in the submission, with hash-chain proof of what was sent on what date.

Flow

  1. 1 Submission package authoring in SynthQMS (or directly in SynthVault for non-SynthQMS users)
  2. 2 Each component document checked into SynthVault as it's finalized
  3. 3 Final submission "snapshot" assembled from versioned vault references
  4. 4 Hash chain proves what was submitted at submission time
  5. 5 Subsequent communication with FDA references vault URIs
  6. 6 Post-submission retention managed per Part 11 mode (if licensed)
Pattern 5

Legal hold + e-discovery archive

A litigation hold or regulatory-inquiry hold demands extraction of all materials related to a specific topic / patient / product. SynthVault's tagging and audit-trail surfaces let counsel produce a defensible record without scrambling.

Flow

  1. 1 Legal hold scope defined (specific patient ID / product version / date range)
  2. 2 SynthVault search across project folders and tags
  3. 3 Matching files exported with their full audit history
  4. 4 Hash-chain receipts produced for every exported file
  5. 5 Bundle handed to counsel with cryptographic provenance
  6. 6 Vault retains the originals; the export is a documented copy
Pattern 6

Engineering specification repository

Engineering specs, design history files, risk-management files, threat models — the regulated-design-control artifacts that need to live somewhere with version + audit. SynthVault is the right place for them when you don't want to put them in source-control or in a generic DMS.

Flow

  1. 1 Engineering team authors a spec / DHF / RMF / threat-model document
  2. 2 Document checked into SynthVault's engineering-specs project
  3. 3 Per-document approval workflow (if integrated with SynthQMS) or direct vault commit
  4. 4 Subsequent revisions go through checkout / checkin with reason text
  5. 5 Audit trail provides the design-control history regulators want to see
  6. 6 Part 11 mode (if licensed) provides the closed-system controls Part 11 demands

Integration points

Writers, readers, storage, identity.

Inbound (writers / consumers)

  • SynthQMS document-control workflow (the most common writer)
  • Build pipelines (CI/CD systems checking in artifacts)
  • Source-control workflows (developer commits round-tripped per the standing rule)
  • Manual web-UI uploads (engineers authoring docs directly)
  • Migration scripts (bulk-loading existing document archives)
  • Webhook-driven external systems

Outbound (readers + downstream)

  • SynthQMS document retrieval (with integrity verification)
  • Build pipelines pulling source for builds
  • Customer-facing document access (with appropriate RBAC)
  • Inspection / audit retrieval workflows
  • E-discovery / legal-hold export workflows
  • Webhook subscribers (downstream archives, build automation, document-mirror systems)

Storage backends

  • Local filesystem (default)
  • S3-compatible object stores (AWS S3, MinIO, Wasabi, Backblaze B2, Cloudflare R2)
  • On-prem NAS (NFS / SMB)
  • Per-project storage-backend assignment (different projects, different backends)
  • Configurable encryption-at-rest per backend

Catalog database

  • PostgreSQL (recommended default)
  • Microsoft SQL Server
  • Oracle Database
  • No SQLite for production deployments
  • HA replication / clustering supported per DB

Identity, audit, observability

  • OIDC / SAML for the web admin UI
  • Active Directory / Azure AD federation
  • Per-action audit trail entries
  • Hash-chain audit log
  • Integrity-sweep results visible on the dashboard
  • Prometheus metrics + structured JSON logs
  • Webhook outputs for SIEM integration

System requirements & sizing

Sized to file count + total storage.

The catalog database scales with file count; the storage backend scales with total content volume. Most deployments pair a modest catalog DB with an S3 or NAS storage tier for the bulk content.

Tier Scale CPU RAM Storage Typical org
Small (single team) < 10,000 files · < 100 GB 2 vCPU 4 GB 500 GB working Single-team document vault, regulated software development at small scale.
Mid-sized organization 10,000 – 1M files · 100 GB – 5 TB 4 vCPU 16 GB 10 TB working + S3 cold tier Mid-sized med-device company with active document-control workflow, build-artifact archive, source archive.
Large organization 1M+ files · 5 – 50 TB 8 vCPU (HA pair) 32 GB per node 50+ TB tiered Enterprise med-device organization with extensive controlled-document set, multi-product engineering teams, regulated software at scale.

Licensing

Three packages, Part 11 license-gated.

Core covers the everyday vault surface (versioning, hash- chain, integrity, webhooks, backup) for RUO / generic- versioning use. The Part 11 Mode tier unlocks the regulatory-grade retention controls. Enterprise adds pluggable storage backends, multi-database catalog support, and HA pairing.

SynthVault Core

The base vault — checkout / checkin, hash-chain audit, integrity sweeps, project organization, webhooks, backup. RUO / generic-versioning baseline.

  • Checkout / checkin workflow
  • Hash-chain audit log
  • Integrity sweeps
  • Project + folder organization
  • Webhooks
  • Backup / restore
  • Web admin UI + RBAC
  • PostgreSQL catalog
  • Up to 100 GB vault size

SynthVault + Part 11 Mode

Adds the license-gated 21 CFR Part 11 retention mode for regulated-document storage with closed-system controls and electronic-signature support.

  • Everything in Core
  • `part11_retention_mode` license feature activated
  • 21 CFR Part 11 §11.10 closed-system controls active
  • 21 CFR Part 11 §11.50 electronic-signature support
  • Retention-window enforcement per folder
  • Per-folder Part 11 mode override
  • License-feature enforcement in code (not config)
  • Up to 10 TB vault size

SynthVault Enterprise

Everything, plus pluggable storage backends, multi-database catalog, multi-host deployment, and HA pairing.

  • Everything in Core + Part 11 Mode
  • S3 / NAS / object-store backends
  • PostgreSQL / SQL Server / Oracle catalog
  • Multi-host distributed deployment
  • Active-active HA pair
  • Cross-project federation across multiple vault instances
  • Unlimited vault size
  • Premium support tier eligible

Per-deployment licensing. Multi-product bundles (SynthVault + SynthQMS + XyDromatics products) get bundle pricing.

Documentation

The controlled-document set.

Document Title Notes
Pending Hardware & Software Requirements (SynthVault) Sizing, OS support, dependencies
Pending Hash-Chain Audit Specification How chain entries are computed and verified
Pending Integrity-Sweep Specification Sweep cadence, mismatch handling, remediation workflow
Pending Part 11 Mode License-Feature Spec Implementation of the strict feature-license check + closed-system controls
Pending EULA Annex (SynthVault) Annex to the Synthology Master EULA (DOC-2026-063)
Pending Penetration Test Results (SynthVault) Available under NDA
Pending User Guide (SynthVault) Operator + administrator + auditor workflows
Pending Installation Guide (SynthVault) MSI deploy + Linux tarball + database setup

Rows listed as Pending are not yet authored or registered in SynthQMS. (When they are, they’ll be stored in SynthVault — turtles all the way down.)

Frequently asked

The questions buyers ask.

How is SynthVault different from SynthQMS?

Different roles. SynthVault is the versioned-storage substrate -- it holds the actual file content with version history, hash-chain audit, integrity verification. SynthQMS is the QMS + CRM control plane that runs on top -- it handles the workflow (document approval, training records, CAPAs, etc.) and uses SynthVault as its storage layer. Many customers run both together; some run SynthVault standalone for use cases that don't need the QMS workflow surface (build-artifact archive, source-tree vault, engineering-spec repository, legal-hold archive).

How is SynthVault different from git?

Different scope. Git is for source code -- text-friendly, merge-friendly, designed for collaborative development. SynthVault is for any file type -- binary artifacts, documents, images, build outputs -- where the regulated authority of "what was approved when" matters more than merge collaboration. Synthology's own pattern: source code lives in git for working state; SynthVault holds the regulated authority for what was approved into a release. Both run; both are useful; they answer different questions.

How is SynthVault different from SharePoint?

SharePoint is a general-purpose document-collaboration platform with rich editing, sharing, search, and the broad Microsoft 365 integration. SynthVault is narrower and more rigorous: hash-chain audit, integrity sweeps, file-locking checkout, license-gated Part 11 mode. They're complementary -- SynthQMS uses SharePoint as a document mirror for off-host redundancy, and SynthVault as the authoritative versioned storage. For regulated artifacts where audit defensibility matters more than collaboration breadth, SynthVault. For general-purpose collaboration, SharePoint.

Why is Part 11 mode license-gated rather than always on?

Same reason as IPE's HIPAA mode -- a regulated capability should not be reachable through a config flag. License-feature enforcement in code keeps the Part 11 boundary at the regulatory level rather than at the customer-modifiable-config level. Without the license, SynthVault runs in a capable RUO / generic-versioning baseline. With the license, the closed-system controls and electronic-signature support activate and audit-record the Part 11 mode state on every action. Customers who don't need Part 11 don't pay for capabilities they're not using; customers who do need Part 11 get the license-enforced regulatory boundary.

How does the hash-chain audit actually work?

Each checkin produces a chain entry with SHA-256 over (file content + timestamp + author identity + previous chain root + reason text). The chain root is the latest entry's hash; subsequent entries chain to it. Tampering with any earlier entry breaks the chain at that point and is detectable by the integrity-sweep tool. The chain root is publishable for off-host tamper-evidence -- print it, store it elsewhere, commit it to a git repo, etch it on a stone tablet -- and compare against the vault later to prove no rewrite happened.

Can SynthVault be deployed without SynthQMS?

Yes. SynthVault is fully standalone-licensable. Common standalone uses: build-artifact archive for regulated software companies, source-tree vault for regulated engineering teams, regulatory-submission-package vault, legal-hold / e-discovery archive, engineering-specification repository. SynthQMS is a great companion when you need the QMS workflow surface, but the vault stands on its own.

What about Microsoft Sentinel / Splunk / SIEM integration?

Webhook outputs forward audit events to any HTTP-receiving SIEM. Structured JSON log output works against Splunk, Sentinel, Datadog, or any log-collection platform. Prometheus metrics endpoint exposes operational state for monitoring. SynthVault doesn't aim to be its own observability platform -- it forwards what observability platforms want.

Cross-platform support?

Yes -- Windows and Linux. MSI installer for Windows, self-contained Linux tarball for Linux. Same parity as SynthQMS and most of the XyDromatics product family. HA pairs can mix OS platforms.

What's the largest file SynthVault handles?

Practical limits depend on the storage backend. Local filesystem and S3 both handle multi-gigabyte files cleanly; the catalog has no hard cap. Tested in production against WSI files (50 GB-500 GB each) when integrated with the XyDromatics Pathology Engine, and against multi-gigabyte MSI installers. Very-large-file workflows benefit from S3 multipart upload support and chunked retrieval.

Where does your regulated file storage live?

Source-tree archive, build-artifact archive, regulatory submissions, legal-hold archive, engineering specs. Tell us what you need to defensibly version + audit and we’ll come back within one business day with a proposed deployment.

Request a demo All products