Privacy notice

MixReady is early-access software: accounts are created by invitation, or by approval from the waitlist. This page is written the way the product is built: plainly, listing what is actually stored and what actually happens to it. Effective 30 September 2026 — what changed from the previous version. Questions and requests: support@mixready.art.

In one screen

• Your audio files never leave your computer. The server receives track metadata and numbers measured from your files, never the files and never where they sit on your disk.
• Your set request reaches OpenAI anonymously. It gets only what building the set needs — the words you typed and the tracks involved — and never your name, email or account.
• When something breaks, the app tells us. Crash reports go to Sentry with your account id (not your email). The desktop app also streams its own log lines to our log store, redacted on your machine before they leave, and files a report when an operation fails. The desktop crash-report switch is in Settings → Privacy & data.
• Nothing you build is public unless you share it. A shared set’s page shows its tracklist — your own files by the titles in their tags, unless you mask them — your description and, unless you hide it, your name and picture: below.
• Your data lives on our servers in the European Union, backed up nightly, encrypted before it leaves them.
• No advertising, no selling of data, no tracking inside the app. The marketing site counts visits with Google Analytics only if you allow it.
• Export and deletion are self-serve, in Settings → Privacy & data.

Who is responsible

MixReady is run by its operator reachable at support@mixready.art.

What MixReady stores about you

• Your account — email address, when the account was created, whether the address has been confirmed, and when and by which door you last signed in (password, emailed link, Google, Apple, SoundCloud, DJ ID or the desktop app). If you set a password, a salted hash of it (PBKDF2-SHA256), never the password. A username and a display name you choose, and an optional profile picture — one you upload, or the address of the picture your sign-in provider shows. The operator can attach a note to an account (a block and its reason, a feature switched on for you); those are stored with it too.
• Sign-in identities — if you sign in with Google, Apple, SoundCloud or DJ ID, the opaque account id that provider issues for you, the email it reports, and when it was linked. Never your password for that provider, which MixReady is not given.
• Provider connections — if you connect Beatport, SoundCloud, TIDAL, Apple Music or Mixcloud, the tokens for your own accounts there, encrypted at rest, plus a small health record (connected or not, last check, which account). A server timer refreshes those tokens and checks the connections on your behalf. Disconnecting destroys the tokens.
• Your sets and choices — the requests you type, the sets MixReady builds, your edits, swaps, ratings, stars, blacklist entries, collections, where each set was sent, and your preferences (including the genres you said you play and your gear profile).
• Your library scan, if you run one — for each track in your rekordbox, Serato, Traktor, VirtualDJ or djay library: title, artists, BPM, key, length, genre, label, mix name, your star rating and play count; your DJ software’s own analysis of it (phrases, mix points, beat grid and a downsampled waveform, capped at 64 KB per track); and the features MixReady measures on your machine (energy, a vocal score, intro and outro length). Each installation carries a random device id so two computers stay two libraries; it is not a hardware identifier. The scan also tells the server which tracks it saw, which files are missing and which are duplicates — by id, never by path. What stays on your computer: the audio files, their paths, full-resolution waveforms, the index that maps tracks to files, and everything in your _Serato_ folder.
• Play history, only if you opt in — reading your rekordbox or Serato play history is off by default. Switched on, each session (start, end, length, which app) and each load (which track, in what position, at what BPM and key, with what gap) is stored on your account, and a preview shows exactly what would go before you agree. Your own history is yours alone; the pooled “crowd” statistics built from everyone who opted in carry no per-person key.
• Captured tracklists — sets you save from 1001tracklists with the extension or the bookmark live on your account and stay there. They are not pooled into the community corpus, are not visible to any other DJ, and are read only by your own builds. A switch that could share their play order existed until 9 September 2026; it was removed, and everything shared under it was withdrawn from the corpus at the same time.
• Feedback and reports — what you type into the Tell us button, up to four attachments (images, PDF or text, 10 MB each), the page you were on, the set that was open, the app and shell versions, your browser and platform, and the id of the last crash report your session sent. Your email is attached on the server so the operator can answer you; you never type it. The app also files a report by itself when a named operation fails — a library upload, an export to your DJ software, a build — carrying the route, the error, versions and facts about the machine (operating system, CPU model, core count, memory, screen size, browser). Not for a lapsed sign-in or a missing page, and at most five per page load. Both kinds land in our own inbox on our own server.
• The waitlist — if you use Save me a seat on the landing page, or try to sign in before your address is admitted: your email, the level you picked (bedroom, gigging, resident, touring), the date and how you asked, and a status (new, invited, declined, registered). It is used to decide and announce admission and for nothing else. A refused sign-in the waitlist cannot hold — one that shared no address, only an Apple relay address, or an address the provider did not confirm — is kept separately (address or handle, provider, reason, time) so the operator can approve it; that list is capped at 2,000 rows.
• Usage counters — per account, how many sets were built, explained, exported and to which destinations, how many captures, files and reports, and when you were last active, so the operator can see what the alpha is used for. Counts, never contents.
• Operational logs and metrics — the server records which route was called, its status and how long it took, under a request id rather than your IP address; an operational line can name an account id. Your IP address is used to rate-limit requests over a five-minute window and is not written to your record. Cloudflare, which fronts the service, sees every request under its own policy.

What it deliberately does not do

Inside the app: no analytics, no tracking pixels, no advertising, and nothing is ever sold or shared for marketing. Your sign-in is a token kept in your browser’s local storage (in the desktop app, in your operating system’s keychain), not a cookie. The server sets exactly two cookies, both unreadable by scripts: one that binds a Google, Apple, SoundCloud or DJ ID sign-in to the browser that started it, deleted when the sign-in completes, and one that only the operator receives during a maintenance window.

Four exceptions worth naming rather than burying. Errors are reported to Sentry and, from the desktop app, log lines are streamed to our log store — below, in full. The app loads its typefaces from Google Fonts, so opening it fetches those font files from Google — no cookie is set and nothing about you is measured, but like any web request it arrives carrying your IP address. The marketing site, unlike the app, counts visits: site analytics, below. And the landing page and every shared set’s page embed Apple’s and SoundCloud’s own music players, which they serve and can measure.

Crash reports, failure reports and the desktop log stream

Alpha testers do not send stack traces, so the software sends them. Three channels, each with a different reach:

• Crash reports (Sentry). When the web app throws an error it did not handle, the exception, the release it happened in and the component stack go to Sentry, tagged with your account id — never your email, never a request body, never library contents. No session replay and no performance traces are recorded, and an ordinary “not found” or “signed out” response is not sent. The desktop app reports the same way for its window, its shell and the backend it runs on your machine, on by default; the switch is Settings → Privacy & data → Send crash reports from this app, and it takes effect the next time you open MixReady. The server reports its own exceptions to Sentry too.
• The desktop log stream. The backend the desktop app runs on your machine sends its informational log lines — what it scanned, exported, refused and why — to our server every thirty seconds, and our server forwards them to our log store at Grafana Cloud, tagged with your account id and a random per-launch session id. Before a line leaves your machine, anything shaped like a secret is dropped, email addresses are dropped, and every file path is cut to its file name; the server applies the same redaction again. The lines carry your operating system and version, architecture, MixReady version and the versions of the DJ software found on the machine — never paths. They are kept for 14 days. While the operator is investigating a problem you reported, they can raise your account to the verbose level, which adds per-track lines (file names, titles); it returns to normal afterwards. There is no separate switch for this stream: it runs whenever the desktop app is signed in.
• Failure reports and feedback go to our own inbox on our own server, as described above. Nothing you type is sent to Sentry or Grafana — only the id that lets the operator put your words next to the crash they describe.

Publishing a mix

MixReady can render a set as one continuous mix and publish it to your SoundCloud or Mixcloud account. The rendering happens entirely in your browser, from files on your computer or the streaming previews the set uses, and the audio never touches our server: your browser uploads it straight to SoundCloud or Mixcloud. To do that, our server hands the page a short-lived copy of the access token you granted for that account — enough to upload as you for about an hour, never the longer-lived token that could renew itself. The tracklist that becomes the mix’s description is composed on our server from the set. Both routes are new and lightly exercised; the privacy shape above is the part that is fixed.

Sharing a set

Every set is private until you share it. Share offers three choices: Private; Anyone with the link, which is unlisted, so nobody finds it unless you send it to them; and Community, which also lists it for other DJs in the app. A shared set gets a page at app.mixready.art/s/… that anyone holding the link can open, without an account.

• What the page shows: the set’s name, genre and length, the description you wrote, and its tracks in order with their titles, artists, tempo and key. Your card is on it unless you turn Show my card off: your picture, display name and @handle — or, if you signed in with DJ ID, the stage name, username and picture DJ ID gave us, and the location it gives us if it does. The request you typed to build the set appears only if you turn Show the brief on.
• Your own files go out as their tags spell them. A track that is a file from your own library with no catalogue match is shown by the title and artist written in that file’s tags. The share dialog lists those tracks by name before you share, and Show my own files as “ID – ID” publishes neither. The file itself, and where it sits on your disk, are never on the page.
• What is never on it: your email, your account id, your other sets or your library. The link is a random code, not derived from your account, and your picture is served under that code rather than at an address that names you.
• Pasted into a chat, the link unfurls: the app showing it fetches the page’s title, a line of description and a picture drawn from the set’s cover art — with your name on both, unless your card is hidden. Shared pages ask search engines not to index them.
• What visitors can do: play its tracks through Apple’s and SoundCloud’s own players (below), copy the track list, save it to their own Apple Music library, and report the page to us. A DJ who finds a Community set in the app can also star it and add it to their own Apple Music library.
• What we record about visitors: nothing that identifies them. The page sets no cookie; views, plays, copies and saves are counted as plain numbers, per page and in total, with no visitor id. A report keeps what the reporter typed, and an email address only if they chose to give one.
• Taking it back: choose Private and the page comes down within a minute; sharing it again later brings the same link back. Reset link kills the current link for good and makes a new one. Deleting the set deletes its page, and deleting your account deletes every page you shared. A page we take down after a report stays down — the terms say when that happens.
• The page follows the set. A share is a live pointer, not a copy: rename, re-sequence or rebuild the set and the page shows the change.

Site analytics, in consent mode

The public site — the landing page, the get-started guide and the free tools on this domain — counts visits with Google Analytics running in its consent mode, and asks once whether it may do so with a cookie. Answering once covers all of them. The guides, the research articles, the download page and this notice carry no measurement script at all. The honest version of both halves:

• Until you say yes — or if you say no: the measurement script loads but runs cookieless. Each page view sends Google a consent-denied ping — the page, where you came from, and the visit’s technical basics — with no cookie set, no id assigned and nothing stored on your device, so two of your visits cannot be linked. Google uses these pings for aggregate modelling, and like any web request they arrive carrying your IP address.
• What allowing adds: a random id in a _ga cookie, so return visits count once instead of every time. Google then receives the pages you view here, where you arrived from, rough location derived from your IP address, and your browser and device type, tied to that id. Never your email, never anything from inside the app — the app itself carries no analytics at all.
• Advertising stays off either way. The ad-storage, ad-user-data and ad-personalisation consent signals are hard-coded to denied; nothing here is an ads integration.
• Changing your mind: the choice lives in your browser, and you can clear it here — that deletes the _ga cookies too, and the site asks fresh on your next visit.
• This page never measures. The privacy notice carries no analytics tag at all — reading it sends nothing.

The free tools

The tools under /tools talk only to our own server, without any sign-in. A search box sends what you typed; Rate my set sends the tracklist you pasted. Those requests are answered and not stored — nothing you type into a free tool is kept, and none of it is sent to an AI model. Your IP address is used to rate-limit the tools and for nothing else. Two of them (genres and hot tracks) read Beatport’s catalogue through MixReady’s own credentials, so Beatport learns nothing about you.

The music players on the landing page and on shared sets

The landing page shows a few real DJ sets, and a shared set’s page shows that set; both let you play any track on them. Those players are not ours: each one is Apple Music’s or SoundCloud’s own widget, embedded in the page and served by them from embed.music.apple.com or w.soundcloud.com. Which of the two a track uses depends on where that record is available. Nothing plays until you press play on a track.

• What we send them: nothing about you. The page asks our own server for the tracklist; the widget’s address contains only the id of the record you pressed play on.
• What they see: Apple and SoundCloud serve their own players, so the usual consequence of loading anything from another company follows — they receive the request, which carries your IP address, it tells them the player was loaded on this page, and it lets them record how you use it. Apple describes this in Apple Music web player & Privacy; SoundCloud’s own privacy policy covers theirs. Those govern what happens inside the player.
• Signed in or not: if you are not, you hear a preview. If you are an Apple Music subscriber signed in to Apple in that browser, the widget will play the whole record — that is between you and Apple, and we are told neither way.
• Cover art on those tracklists is loaded from Apple’s and SoundCloud’s image servers for the same reason and with the same consequence.
• Nothing on this page. The privacy notice embeds no player and loads nothing from either of them.

Saving a set to your Apple Music library

Each of those sets, and every shared set’s page, has a Save to Apple Music button. It runs Apple’s own MusicKit library, loaded from js-cdn.music.apple.com the first time you press it and never before — if you do not press it, none of this happens and Apple is not told you were here.

• You sign in to Apple, not to us. Apple’s own sheet opens over the page and issues a token to your browser. That token never reaches our server — your browser sends the playlist straight to Apple with it. We do not learn your Apple ID, whether you signed in, or whether the playlist was created.
• What is created: a playlist in your library, named after that set with “— made with MixReady” after it. Nothing else in your library is read or changed, and we have no way to reach it afterwards.
• What we do send: our own Apple developer token, which the page fetches from our server. It identifies MixReady to Apple and carries nothing about you.
• Writing to a library needs an Apple Music subscription. Without one, Apple refuses the save and the button says so. That exchange is between you and Apple.

Signing in with another account

You can sign in with an email address and password, with a one-time link emailed to you, or through Google, Apple, SoundCloud or DJ ID. With a provider, you sign in on their page; they tell us an opaque id for you, your email address and, where they offer it, a name and picture, and they learn that you signed in to MixReady. MixReady never sees your password for that provider. You can link and unlink these methods, and set or remove a password, under Settings → Account. The emailed link, email confirmations, password resets and the link that connects a provider from another device are all sent through Resend (below).

The desktop app

• Sign-in happens in your browser, on app.mixready.art; the app receives a session and keeps it in your operating system’s keychain. It never holds a password.
• It scans and exports on your machine. Everything about your files that leaves is listed under Your library scan; the files and their paths do not.
• It checks for updates by fetching a small version file from dl.mixready.art, our download host on Cloudflare. That request carries your IP address and nothing about your account. Nothing installs on its own: the app tells you, you say when.
• It reports crashes and streams its logs as described above; the crash-report switch is in Settings → Privacy & data.
• Backups it makes for you — before it writes anything into rekordbox, Serato, Traktor, VirtualDJ or djay, it copies what it is about to change: the database or the playlist file, and for a Serato cue write the audio file itself. Copies go into MixReady’s own data folder on your machine, or beside the DJ software’s own backups, and you can put one back from Settings → Your software → Library backups, which lists each one with the time it was taken. The store is held to about two gigabytes, oldest first, except the copy from before MixReady first wrote to a file — that one is kept. None of it ever leaves your computer: the copies are not uploaded, not synced, and not included in any backup we hold, which also means they are only as safe as the disk they are on.

The browser extension

The MixReady extension for Chrome saves a DJ set you are reading on 1001tracklists.com into your own MixReady library. It is covered by this notice, and its data handling is deliberately narrow.

• It acts only when you click it. There is no content script and no background process, so it reads nothing until you press the toolbar button, and nothing after the popup closes.
• What it reads: the address, title and rendered HTML of the single tab you clicked on — and only to save that set. It does not read other tabs, your browsing history, or your bookmarks.
• Where that goes: to the MixReady server you paired it with, and nowhere else. If you run MixReady on your own computer, the set never leaves it.
• What it stores on your device: a pairing token, that token’s id, the address of your MixReady server, and the date you paired. Nothing else, and never a password — the extension is never given one. The token can only save sets; it cannot read your library or change your account. Signing out in the popup deletes all four immediately, and you can revoke the token from Settings at any time.
• No third parties. No analytics, no advertising, no error-reporting service. The extension contacts your MixReady server and the page you are already on. That is the complete list.

Sets you capture are yours, and nobody else’s — see Captured tracklists above.

Who touches the data

Backups. One archive of the server’s data is made each night, encrypted on the machine (GPG, AES-256) before it leaves it, and stored in Cloudflare’s R2 object storage. Seven are kept off the server and three on it; older ones are deleted automatically. An erasure request covers them (below). The archive contains everything under What MixReady stores; it does not contain your audio, which was never there.

Where your data lives

Your account and everything listed under What MixReady stores sits on our servers in the European Union. The operator is in Canada, and the other companies in the table above are mostly in the United States.

So wherever you are, some of your data crosses a border. If you are in the European Economic Area, the United Kingdom or Switzerland, the service’s own copy stays in the region, but the operator reaches it from Canada and each processor in the table receives its share under that company’s standard data-transfer terms. If you are anywhere else, your data is stored in the European Union. Canada’s federal privacy law (PIPEDA) applies to the operator regardless of where you are.

How it is protected

• In transit: everything between you and the server is encrypted (TLS). The server itself accepts no inbound connections; it reaches out to Cloudflare, which fronts it.
• At rest: the tokens for your connected accounts are encrypted with a key the app holds; passwords are stored as salted hashes; the operator’s files that hold personal data are readable by the service alone. Backups are encrypted before leaving the server.
• Sessions: a sign-in lasts 14 days. You can end one session or all of them from Settings; a token pasted into a browser cannot delete your account, because deletion asks for your password again.
• Access: one operator has access to the server and the admin console, which sits behind Cloudflare Access and an email allowlist. The admin console shows who an account belongs to and what they reported; it does not show your sets’ contents or your library.
• If it goes wrong: should a breach affect your data, you will be told by email without undue delay, and the supervisory authority within the 72 hours the GDPR sets, with what was affected and what to do.

Honest limits: MixReady runs on a small number of servers and is run by its operators. That is the alpha’s shape, and it is why the terms ask you to keep your own copy of anything you depend on.

Export and deletion

Both are self-serve, in the app under Settings → Privacy & data:

• Export downloads the account data MixReady stores as one JSON file — account details, preferences, connections (never tokens), devices, your sets with their tracklists, your blacklist and the feedback you sent. Not yet in the file: your play-history sessions, collections, the analysis data from your scan, the picture you uploaded, and the log lines in our log store. Ask by email and they will be sent to you.
• Delete account asks for your password, then erases your account record and sign-in identities, preferences, connection tokens, paired devices, your sets and collections, your library’s ownership records, your play-history contributions, your captured tracklists, your feedback and its attachments, your waitlist and refused-sign-in rows, your usage counters and your analysis data — immediately, from the live system. Anything you contributed to shared pooled statistics is recomputed without you. If any part could not be removed, the app says so rather than reporting success. An account that signs in only through a provider sets a password first (Settings → Account), or emails instead.

If you can’t sign in (blocked, or the password is gone), email support@mixready.art from your account address and the same deletion runs operator-side. Backup copies containing your data age out within seven nights and are purged no later than 30 days after an erasure request; log lines naming your account id expire from the log store after 14 days; crash reports expire on Sentry’s own schedule. The shared reference corpus (public tracklists, catalogue metadata) is not personal data and stays.

Your rights

Wherever you are, you can ask what MixReady holds about you, have it corrected (email, username, name and picture are yours to change under Settings → Account), have it deleted, receive a copy, and withdraw any consent you gave — the play-history switch is in Settings, the site-analytics choice is above. Requests go to support@mixready.art and are answered within 30 days. You can also complain to the Office of the Privacy Commissioner of Canada or, in the EEA or the UK, to your local data-protection authority. None of this costs anything.

Children

MixReady is not for children. You must be at least 16 to hold an account (or older where the law where you live says so), and MixReady does not knowingly collect data from anyone younger. If you believe a child has an account, email and it will be removed.

Retention

• Account data lives until you delete it.
• Waitlist rows live until the address becomes an account (they are then deleted with it) or you ask for removal. Refused-sign-in rows are capped at 2,000 and scrubbed with the account they name.
• Spent invite codes stop recording who used them once that account is deleted.
• Feedback and failure reports live with your account and go with it.
• A shared page lives until you make the set private, delete it or delete your account. Reports about a shared page are kept in our inbox with the others; if you sent one and want it gone, ask.
• Logs: 14 days at Grafana Cloud; the server’s own journal rotates with its size limits.
• Backups: seven nightly copies, then deleted.
• Rate-limit counters keyed by IP address: five minutes.
• The shared reference corpus (public tracklists, catalogue metadata) is not personal data and stays.

The formal bit

Processing your account, library and set data — publishing a set you chose to share included — is necessary to provide the service you signed up for (GDPR Art. 6(1)(b)). Optional things — the play-history pool, the site-analytics cookie on the marketing pages — run on consent (Art. 6(1)(a)), asked per switch, never bundled, withdrawable in the same place. Crash reports, the desktop log stream, automatic failure reports, rate limiting, reports about shared pages and the cookieless consent-mode pings rest on legitimate interest (Art. 6(1)(f)): keeping early software working, secure and lawful, and counting visits without identifying visitors. The waitlist rests on your request to be admitted. The data controller is the operator reachable at support@mixready.art. If this notice changes in a way that matters, the change is announced in the app or by email before it takes effect, and the effective date at the top always says which version you are reading.

What changed in this version

Against the version effective 31 August 2026, this one:

• Discloses crash reporting (Sentry) on the web app, the desktop app and the server, the desktop log stream into Grafana Cloud, and the automatic failure reports — none of which the previous version named.
• Adds the sign-in providers (Google, Apple, SoundCloud, DJ ID) and the emailed sign-in link, and the profile fields an account now carries (username, display name, picture).
• Adds Apple Music and Mixcloud as connectable accounts, Serato, Traktor, VirtualDJ and djay alongside rekordbox, and the publish-a-mix flow.
• Says what the backups MixReady takes before writing to your DJ software hold, that you can restore one yourself, how long they are kept, and that they never leave your computer.
• Corrects the library-scan section: file paths are not sent to the server (the previous version said they were, which had been true for older installations); says exactly which fields are.
• Adds the waitlist, the refused-sign-in list, usage counters, the free tools, the update check, and the two cookies the server sets.
• Says where the servers are (the European Union), the international transfers, how data is protected, your rights and where to complain, and an age floor.
• Updates the processor list (Sentry, Grafana, Resend) and the export’s known gaps.
• Names OpenAI and Anthropic, the two model providers: what each is used for, and that neither receives your name, email, account or anything else that identifies you.
• Adds sharing a set: what a shared page shows — including your own files’ tags unless you mask them — who can see it, what its visitors’ players and reports involve, and how to take it back.