Your audio stays on your devices.

Who runs Daisy

Daisy and mydaisy.io are built and operated by Egor Sazanov, Individual Entrepreneur, under the addicted product studio. Daisy has been publicly available since its launch on Product Hunt on June 2, 2026. Contact: hello@mydaisy.io. See also our Terms of use.

Daisy for Mac

What gets stored, and where

Recordings, transcripts and summaries are written to a folder inside your user Library, on your Mac. Daisy never uploads any of it. You can open the folder from the app menu, back it up, or delete it.

What runs on-device

Audio capture, transcription (Whisper, via Apple’s Neural Engine), and the default summarizer (Apple Intelligence) all run locally. No network call is involved in producing a transcript or a default summary.

What happens if you use a cloud summarizer

You can optionally point the summarizer at Anthropic, OpenAI or another supported cloud provider using your own API key. You can also connect the ChatGPT account already signed in through ChatGPT or Codex. In either case, the transcript for that summary request goes from your Mac to the provider you chose. Daisy is not in the middle and we never see the transcript. API keys stay in your Mac’s Keychain, not on our servers.

In ChatGPT-account mode, a local Codex App Server handles the request with that account. Daisy receives display metadata, available models and provider-reported plan windows, but does not read or store the account credentials. Before the first request, Daisy explicitly warns that the full transcript will be sent to OpenAI. Summary threads are ephemeral and run in an empty temporary folder with tools, approvals and file changes disabled.

Daisy 1.0.7.59 also offers an optional, off-by-default local protection step for supported cloud summaries. It pseudonymizes detected people, organizations and contact details before sending, then restores safe values in the result; detected credentials and payment-card numbers remain redacted. Detection can miss sensitive data or flag ordinary text, so this reduces disclosure risk but does not guarantee anonymity. Local providers receive the original text.

What happens if you connect Notion

If you paste a Notion integration token, Daisy sends finished notes from your Mac directly to your Notion workspace. Same shape: your machine to their API, nothing through us.

What happens if you connect a calendar

Daisy can link recordings to meetings on your calendar — useful for naming a recording after the event, prefilling attendees, and optionally starting / stopping the recording when the event starts / ends. Two independent paths, both opt-in: Apple Calendar through Apple’s EventKit (no third-party involved), and Google Calendar through Google’s OAuth API. The Google integration is also documented in detail in the dedicated section below so the disclosures Google’s API policy requires are in one place.

What gets downloaded on first run

The first time you pick a transcription or dictation model, Daisy downloads it from its publisher’s CDN (Hugging Face for Whisper; the FluidAudio model host for the optional Faster dictation engine). That’s a one-time HTTPS download of the model weights, not telemetry — no identifier about you is sent beyond the standard request that any HTTPS client makes. The CDN sees your IP and a User-Agent string, like any download.

What checks for updates

Every hour by default, Daisy fetches mydaisy.io/appcast.xml to see if a newer version is available. The request carries your current version number and a generic User-Agent — no account, no device ID, no usage data, no telemetry of any kind. You can disable automatic checks in About → Updates; the “Check for Updates…” menu item still works manually after that. Update downloads are signed with our EdDSA key and Daisy refuses to install anything whose signature doesn’t verify, so an attacker who hijacks the feed can’t push code at you.

No accounts

There is no Daisy account or Daisy sign-in and no feature flagging service. In the background Daisy only checks for updates (above) and, if you agreed, sends the day’s feature counts (below) — both to our own domain. Nothing else leaves your Mac unless you explicitly connect a provider (Anthropic, OpenAI, Notion, …) yourself or send a crash report.

Feature counts, only if you agree

Daisy asks once whether you’d like to help make it better. If you say yes, once a day it sendsapi.mydaisy.ioa short list of numbers for the previous day: how many times recording, dictation, summaries, imports, exports and other features ran (for summaries, which kind of provider), and how many times something failed — with the app and macOS versions, the interface language, the update channel and whether sync is on. Never meeting text, titles, names, file paths or device names, and no identifier: a report can’t be tied to your Mac. Our server adds the numbers into daily totals, keeps no report and doesn’t record the address it came from; Vercel, which hosts it, keeps its standard short-lived request logs. Every counter is listed in the app’s source, inDocs/usage-statistics.md. Turn it on or off any time in About → Help improve Daisy; turning it off deletes what was counted and not yet sent. Daisy for iPhone doesn’t send these counts.

Crash reports, only when you send one

If Daisy closes unexpectedly, it notes where it failed and, on the next launch, asks whether to send a report to us — showing the whole report first. Nothing is sent unless you press Send Report. A report holds where in the code Daisy failed, the app and macOS versions and the Mac model; never meeting text, titles, names, paths into your folders (your home folder is replaced with ~), device names or logs. Reports go to Sentry’s EU region. You can turn the question off in About → Crash reports → Never send; from the next launch the crash handler doesn’t start at all.

Check all of that yourself

None of this is worth much as a promise. Verify it is local walks through blocking Daisy at the firewall and recording a meeting anyway, lists every host the app is able to contact and what triggers each one, and shows where the files land on disk.

Daisy for iPhone and Apple Watch

Recordings and transcription

Audio is recorded on your device and transcribed on your iPhone. A watch recording transfers to your paired iPhone for transcription. Audio is never uploaded to Daisy or an AI provider. Recording works before the speech model is downloaded; transcription waits until the model and processing time are available.

Your private iCloud and your Mac

Sync is on by default and can be turned off in Profile. Transcripts, summaries, session metadata, attached images and session voice fingerprints sync through the private CloudKit database in your own iCloud account. Daisy has no access to that database. Audio transfers directly to your Mac over the local network, on request. Your own voice profile stays on the iPhone. Shared settings and provider API keys use iCloud key-value storage and iCloud Keychain.

Cloud summaries and questions

With your own provider key from Daisy for Mac, text goes directly to the provider you selected. Without a key, the first three summaries or questions are free after consent; further use requires a subscription. These requests go through api.mydaisy.io, hosted on Vercel, to Anthropic. Summaries send the transcript; questions send the question, selected recording excerpts and conversation context. Project notes and short summaries of earlier meetings may accompany a request; project memory can be turned off per project.

Before a proxy request leaves your iPhone, recognised names, organisations and contact details are replaced with placeholders, and recognised secrets are redacted. Detection is best-effort and can miss information. Daisy restores placeholders on your phone. Daisy does not retain meeting text after processing. Anthropic processes the request under its API terms and retention policies; this is cloud processing, not on-device processing.

Purchases and usage counters

Apple handles payment. To verify access, Daisy sends the signed subscription transaction to its server. Free access uses a random token stored in this iPhone's Keychain, which can survive a reinstall. The server keeps usage counters against that token or the original transaction identifier, not a Daisy account. Trial counters expire after up to 400 days; daily and per-minute limit counters expire after two days and two minutes respectively. Operational logs contain request size, time, result and the access identifier, never meeting text. These identifiers are not used for advertising or tracking across other companies' apps.

Your business card and Apple Wallet

Your own business-card fields, photo and logo are stored on your device. The colour used to light the card is calculated locally from the logo. To create an Apple Wallet pass, Daisy first asks you to confirm sending the card's name, company, role, contact details, link, optional logo and colour, and a random pass identifier to api.mydaisy.io on Vercel for a digital signature. Your photo is not sent. This request does not go to an AI provider and does not use your free AI requests or subscription quota.

The signing service processes the card in memory and does not store its contact fields or logo, or include them in application logs. It keeps aggregate request counters for abuse protection, without a contact or account identifier; these expire after two minutes or two days. Hosting infrastructure may keep ordinary request metadata for security. Apple Wallet shows a preview before you add the pass and keeps the copy you choose to add. You can remove that copy in Wallet. The QR contains the contact itself, not a public card URL, and can be read offline after creation.

Permissions and deletion

Microphone access records audio; camera access attaches photos or rehearsal video. Calendar titles and attendees can be saved with a meeting. Contacts are read locally to help prepare contact cards; reminders, messages and emails are created when you request them. Rehearsal speech recognition and business-card recognition run on the device. Models download from models.mydaisy.io on Cloudflare, with Hugging Face as a fallback. Those services receive ordinary download request metadata, not recordings. Delete recordings from the Library and erase Daisy's iCloud data in Profile. For requests about server identifiers or support messages, contact support@mydaisy.io. There is no Daisy account to delete.

This website (mydaisy.io)

The landing page is a static Next.js site hosted on Vercel. It uses Vercel Web Analytics to count page views, referrers, countries and device categories so we can understand which pages are useful. It does not set analytics cookies, create a Daisy account profile or collect meeting content. Vercel also keeps short-lived request logs (IP, user agent, URL) for hosting, security and abuse protection.

If you email support@mydaisy.io, that message lands in a regular inbox and is treated like any other email — kept only as long as needed to reply.

Subprocessors

• Vercel — site hosting and privacy-preserving aggregate web analytics for mydaisy.io, and hosting for the iPhone summary and question proxy. Website analytics never receives meeting content; proxy requests process the text described above.
• Hugging Face — hosts the Whisper model files the app downloads on first use. No account or identifier is sent.
• Anthropic, OpenAI and other selected AI providers — only if you opt into a cloud summarizer using your API key or, for OpenAI, your connected ChatGPT account. The traffic is between your Mac and the provider. For iPhone proxy summaries and questions, Daisy forwards the request to Anthropic as described above.
• Sentry (Functional Software, EU region) — crash reports from the Mac app, only the ones you choose to send, and errors in our own server code, without request contents.
• Notion — only if you opt in by adding an integration token, same shape.

Google Calendar integration (optional)

This section exists to satisfy Google’s API Services User Data Policy disclosure requirements. Daisy’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Connecting Google Calendar is entirely optional — Daisy works fully without it, and Apple Calendar via EventKit covers the same use cases without involving Google.

Data accessed

When you connect Google Calendar, Daisy requests a single OAuth scope: https://www.googleapis.com/auth/calendar.readonly. This is read-only — Daisy can only see events, never create, modify or delete them. From the events Daisy reads, the following fields are used: event title, start and end time, location, description, organiser, and the email addresses of attendees the calendar API returns to you. No other Google services or APIs are accessed.

Data usage

Calendar event data is used only on your Mac, and only to power user-visible meeting features:

• Naming — the upcoming meeting’s title is used as the recording title in your transcript.
• Auto-start / auto-stop — if you enable these in Settings, Daisy starts and stops recording at the event’s start and end times.
• Attendee prefill — attendee email addresses are written into the local transcript file as recording metadata, and the dominant external email domain is used to auto-suggest a free-form “tag” for filtering recordings in your local library (e.g. acme.com attendees → suggested tag “Acme”).
• Menu-bar “next meeting” — optional, off by default; shows the next event’s title in the macOS menu bar.

Calendar data is never used to train any AI or ML models — generalised or otherwise. Daisy does not run analytics, profiling, advertising, or any kind of automated decision-making on Google user data.

Data sharing

Daisy does not shareGoogle user data with any third party. The OAuth flow runs entirely between your Mac and Google’s servers; Daisy doesn’t operate any backend that touches calendar data. We are not in the path. Calendar data does not leave your Mac except for the original request to Google’s own API that fetched it.

If you later use a cloud AI summariser (with an API key or a connected ChatGPT account), only the transcript you ask to be summarised is sent — and that’s the transcript text you produced, not raw calendar fields. Even there, no calendar metadata is forwarded to those providers as a standalone payload.

Data storage and protection

OAuth refresh and access tokens are stored in the macOS Keychain on your Mac — system-grade encryption at rest, hardware-backed on Apple Silicon, isolated to your user account. No tokens are stored on any server. Calendar event data is fetched on demand when the app needs it (when arming auto-start, when starting a recording, when refreshing the Home view); the only persisted copy of any event field ends up in the local transcript file’s YAML frontmatter inside the sessions folder you picked — which means it’s protected by your macOS user-account isolation and any FileVault encryption you have enabled, the same as the rest of your local files.

Data retention and deletion

Refresh tokens are kept in the Keychain until you disconnect the integration. To disconnect at any time: open Daisy → Connections → Calendar → Google → Disconnect. That revokes the token with Google’s OAuth endpoint and removes the Keychain entry — no leftover credentials remain. You can additionally revoke Daisy’s access from myaccount.google.com/permissions.

Calendar event fields that ended up inside transcripts (titles, attendees, times) live as long as you keep the transcript file. To delete them, delete the recording in Daisy’s Library tab, or remove the file from your sessions folder in Finder. Because Daisy stores nothing on our servers, there is no separate “contact us to delete your data” process for calendar data — you delete the files and the data is gone.

Questions or deletion requests: support@mydaisy.io.

Your rights

Because Daisy stores your recordings and transcripts on your own devices and private iCloud, deleting local recordings is a matter of deleting the folder from inside the app or in Finder. For the personal data we do hold (support correspondence and the access identifiers and counters described above), reply to your own thread and ask us to delete it — we will.

Changes

If this policy changes in a way that affects what we collect, we’ll bump the “Last updated” date below and, for anything material, note it on the landing page.