Security

Build Infrastructure

Our build infrastructure has been architected with security as a primary consideration, implementing best practices to protect customer code, sensitive credentials and signing certificates. This section explains the security features of our build pipeline.

Secure Authentication & Configuration

The build process begins when our CLI authenticates with the ToDesktop API using your unique API key. After authentication, your app's configuration is retrieved from our database and from the local todesktop.json file.

Secure File Management

Your application files are handled through a secure upload process:

1. The CLI requests pre-signed URLs from our API, which are temporary, scoped access tokens to our Amazon S3 storage.
2. After verification of upload permissions, your files are transferred to S3.
3. File integrity is maintained by calculating and storing checksums, ensuring the files used in the build process are identical to those you uploaded.

Encryption in Transit and at Rest

We encrypt customer data both in transit and at rest:

• The web app, API, and artifact uploads/downloads use HTTPS/TLS (TLS 1.2+; TLS 1.3 where supported)
• Connectivity to managed services (including Firestore) uses TLS
• Firestore data is encrypted at rest using provider-managed AES-256 encryption
• Object storage (Cloudflare R2 and Amazon S3) is encrypted at rest by the provider

Ephemeral Credentials with Principle of Least Privilege (PoLP)

One of our key security features is the creation of ephemeral credentials:

• Temporary credentials are generated with a short 2-hour time-to-live (TTL)
• Access is strictly limited to only the specific resources needed for your build
• Each build receives unique credentials, preventing any potential credential reuse
• Credentials are automatically destroyed after build completion

This approach ensures that even in the unlikely event of a security breach, the potential impact is minimized through strict isolation and time constraints.

KeyVault Gatekeeper Architecture

While our ephemeral credentials already provides security through isolation, we maintain an additional layer of protection through our KeyVault Gatekeeper:

• The Gatekeeper acts as a secure sidecar that mediates all access to Azure KeyVault
• Communication between the build process and Gatekeeper occurs over localhost HTTPS

Secure Code Signing & Notarization

For distributing trusted applications:

• Code signing certificates for both Windows and macOS are securely managed in Azure KeyVault
• The signing and notarization process is handled by the KeyVault Gatekeeper
• The process follows platform-specific requirements for creating properly signed and notarized applications

Integrity Verification

Throughout the build process, we verify file integrity:

• Checksums created during upload are compared with files retrieved from storage
• This verification ensures that the exact files you uploaded are used in the build process
• Any integrity mismatch would trigger a build failure

Fault Tolerance

Our build system is designed for reliability:

• Builds that encounter errors are automatically retried once
• Error reporting is provided if builds ultimately fail
• The build status is continuously communicated back to you through the CLI and web UI

Build Distribution

After successful builds:

• Artifacts are securely stored and made available through our CDN
• Cloudflare Workers with R2 storage are used for primary distribution
• Distribution artifacts are mirrored to Amazon S3 (eu-west-1) as a backup target

Backup, Recovery, and Disaster Resilience

Our backup and recovery strategy focuses on fast recovery for distribution artifacts and reliable database backups:

• Firestore production backups run daily using scheduled backups
• Firestore backup retention is 42 days
• Artifact storage objective: RPO near-zero (mirrored), RTO minutes
• Database objective: RPO up to 24 hours (daily backups), RTO typically 2-3 minutes to restore

Resilience & Disaster Recovery

Our platform is designed with redundant storage and documented recovery objectives.

Storage Redundancy

• Distribution artifacts are primarily served from Cloudflare Workers with R2 storage.
• Distribution artifacts are mirrored to Amazon S3 (eu-west-1) as a backup target.
• We can fail over artifact delivery to backup storage in minutes when needed.

Backups and Retention

• Our production Firestore database is backed up daily using Firestore scheduled backups.
• Database backups are retained for 42 days.

Recovery Objectives

• Artifacts: RPO near-zero (mirrored), RTO minutes.
• Database: RPO up to 24 hours (daily backups), RTO typically 2-3 minutes to restore.

Last Reviewed

• February 5, 2026.

Release Process

Our release process is designed with multiple security layers to ensure that only authorized individuals can publish updates to your applications. This section explains the security features of our release pipeline.

Security Key Authentication

The most critical security feature of our release process is the requirement for user verification via security keys:

• All release actions require WebAuthn authentication with user verification turned on (i.e. a physical security key or biometric or pin is required)
• This verification is managed through a dedicated security token service
• The authentication system operates independently from our main infrastructure
• Even if other systems are compromised, releases remain protected
• We recommend using a physical security key like a YubiKey

Least-Privilege Permission Controls

We implement strict permission-based access controls:

• Account administrators can assign specific release permissions to team members
• Team members can be granted build-only access without release capabilities
• Sensitive actions require WebAuthn user verification, including releases
• An audit trail records release attempts and other sensitive account actions

Partial Release Capability

To enhance security and reliability:

• Releases can be configured as full or partial rollouts
• Partial releases limit distribution to a subset of users
• This allows for controlled testing before wider deployment

Secure Distribution Architecture

Released builds are distributed through:

• Cloudflare Workers with R2 storage providing edge distribution
• Automatic cache invalidation to ensure immediate availability of updates
• In the case of an R2 outage, we can fall back to a backup storage system using Amazon S3

Self-hosted Distribution Infrastructure

Principles

• Follows the previous TD release process but allows you to have control over the infrastructure that has direct access to your end-users.
• ToDesktop has no access to the buckets and workers that serve your application releases and updates.
• The only interaction ToDesktop has is firing a webhook to your release-relay, which you fully control.
• The build is not released to your customers until you verify the release details and merge the corresponding PR into the main branch.
• You can enable branch protection rules in GitHub to require at least one/two specific reviewers (e.g., security lead or dev lead) to approve PRs before merging.

For the latest security details and implementation instructions, see the self-hosted README on GitHub.

View our published security advisories for ToDesktop Builder and ToDesktop for Electron (CLI) at our Security Advisories page.

For the latest details, see our Security Policy page.

Third-party Audits

We have engaged third-party auditors to review our build process and infrastructure. We will complete at least one audit per year to ensure our security measures are up to date.

The following audits have been completed:

• Completed on 25^th February 2025: Security Audit conducted by Doyensec. [View attestation report].