Architecture Overview
BYOVault is made up of a handful of independently deployed components, each with a distinct job. This page describes what each one is for, not how it is built internally.
The API service
BYOVault’s API service is the single front door for everything else in the system. Every other component either calls the API service or is called by it — the operator dashboard, the self-service portal, and the file-server agent all talk to it directly over HTTPS.
The API service handles:
- Authentication for both BYOVault operators and end users
- Tenant and storage configuration
- The Microsoft 365 admin-consent OAuth flow
- Restore requests
- Retention vault provisioning
- BYOK setup
The API service does not execute backups or restores itself. It is responsible for starting jobs, sending pause/cancel requests to running ones, and scheduling tenants’ backup jobs on their configured cadence.
All real execution — every file read, every upload, every encryption operation — happens in a dedicated backup worker, described below.
The backup worker
The backup worker does the actual work of a backup or restore: authenticating to Microsoft Graph, enumerating drives and mailboxes, downloading content, encrypting it, and writing it to the tenant’s own Azure Blob container or S3 bucket.
It also runs the recurring maintenance jobs that keep a tenant healthy:
- Connection-health checks
- Retention-vault archiving
- Vault integrity checks
- Encryption-key health checks
- The notification digests described in Notifications & Alerts
The backup worker never decides when to run — that comes from the API service, either on a schedule or in response to an operator action.
A durable orchestration layer sits underneath both components. It ensures that a backup already in progress keeps running, and survives a restart of any part of the system by resuming from where it left off rather than starting over.
The operator dashboard
The operator dashboard is where BYOVault operators sign in to connect Microsoft 365 tenants, attach storage accounts, configure backup schedules, monitor job status, and perform restores.
It is the operator-facing surface: any tenant, any workload, immediate execution, no approval step. This is distinct from the self-service portal below, which is scoped to individual end users.
The self-service portal
The self-service portal is a separate application from the operator dashboard, not a section within it. It is where an end user — not a BYOVault operator — signs in to browse and request restoration of their own Exchange mail or OneDrive files.
Requests are not executed immediately: a designated Restore Files Approver reviews and approves each one first. A tenant with no approver configured cannot use self-service restore at all.
See Self-Service Portal for the full request lifecycle.
The file-server agent
The file-server agent is a native Windows Service (installed via the standard installer) that customers run on their own on-premises machines to back up local or network file shares.
It never accepts inbound connections. Instead, it enrolls once against BYOVault, then repeatedly polls BYOVault over outbound HTTPS for pending backup or restore jobs, uploading file content in the same request cycle.
Encryption happens on BYOVault’s side, not on the agent. The agent sends file content over TLS, and BYOVault encrypts it with the same AES-256-GCM scheme used for Microsoft 365 content before writing it to the tenant’s storage account.
The agent also checks in for self-updates and reports job completion back to BYOVault.
How a backup actually flows
For Microsoft 365 workloads: a scheduled backup starts automatically, and the backup worker authenticates to Graph, enumerates the relevant drives or mailboxes, and streams content into the tenant’s own storage account.
For file servers: the agent polls BYOVault for a job, uploads the file content it finds locally, and BYOVault’s own pipeline takes over encryption and storage from there.
See How BYOVault Works for the full step-by-step version of this flow.