Security and data.
Starlings keeps your team’s work in your own workspace, apart from every other team’s. Here is where it lives, who can see it, and what Starlings never keeps.
Your data stays yours
Starlings keeps your workspace’s records, documents and transcripts in its own storage, and you can take them with you.
- Where
- Cloudflare. Docs and records too
- Who else
- Nobody else holds a copy. Starlings doesn’t store audio or video
- Backed up
- Starlings copies every room and conversation to an EU bucket each day and keeps each copy thirty days. Each one restores on its own
- Separate
- Each workspace’s data is kept apart from every other workspace’s
- Export
- Download transcripts and notes as plain Markdown files at any time
Keep, the vault
Client credentials, sealed on your device. The server cannot read them.
- Unlock
- Touch ID, Face ID, or a passphrase. Locks after fifteen idle minutes
- Share
- Per vault, with an audit trail
- Where
- Mac and iPhone. On the web, a vault says to open it there: a browser never holds the keys
Security
Every entry point checks who you are. Starlings trusts no request because of where it came from.
- Hosts
- Only a Google account from your company can host, proven by Google itself. A room belongs to its owner by configuration, never by a submitted name or link
- Guests
- Ask to join, and hold a secret until the host admits you. No media flows before that, and the host has to be live within the last thirty seconds
- Keys
- A room key lasts two hours and opens one room. Sessions last eight hours. Logs never hold keys, transcripts, emails, or lobby secrets
- Devices
- Settings lists every Mac and phone signed in to your account, by name. Sign one out from anywhere and Starlings refuses its next request. A session stays on its device and never goes into a backup
- Captions
- Starlings shows captions only from the verified host. Reactions are an enum, so a guest cannot put text on your screen
- Agents
- Never hold a session. They come through one signed endpoint, rate limited, and Starlings logs every call
- Browser
- Strict content policy, no framing, no referrer. Shared files render in a sandbox with no scripts
Privacy
Starlings keeps the text of a call and the minimum about each person.
- Speech
- The host's Mac or iPhone transcribes it in memory and discards the audio as it goes. Only finished text leaves
- Notes
- A model writes them from the transcript text. The model providers do not train on it
- Who sees notes
- People who were in the call, inside Starlings. Starlings never emails a transcript
- Where
- Cloudflare. Direct messages are stored only in the EU
- Logs
- Never hold a token, a transcript, a message, an email address, or a lobby secret
The building blocks
Starlings is the app. Records, documents and the vault are each a service of their own, with its own store and its own key.
- One sign-in
- You sign in to Starlings. Starlings confirms who you are to each service. The service gives your device its own key. Starlings never keeps it
- Direct
- After that, your Mac or phone talks to the service itself. Each service enforces its own rules, once
- Self-describing
- Each service says what it holds and what you may do. Starlings shows only that
- Separate keys
- A key for Docs does not open Keep. Revoke one and the others still work
- Extensible
- A new service needs a store, a key, a package, and an entry point in Starlings. The tabs do not change
Technology
Media on LiveKit, transcription on the host's device, everything else on one Cloudflare Worker.
- Rooms
- A Durable Object holds each room: who is waiting, who is in, whose hand is up. LiveKit only ever sees a signed two-hour key
- Agent activity
- Admin shows handoffs, runtime acceptance or refusal, finalized replies observed by Starlings, and watchdog resets. Runtime model costs are not included
- Transcript pipeline
- The host device posts finished text to the Worker. A queue turns it into the transcript, the summary, and a record on the project, with retries and a dead letter an admin can replay. The Worker counts failures and daily model spend and sends an alert by email
- Services
- Records, Docs and Keep are separate services. Starlings reaches them over service bindings, never the public internet
- Contract
- One package of Zod schemas defines every wire shape. The Swift clients read the same fixtures, so the three clients cannot drift
- Ships
- Every push to main deploys the web app and the Worker through Workers Builds. Mac and iOS releases are notarized from a tag, and the Mac app checks for its own update
- Sign-in
- Google, your company’s accounts only. The Worker encrypts refresh tokens; the device keeps a session and its own device id
How Starlings is built.
Every service Starlings runs on, and what travels between them. Video goes directly between participants. The transcript goes to a Worker that never sees video. The full diagram, down to the bucket and the queue, is on feature status.
In the meeting
The devices a person is looking at.
- The hosting device
- One owner device opens the room, admits guests, and writes the transcript on its own hardware.
- The browser
- Guests join at
/room/<slug>with no account; a signed-in member gets the five surfaces too. It never hosts.
Media
Audio and video, end to end, never recorded.
- LiveKit CloudLiveKit
- Carries audio, video and screen between the people in the room. Nothing is recorded, and no stream is stored.
The control plane
One Cloudflare Worker. Text only — it never sees a stream.
- Meet control planeCloudflare
- One Worker: the door, the routes, and the SPA in front of them. It holds text and never media.
What it keeps
Room state, the words, the ledger, the files.
- Meet's own storeCloudflare
- The ledger, the tokens, the files and the job queue behind the Worker. Text and files — no media bucket.
The rest of the company
Services Meet reads and writes on a member's behalf.
- CoreEnvisioning
- The CRM. Subjects, tasks and interactions, read and written over HMAC — a meeting is filed on the project it belongs to.
- DocsEnvisioning
- Where documents and their comments live. Every read goes through Meet's Worker; the browser never holds a Docs token.
- KeepEnvisioning
- Where client credentials live. Meet reads what a member may see, over a service binding.
- Google WorkspaceGoogle
- Both halves of Google: who is one of us at sign-in, and the owner's day once they attach a calendar.
- The models
- Where the writing happens: the notes after a meeting, a forwarded mail read into events, suggested tasks and filing.
- AgentsVercel
- Peers with no device. Each is one row in the roster; a hand-off is signed, and an unanswered one is reset every five minutes.
- Connectors
- Every outside source that writes meetings into Meet. One card each on
/admin/connectors; the next one is a card, not a page. - PostmarkPostmark
- Outbound mail — invitations and the notices a guest gets — sent from
contact@envisioning.com.
What runs between them
- The hosting device ↔ LiveKit CloudAudio, video and screen · WebRTCNever: A recording. Nothing is written to disk, here or anywhere.
- The browser ↔ LiveKit CloudAudio, video and screen · WebRTCNever: A recording, and never a stream before the owner has admitted you.
- The hosting device ↔ Meet control planeTranscript text, summaries, admissions and room state · HTTPSNever: Audio, video, or the screen. The words leave; the sound does not.
- The browser ↔ Meet control planeThe knock, admission status, chat, and every workspace read · WebSocket
- Meet control plane → LiveKit CloudA media token, minted only once the owner has admitted the guest · HTTPSNever: Media. No stream passes through the Worker.
- Meet control plane ↔ Meet's own storeRoom state, the words, the ledger, the files, the jobs · Cloudflare binding
- Meet control plane ↔ CoreThe meeting, its notes and its tasks, filed on a subject · HTTPS
- Meet control plane ↔ DocsDocuments and comments, on the member's behalf · Cloudflare bindingNever: A Docs token into the browser. The Worker keeps its own, per owner.
- Meet control plane ↔ Google WorkspaceThe owner's day, and the meetings scheduled from Meet · HTTPS
- Connectors ↔ Meet control planeMeetings from outside sources — a webhook in, a paced job pulling history · HTTPS
- Meet control plane ↔ The modelsTranscript text to write the notes from, and a mail to read into events · HTTPSNever: Audio. A model reads the words the device wrote, never the sound.
- Agents ↔ Meet control planeA signed hand-off out, the agent's answer back · HTTPSNever: A seat in the room. An agent has no device and no media.
- Meet control plane ↔ KeepThe credentials a member may see · Cloudflare binding