Privacy

Lyra is not a company. It is a personal project built and operated by one individual, reachable at hello@lyracal.com. There is no support desk, no sales team, and no third party being paid for your attention.

• Your account. Your email address. Your time zone. Your display preferences — theme, week start, density, hour format, which fields you want to see. A name and a profile picture only if you signed in with Google and Google supplied them.
• Your calendar. Event titles, notes, start and end times, the time zone an event was written in, whether it is all-day, its colour, the calendar it sits on, reminder offsets, and the email address of every guest you invite along with their answer. Memos too — their text, their list, their checklists and their due dates.
• Delivery records. One row per email Lyra owes you or a guest — which reminder or invitation it was, when it was due, how many attempts it took, and whether it was sent, cancelled or failed. This exists so that “why did that reminder never arrive” has an answer.
• Notification permissions, if you turn them on. If you ask for reminders to arrive as notifications rather than email, your browser issues Lyra an endpoint— a long, unguessable web address belonging to your browser maker’s notification service — plus two keys that encrypt each notification so only that device can read it. One row per browser on one device. The endpoint identifies that device, and Lyra also keeps a coarse word for it (“iPhone”, “Mac”) so you can tell which one to turn off, and the date it was last seen. Never your browser’s full identification string. The row is deleted the moment you turn notifications off, and also the moment the notification service reports that the browser is gone.
• A connected Google calendar, if you connect one. The Google address you connected, a lasting permission from Google (stored encrypted, never in readable form), which of that account’s calendars you chose, and a copy of the events on them for the window Lyra keeps — a month back and six months ahead. The copy holds the same things a Lyra event holds: title, details, times, whether it is all-day, and whether Google says the hour is busy or free. See the section on it below.
• A connected Apple calendar, if you connect one. The iCloud address you connected, the app-specific passwordyou generated for Lyra (stored encrypted, never in readable form), which of that account’s calendars you chose, and a copy of the events on them for the same window — a month back and six months ahead. Apple offers no other way in: there is no “connect” button for iCloud calendars, so Lyra signs in the way every other calendar app does. You can revoke the password at appleid.apple.com at any time, and doing so stops the syncing immediately.
• Calendar subscriptions, if you add any. You may connect third-party calendar feeds by giving Lyra a link to one. Their contents are fetched and stored, in the same window and the same shape as everything above. The link itself is stored encrypted, because for many calendars the link isthe password — anyone who has it can read that calendar. Lyra only ever reads it, and only over a secure connection.
• Sign-in. A session row for each browser you are signed in on, the one-time sign-in tokens emailed to you (which expire), and — only if you use Google — the tokens Google issues for your account.
• Your subscription, if you have one. Two identifiers Stripe gives Lyra — one for you as a customer, one for the subscription itself — plus the status Stripe reports, which price you are on, whether you pay monthly or yearly, when the current period ends, whether you have asked it to stop at the end of that period, and, if a payment failed, when the grace period runs out. Lyra also keeps a short ledger of the notifications Stripe sends it: an identifier, a type, two timestamps and the outcome. Never the contents — no card number, no card brand, no billing address, no invoice.
• Your daily briefing. The sentence written for a given day is cached against your account so the same day is not written twice. If you are on premium and you pressed play, the audio of that sentence is cached too.
• Product events. So that Lyra can tell whether it is being used and whether people come back, its server writes a line for certain things that happen: an account was created, someone signed in, an event or memo was made, a briefing was played, an invitation went out, an RSVP page was opened, a subscription started or stopped. Each line is a name, a time, and — for a signed-in action — which account it belongs to. There is no IP address, no browser or device information of any kind, and never any of your words: not an event title, not a note, not a label name. Alongside the name sit a few counts and yes/no facts, like whether an event was all-day or how many guests it had. Opening the app is recorded at most once a day per account, not once a page.

There is no advertising identifier, no device fingerprint, no location, no contacts import and no address book. Lyra does not know what other sites you visit.

The product events stay in Lyra’s own database. They are not a tracker: there is no script, no cookie and no third party involved, and every line is written by Lyra’s own server as it answers your request. Deleting your account deletes these lines along with everything else. What survives is the daily arithmetic — “four people opened Lyra on Tuesday” — which is a number rather than a person.

When you add a guest, Lyra stores the address you typed and the answer they gave. Guests never need an account. Their address is used to send that invitation, its updates and its cancellation, and for nothing else — no list, no newsletter, no later contact.

One further thing, stated plainly because it is the only place a guest’s address touches the product-events log above. Lyra wants to know whether people who are invited to something later make an account of their own. To answer that without keeping guest addresses in a second place, it stores a scrambled stand-in for the address instead: a fixed-length code produced with a secret key, from which the address cannot be recovered and which matches nothing outside Lyra. Two lines carrying the same code came from the same address; that is all anyone, including Lyra, can learn from it.

Lyra is small, so it rents the parts it does not build. This is the whole list. Each of these sees only what it needs to do its job, and none of them is an advertising or analytics company:

• Vercel hosts the site and runs the server. It sees the ordinary web-server things — your IP address, your browser, and which URL you asked for — and, through Vercel Blob, it stores the premium audio files described below.
• Neon hosts the Postgres database. Everything described above lives there.
• Resend sends every email: sign-in links, reminders, invitations, updates and cancellations. It sees the recipient address and the contents of that particular message.
• Inngest runs the clock that decides when a reminder is due and when the weekly chores run. It sees job identifiers and timings only — no event titles, no notes, no email addresses.
• Stripe takes the payment, if you subscribe. See below.
• OpenAI turns your briefing into speech, but only on premium and only when you press play. See below.
• Anthropic writes the daily briefing, but only when Lyra is configured to use it. See below.
• Googleis involved if you sign in with Google, and — a separate choice, made separately — if you connect Google Calendar. Signing in tells Lyra your address and nothing else. Connecting the calendar lets Lyra read the calendars you pick. Lyra never writes to Google Calendar, and never reads your Gmail, your contacts, or anything else in your Google account. See below.
• Appleis involved only if you connect an iCloud calendar. Lyra reads the calendars you pick, over Apple’s standard calendar protocol, using an app-specific password you generate and can revoke. It never writes to iCloud, and never reads your mail, your contacts, your photos, or anything else in your Apple account.
• Your browser maker’s notification service— Google for Chrome, Apple for Safari, Mozilla for Firefox, Microsoft for Edge — delivers a notification to your device, and only if you turn notifications on. This one is worth being precise about: each notification is encrypted on Lyra’s server to keys that only your browser holds, so the service carries a sealed parcel it cannot read. What it does learn is that a parcel was sent to that device, and when. It is also the only party that can tell Lyra a device has gone away, which is how those rows get deleted.
• Calendar feeds you add are whoever publishes them. If you subscribe to a calendar link, Lyra fetches that link on a schedule; whoever runs it can see that it was fetched. Lyra sends them nothing about you beyond the request itself, and never sends them anything from your calendar.

If you never subscribe and never press play, Stripe and OpenAI never receive anything about you at all. If you never turn notifications on, no notification service receives anything about you either.

The briefing is the sentence at the top of your calendar that tells you what your day looks like. It can be written two ways. By default it is composed on Lyra’s own server from your events, and nothing leaves.

When Lyra is configured with an Anthropic API key, that day’s calendar is sent to Anthropic’s API to be written instead. What is sent, exactly: your event titles, the name of the calendar or label each one is on, the times as they read on your screen, durations, whether an event is all-day, any note you left on an event (up to 160 characters), reminder offsets, how many guests are going, your time zone, and the text of any memo that is due — including one that was due on an earlier day and is still open. What is not sent: your name, your email address, your guests’ email addresses, your checklists, and any event from a day other than the one being described.

The written result is cached so the same day is not sent twice. If you would rather no version of your day ever left the server, say so at hello@lyracal.com — a per-account switch is on the list.

Connecting is a separate decision from signing in, and neither implies the other: an account created with a sign-in link can connect Google Calendar, and an account created with Google is not connected to anything until it says so.

It only ever reads, and it only reads calendars. The permission Lyra asks Google for is the read-only calendar one. Lyra cannot create, change or delete anything in Google Calendar, and it has no access to Gmail, Drive, contacts or anything else. If you try to change an event in Lyra that came from Google, Lyra will not let you — it says where the event lives and links you there.

What is copied. For each calendar you turn on, Lyra keeps a copy of the events in a rolling window — thirty days behind and one hundred and eighty ahead. A copied event carries its title, its details and location, its start and end, whether it is all-day, and whether Google marks the hour busy or free. Where Google does not tell Lyra what an event is — a private event on a calendar shared only as free/busy — Lyra shows the hour as “Busy” with no title, because that is all it was given.

The permission is stored encrypted. Google issues a lasting permission so Lyra can keep the copy fresh without asking you again. It is encrypted before it is written to the database and is never stored in readable form. The short-lived keys Lyra uses minute to minute are never stored at all.

Copied events are treated exactly like your own. They are counted in the day’s summary, they are searchable, and they block out time when Lyra looks for a free slot — and they are included in the daily briefing on the same terms as everything else. Which means: if the briefing is being written by Anthropic (see above), the titles and times of copied events are part of what is sent, in exactly the way your own events are. That is the point of connecting, and it is said here rather than assumed.

Disconnecting. Turning off one calendar removes its events from Lyra. Disconnecting the account removes the permission, hands it back to Google, and deletes every copied calendar and event that came with it. Nothing in Google Calendar is changed or deleted by any of this — the copy goes, the original stays.

Lyra’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of information received from Google Workspace APIs will adhere to the Google Workspace API User Data and Developer Policy, including the Limited Use requirements. In plain terms: calendar data is used to show you your own calendar, and nothing else. It is not sold, not transferred to anyone, not used for advertising, not used to build a profile of you, and no human at Lyra reads it.

The same rules as above, in every respect that matters: one way, read only, the same rolling window, and the copied events are treated exactly like your own — counted, searchable, blocking out time when Lyra looks for a free slot, and included in the daily briefing on the same terms as everything else. If the briefing is being written by Anthropic, the titles and times of copied events are part of what is sent, in exactly the way your own events are.

Applepublishes no “connect” button for calendars — no equivalent of the Google permission screen exists — so Lyra connects the way every other calendar app does: with your iCloud address and an app-specific passwordyou generate at appleid.apple.com. Your ordinary Apple password will not work, and on an account with two-factor turned on it cannot be made to. That password is stored encrypted, never in readable form, and it is the only credential Lyra holds for Apple. Revoking it at appleid.apple.com stops the syncing at once, from Apple’s side, without needing Lyra’s cooperation.

Calendar subscriptions are any calendar that publishes a link — a work calendar, a university timetable, a fixture list. You give Lyra the link; Lyra fetches it on a schedule and stores what it contains. Two things worth saying plainly. The link is treated as a secret, because for most services it is one: anyone holding it can read that calendar, so Lyra stores it encrypted and never displays it back in full. And Lyra will only fetch links on the public internet over a secure connection — a link pointing at a private address is refused, so a subscription can never be used to make Lyra read something it would not otherwise reach.

Disconnecting either one deletes every calendar and event copied through it. Nothing in iCloud, and nothing in a subscribed calendar, is changed or deleted by any of this — the copy goes, the original stays.

On the free plan, the briefing is read aloud by your own device. That is your browser’s built-in voice; nothing is sent anywhere, and this page has nothing to add about it.

Premium replaces it with a natural voice, and that is made by someone else. When a premium account presses play, the text of that day’s briefing — which is written from your own event titles, and can therefore contain them — is sent to OpenAI’s speech API, which sends back an audio file. Your name, your email address and your guests’ addresses are not sent. Nothing is sent on a day with nothing on it, and nothing is sent unless you press play.

The audio is then stored in Vercel Blob so that pressing play again on the same day costs nothing and sends nothing. Its address is never given to your browser: playing it is a request to Lyra, which checks that you are signed in and that premium is active before it streams you the bytes.

Premium is handled end to end by Stripe. Subscribing sends you to a page Stripe runs, on Stripe’s own domain, and so does every later change — updating a card, seeing an invoice, cancelling. There is no card field anywhere in Lyra, and no Stripe script on any Lyra page.

What Lyra sends Stripe when you start: your email address, which price you chose, and Lyra’s own internal identifier for your account, so the answer can be matched back to you. Nothing about your calendar is sent, ever.

What Stripe sends Lyra back: the two identifiers and the subscription facts listed under What is stored. Your card number, your card brand, your billing address and your invoices stay with Stripe. Stripe’s own privacy notice governs what it does with them.

Lyra sets a session cookie and a theme cookie. That is the list.

• The session cookie is set when you sign in, so the next page knows it is you. Signing out clears it.
• lyra.theme remembers whether you asked for the light theme or the dark one, so the first paint is the right colour.
• Signing in also briefly sets a small number of Auth.js cookies whose only job is to make that sign-in safe against forgery.

There is no analytics service, no tag manager, no advertising pixel, no session recorder and no third-party script of any kind. Nothing on any Lyra page phones anywhere. The product events described above are written by Lyra’s own server as it answers your request — they involve no script running in your browser and no cookie beyond the ones named here. Paying is a redirect to Stripe rather than a Stripe script embedded in Lyra, so Stripe learns nothing about you until you arrive on its page. Fonts are served from Lyra’s own domain, so loading a page tells nobody else that you did. Your browser also remembers which view you were last on (lyra.view); that never leaves your device.

To run your calendar, to send the email you asked to be sent, to charge you if you asked to be charged, and to count how many people are using it. Nothing is sold, rented, or shared for advertising — there is no advertising. No third party here is paid for your attention or given your data to build a profile with.

Lyra does not use your events to train anything. Anthropic’s and OpenAI’s commercial API terms both say that inputs sent to them through the API are not used to train their models. That is their promise rather than Lyra’s, and it is worth reading it yourself if it matters to you.

• Your account and everything on your calendar: until you ask for it to go.
• Delivery records: 90 days after they reach a final state — sent, cancelled or failed. Anything still owed to you is never deleted on age.
• Cached briefings, text and audio alike: deleted after 30 days. The audio file is deleted from storage first and the record that names it second, so nothing is left behind that nobody can find.
• Copied events from any connected calendar — Google, Apple, or a subscription: only the rolling window — thirty days behind, a hundred and eighty ahead — and all of it goes the moment you disconnect or turn that calendar off.
• Notification permissions: until you turn them off, or until the notification service says the browser no longer exists — whichever comes first. Nothing here is kept on a timer, because a row that can no longer be written to is deleted as soon as that is discovered.
• Product events: kept until the account is deleted. They are not pruned on age, which is a thing that should change and has not yet.
• Subscription facts: kept while the account exists, because the next answer from Stripe has to be matched against the last one.
• Sign-in links are single-use and expire. Sessions expire on their own, and signing out ends them immediately.
• The daily and weekly counts — how many accounts opened Lyra on a given day — are kept indefinitely. They are numbers, not people, and they are what the deleted rows above were being counted for.

One honest exception, stated because it is true rather than because it is flattering: the ledger of Stripe notifications — identifiers and outcomes, never contents — is not pruned on age.

Until 8 August 2026 there was a second one. Audio written to Vercel Blob was not swept up when the 30-day record that pointed at it was deleted, so clips derived from your own event titles accumulated indefinitely. The weekly sweep now deletes the file and then the record. If a sweep cannot reach the storage service it leaves the record alone and tries again the following week, because that record is the only thing that knows the file’s address.

Email hello@lyracal.com from the address on the account and ask for a copy of your data or a correction. Deleting is self-serve: Settings → Your account → Delete account. You type the account’s own email address to confirm, and nothing about it is recoverable afterwards.

Deletion removes your account, your calendars, your events, your memos, your guests’ answers, your reminders, any email still queued for you, your cached briefings and the audio of them, your notification permissions, and your product events. What it does not remove: the daily counts, which are numbers, and the Stripe ledger described above.

If you are paying, deleting the account cancels the subscription. It is cancelled immediately rather than at the end of the period, and it happens before anything is deleted — so if it cannot be cancelled, nothing is deleted at all and you are told to try again or to cancel from the billing portal first. Until 8 August 2026 this was the other way round: the account went and the card kept being charged.

There is no password to leak: sign-in is a one-time emailed link or Google. Guest RSVP links are signed and expire. Everything travels over HTTPS, and the database is reached over an encrypted connection with credentials that live only on the server. Stripe’s notifications are checked against a signature before Lyra acts on them.

Lyra is also a young product run by one person. It is built carefully and reviewed, but it is not certified against any standard and it has not been audited by anyone but its author. Treat it accordingly.

Lyra is not designed for children and should not be used by anyone under 13.

The date at the top of this page changes with it, and the list below says what changed. If a change affects what is stored or who sees it, the account email address gets a note about it before it takes effect.

• 9 August 2026 — notifications described. Reminders can now arrive on a device instead of by email, which means Lyra stores an endpoint for each browser you turn them on in, along with the two keys that encrypt a notification to that device and a coarse word for what kind of device it is. Added to what is stored, to how long it is kept, and to what deletion removes. Nothing is sent to a notification service unless you turn notifications on, and email remains the fallback whenever a notification cannot be delivered.
• 8 August 2026 — two disclosed gaps closed rather than described. Deleting an account now cancels a live subscription first and refuses to delete anything if it cannot, and it clears that account’s briefing audio from storage; the weekly sweep deletes a cached briefing’s audio before the record that names it. Deletion is also self-serve now, in Settings.
• 7 August 2026 — Apple Calendar and calendar subscriptions described: the app-specific password Apple requires and that it is stored encrypted, that a subscription link is treated as a secret because it usually is one, that links pointing at private addresses are refused, what each one copies and for how long, and that copied events from all three sources reach the briefing on the same terms as your own. Apple and the publishers of any feeds you add named among the third parties.
• 6 August 2026 — Google Calendar sync described: what connecting permits, what is copied and for how long, that the permission is stored encrypted, that copied events reach the briefing on the same terms as your own, what disconnecting does, and the Limited Use disclosure Google’s own policy requires.
• 30 July 2026 — Stripe, OpenAI and Vercel named as the third parties they now are; the premium voice and the payment path described; product events, the briefing cache and the subscription facts added to what is stored; retention and deletion corrected, including what deletion does not reach.
• 25 July 2026 — first version.