Secure, Versioned File Sharing Purpose-Built for Music Production
Music producers and audio engineers working in teams face a unique set of collaboration challenges that generic cloud storage tools were never designed to solve:
DAWShare was built from the ground up to address these problems with a system that understands the specific structure and workflow of DAW projects.
DAWShare is a self-hosted file sharing and version control platform designed specifically for music production teams. It provides:
| Capability | Description |
|---|---|
| Version Control | Every push creates an immutable version. Full history is preserved and any version can be restored. |
| Delta Sync | Only changed bytes transfer over the wire. A 2 GB project with a few tweaked audio files syncs in seconds. |
| Background Sync | Push operations run in the background after user confirmation; macOS® delivers a success or failure notification on completion. |
| File-Level Deduplication | Identical files (samples, loops, stems) are stored once across all versions and projects in a collab. |
| Check-out / Check-in | A user can lock a project while editing, preventing others from pushing conflicting changes. |
| End-to-End Encryption | Files are encrypted on the client with the per-collab symmetric secret before upload. The server stores ciphertext only and never holds the keys needed to decrypt. |
| Audit Logging | Every push, pull, version commit, and administrative action is recorded with timestamps and user attribution. |
| Automatic Backups | Before each pull overwrites local files, changed files are backed up to a timestamped folder. |
| Server-Side Mapping Recovery | Folder-to-project mappings are stored server-side and automatically recovered on new machines or data loss. |
| Smart Folder Setup | On first sync, the app offers to auto-create a local folder pre-named after the project, defaulting to the Logic Folder with the option to choose any location. |
| Moved Folder Detection | If a project folder has been moved or renamed, the app automatically locates it by scanning common music directories and sibling folders. |
| Restore Last Project | When the app launches, the browser reopens directly to the last project the user was working on. |
| Project Cover Art | Users can upload cover artwork (JPEG, PNG, GIF, WebP, SVG) for each project, displayed throughout the web UI. |
| Version Notes | Each push can include free-text session notes for context and searchability. |
| Project Finalization | Projects can be marked as final to prevent further changes. Finalization optionally records library placement metadata (library name, album, and streaming URL). |
Three independent FastAPI application nodes sit behind a Cloudflare® load balancer with automatic failover. The PostgreSQL® cluster runs four nodes managed by repmgr — one primary, three replicas, with automatic promotion on primary loss. Encrypted blobs are stored in Backblaze® B2 with Object Lock (governance, 30-day) protecting recent uploads from deletion or tampering. Database dumps are encrypted with rclone crypt and synced off-cluster to B2 nightly.
.app bundle. AppleScript® URL handler dispatches :// actions to a bash sync engine that calls a Go binary (dawshare-crypto) for all cryptographic operations. No Python dependency.:// URL handler, calling the same dawshare-crypto.exe Go binary. No Python dependency.:// URL scheme.The desktop app chunks every file to 4 MB, encrypts each chunk client-side with XChaCha20-Poly1305 using the collab's symmetric secret, and uploads only chunks the server doesn't already have (content-addressed by SHA-256 hash). The server stores chunks as opaque ciphertext blobs and a per-version manifest that maps file paths to chunk hash sequences. Pulling a version reverses the process: fetch missing chunks, decrypt locally, reassemble files.
Because chunks are content-addressed, renaming a 500 MB sample uploads zero bytes — the chunks already exist server-side under the same hash. Saving a tweaked version of a 1 GB project uploads only the chunks that actually changed.
Users are organized into Collabs (collaborative groups). Each collab has its own symmetric encryption secret, generated on the creator's device and shared to new members via end-to-end encrypted invite links. The server never sees the unwrapped collab secret. Removing a member ends their access at the API level; previously-pulled chunks they hold are revoked only by the owner rotating the collab secret.
We take security seriously because we know you take your music seriously. While balancing ease of use and flexibility, we also made sure that your music stays locked up and accessible only to you and your collaborators.
The Master Key never leaves the user's device. Authentication uses a two-round HKDF-derived hash so that the server can verify identity without ever holding a credential that decrypts files:
salt from the server.auth_hash = HKDF(master_key, salt, info="auth") and wrapping_key = HKDF(master_key, salt, info="wrap") locally.{username, auth_hash} to /v2/auth/session. The server compares auth_hash against its stored value (bcrypt-hashed at rest) and, on match, issues a short-lived Bearer token.wrapping_key never leaves the device. The server returns each collab's wrapped symmetric secret with the session response; the client unwraps each one locally with the wrapping_key and holds the plaintext collab secrets in process memory only.Even with a full server compromise, an attacker obtains the bcrypt-hashed auth_hash values (not the Master Keys) and the wrapped collab secrets (not the unwrapped ones). No combination of server-side data permits decrypting a single uploaded chunk.
All client–server traffic is HTTPS over TLS 1.2/1.3, terminated at Cloudflare® and re-established to the origin using a Cloudflare® Origin Certificate (zone is set to Full Strict). There is no longer any SSH tunnel, rsync wrapper, or force-command layer — eliminating that attack surface entirely. Bearer tokens are bound to a session row, expire automatically, and can be refreshed during long uploads without re-presenting credentials.
Each device the user installs the app on reports a stable hardware-derived identifier (macOS® IOPlatformUUID, Windows® Win32_ComputerSystemProduct.UUID) along with hostname, OS version, and architecture to /v2/device-checkin. The server records each device against the user's account so:
sync_sessions row carries the originating device_id for full audit attribution — the version history shows not just who pushed but from which device.DAWShare 2 uses two distinct credentials so that compromising one cannot expose what the other protects:
auth_hash (for login) and a wrapping_key (for unwrapping each collab's encryption secret). Lose it without a backup or another active device, and we cannot recover it — that is the cost of true end-to-end encryption.It is incredibly simple to register your web account with a free authenticator app like Microsoft® or Google® Authenticator. This helps to lock down your web account so only you have access. Whenever you login through the web you just enter the authenticator code on your phone and we know that it is you.
DAWShare 2 encrypts every file on your device before it reaches our servers. The server stores ciphertext and never holds the keys needed to decrypt it. Even a full server breach — or a subpoena, or a rogue insider — cannot expose your audio or session data.
auth_hash — the Master Key itself never leaves the user's deviceFiles are encrypted client-side with the collab's symmetric secret before any bytes leave the device. The server stores ciphertext and verification hashes only — it cannot inspect file contents. Server-side antivirus scanning would therefore yield no information and is deliberately not performed.
Malware protection is delegated to the endpoints that decrypt and open files: each collaborator's OS-level antivirus scans decrypted files when they land in the local sync folder, the same way it would scan any other download. This places the trust boundary at the endpoint where the file actually executes, not at a server that cannot read what it stores.
Every action is logged: pushes, pulls, version commits, project creation/deletion, check-outs, collab management, and user authentication events. Logs include user identity, timestamp, IP address, and action-specific details. Admins can view grouped audit logs filtered by collab, project, or user.
DAW projects are highly redundant. A typical Logic Pro® project shares most of its audio files between versions — a 90-second vocal take doesn't change when the mix engineer adjusts EQ settings. DAWShare exploits this with file-level content-addressable deduplication:
Storage quotas are enforced per-project (default 1 GB) and per-collab (default 10 GB), measured by actual bytes stored after deduplication.
The sync protocol is designed to minimize data transfer for large projects where only a few files change between versions:
/sync/session)rsync from the local project folder to the staging directory — only changed bytes transfer/sync/session/{id}/complete)rsync from the staging directory to the local folder with --backup to preserve overwritten filesEach sync session generates a time-limited token (default 15 minutes) that authorizes the rsync SSH connection. An SSH force-command wrapper on the server validates the token and restricts rsync to the session's staging directory, preventing unauthorized file access.
DAWShare stores folder-to-project mappings both locally and on the server. If the local configuration is lost (new machine, reinstall, accidental deletion), the system recovers automatically:
local_id (UUID) stored in a .dawshare marker filelocal_id and folder path to the serverlocal_id to folder pathIf the local project folder has been moved or renamed, the app automatically locates it before syncing rather than reporting an error. The search checks sibling directories of the last known path, as well as common music directories (~/Music/Logic, ~/Documents, ~/Desktop, ~/Music). When found, the user is shown a confirmation dialog before proceeding. The corrected path is then saved back to the server so subsequent syncs resolve correctly.
When a user syncs a project for the first time and no local folder exists, the app offers to create one automatically. A dialog pre-fills the folder name with the project name (editable), and offers two placement options: the user's Logic Folder (default) or a custom location chosen via the native folder picker. The folder picker includes a New Folder button so the user can create subdirectories without leaving the dialog.
When the desktop app launches and opens a browser window, it automatically navigates to the last project the user was viewing rather than the projects list. The last-visited project path is stored in localStorage and threaded through the auto-login URL so the redirect happens silently on every launch.
Before a pull overwrites local files, DAWShare automatically backs up changed files to a timestamped folder. Users can browse these backups directly from the project page in the web UI. Backups can be disabled per-user in profile settings.
Each project can have a custom cover image uploaded via the web UI. Raster images (JPEG, PNG, GIF, WebP) are automatically resized and optimized for display. SVG files are stored as-is and rendered natively in the browser. Cover art is displayed on the project detail page, the projects list, and anywhere the project is referenced in the UI.
When pushing a new version, users can optionally add free-text session notes describing what changed. Notes are displayed alongside each version in the version history table and are searchable and filterable, making it easy to locate a specific session across a long history.
Each project stores rich metadata editable from the web UI: musical key, BPM, DAW type, genre (with sub-genre), mood, and instrumentation tags. This metadata supports organization across large collabs and aids in locating projects by musical or technical criteria.
Projects can be marked as final, locking them against further version uploads. Finalization is an intentional milestone action and optionally captures library placement metadata:
The web UI provides autocomplete suggestions for library names and album names drawn from the user's placement history across all projects. Selecting a known library automatically populates the associated album dropdown and pre-fills the URL. Library metadata can be updated at any time after finalization without reopening the project. Finalized projects display a dedicated banner with a direct link to the placement.
The server exposes a public GET /client-version endpoint that returns the current installer version, release date, and download URL. The desktop app checks this endpoint once per day and displays an in-app update dialog when a newer version is available. The web UI shows a dismissible top banner for the same purpose. Users can dismiss the banner per-version for up to 7 days.
| Platform | Status | Components |
|---|---|---|
| Web (any browser) | Available | Dashboard: project management, version history, member management, audio preview, audit logs, admin panel. File transfer requires the desktop app. |
| macOS® | Available | Signed and notarized native .app bundle. AppleScript URL handler + bash sync engine + dawshare-crypto (Go binary). End-to-end encrypted chunk uploads over HTTPS. |
| Windows® | Available | PowerShell sync script with registry-based :// URL handler + dawshare-crypto.exe (Go binary). Same E2EE sync protocol as macOS. |
DAWShare is DAW-agnostic. It works with any software that stores projects as files or folders, including Logic Pro®, Ableton Live®, Pro Tools®, FL Studio®, Cubase®, Studio One®, REAPER®, GarageBand®, Reason, and Bitwig Studio®. It can also sync standalone audio folders (stems, bounces, multitracks).
The macOS® installer handles the complete setup process without requiring a web browser:
UseKeychain yes, and AddKeysToAgent yesdawshare:// URL scheme registeredA monitoring script runs on a configurable schedule (default: every 5 minutes) and checks system health:
Alerts are delivered via desktop notifications, server-side alert API, and direct SMTP email fallback if the server is unreachable. A 30-minute cooldown prevents alert flooding.
Automated database backups follow a Grandfather-Father-Son (GFS) rotation strategy:
Backups are created via pg_dump and stored on the NFS mount. A pre-flight check verifies the mount is available before proceeding, and rotation only runs after a successful dump.
Users can configure per-event email notification preferences from their Profile page:
Push sync operations fork to a background process immediately after the user confirms. The browser tab can be closed and work can continue while the sync completes. On macOS®, a system notification is delivered on success (Glass sound) or failure (Basso sound), with a direct link to the sync result. A real-time progress page is available for users who wish to monitor the operation.