Privacy-first diary generation
An automatic diary creates an uncomfortable trade-off. To generate a record of your day, a service needs access to the raw material of your day: your calendar, your messages, your tasks, your commits. The more it knows, the better the entry. The more it knows, the more you have to trust it.
This is the core tension of automated journaling, and pretending it does not exist would be dishonest. If you are going to hand over fragments of your daily life to a service, you deserve to know exactly what happens to them. Not vague assurances. Specifics.
Here is how deariary handles your data, written plainly, including the parts we are still working on.
What we collect and what we do not
Every integration in deariary follows a principle: collect the minimum data needed to write a useful diary entry, and nothing more.
For GitHub, that means commit messages, pull requests, and code reviews. Not your source code. Not a single line of it. Not your file trees, not your secrets, not your environment variables. The GitHub Events API provides activity metadata, and that is all deariary reads.
For Slack, that means messages from channels you explicitly select. Not your DMs. Not group DMs. Not channels you did not choose. You pick which rooms are relevant, and everything else stays invisible.
For Todoist, that means completed tasks only. Your pending to-do list, your overdue items, your upcoming deadlines: deariary never sees them. The OAuth scope is data:read, which is read-only. It cannot create, edit, or delete your tasks.
For Bluesky, that means your authored posts. Not DMs, not other people’s content. And if you delete a post before the daily sync runs, it is not included. Your right to take something back is respected.
This pattern repeats across every integration. Google Calendar events, but not attendee emails. Webhook payloads you explicitly send, shaped however you choose. The boundary is always the same: activity metadata in, personal content out.
Nothing is collected without your explicit permission. You choose which services to connect, which channels to include, which repositories to share. And you can revoke access at any time from each service’s settings page. Once revoked, deariary loses access immediately.
How your data is stored
Your diary data lives on Google Cloud Platform. Here is what that means concretely.
In transit: All data is encrypted with TLS 1.3. Every API call between your browser and deariary, between deariary and integration providers, and between deariary and its own infrastructure uses encrypted connections. The database sits on a private network with no public IP address. It is not reachable from the internet.
At rest: Data stored in Google Cloud Storage uses AES-256 encryption. Your diary entries, raw activity data, and generated content are all encrypted on disk. Integration credentials (OAuth tokens, API keys) receive an additional layer: AES-256-GCM encryption with a dedicated key, using a unique initialization vector for every single encryption operation. Even if someone gained access to the database, your tokens would be unreadable without the separate encryption key.
Authentication: deariary uses IAM-based authentication for its database connections, not passwords. The database does not accept password-based logins. Cloud Run services connect through Google’s private networking, authenticated by identity, not shared secrets.
These are not marketing phrases. They are the actual infrastructure decisions, and they are verifiable in practice.
What happens when your data reaches the LLM
This is the part most people are right to worry about.
To turn raw activity data into a readable diary entry, deariary sends that data to a language model. The normalized activity (calendar events, commit summaries, message excerpts, completed tasks) goes to the LLM provider as a prompt. The model returns prose. That prose becomes your diary entry.
The LLM providers deariary uses are OpenAI, Anthropic, and Google Gemini. Your data is sent to their APIs for processing. That is a fact, and there is no way around it for a cloud-based automatic diary. If a service generates text from your data, that data must reach the model.
Here is what mitigates the risk:
Your data is not used for training. None of the LLM providers use API data to train their models. This is covered by their data processing agreements, and deariary has signed DPAs with each provider. Your Tuesday standup notes are not making anyone’s language model smarter.
Only activity data is sent. The LLM receives a structured summary of what happened: event titles, task names, message snippets from selected channels. It does not receive your full Slack history, your entire calendar archive, or anything beyond the day being generated.
The prompt is explicit. The system prompt instructs the model to write only from provided data, not to invent facts, and not to fabricate emotions. The diary is a record, not a creative writing exercise.
We are transparent about the sub-processors who handle your data. The full list, including each provider’s purpose, data location, and applicable agreements, is published on our sub-processors page.
Your data, your control
Two rights matter most for a diary service: the right to leave with your data, and the right to leave without it.
Data export. You can export everything at any time. Your diary entries are stored as Markdown and YAML, not in a proprietary format. The export produces a ZIP file containing all your entries and metadata. This works on every plan, including the free plan, because data portability is not a premium feature.
Account deletion. When you request deletion, a 30-day grace period begins. You will receive a confirmation email and a reminder before the period ends. You can cancel during this window if you change your mind.
After 30 days, the deletion is permanent and comprehensive. Your diary entries, raw activity data, generated content, integration credentials, notification history, analytics events, LLM usage records, and payment information are all purged. Every file in cloud storage is removed. Every database record across more than 40 tables is deleted in a single atomic transaction. Your Stripe subscription is cancelled. A completion email is sent to confirm the process finished.
This is not a soft delete that hides your profile while keeping your data in a backup somewhere. It is a hard delete that removes every trace.
What we do not do
Sometimes what a service does not do matters as much as what it does.
We do not sell your data. Not to advertisers, not to data brokers, not to anyone. Our Do Not Sell page states this explicitly, as required by CCPA.
We do not use tracking cookies. The landing page runs cookie-free, self-hosted analytics. No Google Analytics. No Facebook Pixel. No third-party tracking scripts. No consent banner is needed because there is nothing to consent to.
We do not read your DMs. Across Slack, Bluesky, Discord, and any messaging integration, direct messages are excluded by design. This is not a setting you need to remember to toggle. It is a hard boundary in the code.
We do not access more than we need. Todoist integration requests data:read scope. Google Calendar uses a read-only iCal feed, not OAuth with write permissions. GitHub reads event metadata from the public Events API, not repository contents. The principle is minimum viable access, enforced at the API permission level.
The honest parts
No privacy story is complete without acknowledging the limits.
deariary is a cloud service. Your activity data is transmitted over the internet, processed on remote servers, and stored in a data center you do not control. If complete local-only privacy is your requirement, a paper notebook or an offline app like Daylio will always be the more private option. We said this in our what is automatic journaling explainer, and it remains true.
LLM processing involves sending your data to a third-party API. We trust the contractual protections (DPAs, no-training policies), but we do not control those providers’ infrastructure. If this is a dealbreaker for you, that is a reasonable position.
We are a small team. We do not have SOC 2 certification or a dedicated security team. What we have is careful infrastructure design, encryption at every layer, and a commitment to being straightforward about what we do and do not protect.
Why this matters for a diary
A diary is one of the most personal things a person can own. It contains the texture of your days: what you worked on, who you talked to, how you spent your time. Handling that data carelessly would be a betrayal of the trust that makes the product possible.
We built deariary because we believe everyone deserves a record of their days. That belief comes with an obligation: the record must be handled with the same care you would give a physical journal locked in your desk drawer. We cannot offer the physical lock. But we can offer encryption, minimal data collection, transparent processing, full data portability, and the ability to walk away cleanly.
Your diary is yours. That sentence is easy to say. The engineering to make it true is harder. We think we have done the work.
