Your data.

Three parts

The apps never talk to Google directly; they don’t know your Google sign-in. Access to the backend works through an address and an access key you enter once. The backend is the only place with logic, so rules run even when no device is on, and what happens stays traceable.

Google stays the source

Every event lives in your Google calendar and only there. Zulu reads through the Google Calendar API and writes through it. There is no second dataset that could drift apart. If you stop using Zulu, nothing is lost.

• Access: one OAuth sign-in per Google account with the Google Calendar permission. Google shows what Zulu accesses; you can revoke access in your Google account at any time.
• Range: Zulu loads 30 days back and 180 days ahead. If you request a range outside of that in the app, the backend fetches it from Google directly without storing it.
• Freshness: Google notifies the backend of changes via push. It also polls every minute in case a push message doesn’t arrive.

What the backend stores

One SQLite database, one file. In it:

• A cache of the events in the loaded range, so the apps are fast and rules can be computed. It is rebuilt from Google on every sync.
• What Google can’t represent: the type of an event (normal, travel time, blocker), the link between an event and its travel time or blocker, your rules, the travel times and exclusions per event or series, the roles of your calendars (personal, work, other).
• One access token per Google account, encrypted with AES-256-GCM and a key that only exists on the server.
• A log of syncs for troubleshooting.

No analysis, no sharing, no third-party services: the backend talks exclusively to Google and your apps.

What Zulu writes to Google

• What you create, change, or delete yourself.
• Travel time events (“⏳ Wegzeit”) before and after events with travel time, in the same calendar.
• Blockers in the target calendar of a rule, with the rule’s title, private, without details.
• Copies of working locations, if you set up a transfer rule.

All three are regular Google events with a short Zulu marker so Zulu recognizes them. Zulu only touches existing events when you do. And it only writes to calendars that were set as writable during setup; all others are read-only for Zulu.

What lives on Mac and iPhone

• Mac: the backend address and access key, encrypted via the macOS keychain. Plus window position, hidden calendars, the view, and since October 2026 a local cache of the last loaded events for a fast start.
• iPhone: settings in the device keychain. A cache of the loaded range in the app’s storage, so week, day, month, search, and widget show the last state even without a network. It is part of the device backup.
• The “time to leave” notification is scheduled locally by the iPhone app; nothing leaves the device for it.

Where the backend runs

Two options. Either we run the backend for you on our own hardware, not at a cloud provider. Or you run it yourself: it is a single process with one SQLite file, runs as a container (Docker or Podman), and needs little; a Raspberry Pi is enough. For push from Google, one address has to be publicly reachable; without it, Zulu works with the minute-by-minute poll only.

Disconnecting Zulu

1. In your Google account under Security › Third-party apps, remove Zulu’s access. From then on, the backend can neither read nor write.
2. Travel times, blockers, and working location copies remain in Google as regular events. Delete them there like any other event, or we remove them for you beforehand.
3. Let us know, and we delete cache, rules, and tokens from the backend. If you run it yourself, delete the database file.