How to Judge Meetily's Privacy-First Architecture
Meetily’s answer to the privacy question is neither an unconditional yes nor a marketing-only promise. In the current supported desktop application, capture, speech recognition, local storage, and selected summary paths can remain on the user’s infrastructure. This final synthesis reconnects those capabilities with the provider, telemetry, platform, package, and failure choices that surround them. The reader can use the result to decide when Meetily’s configurable locality is a genuine advantage, what must be verified, and where the repository cannot provide certainty.
The useful unit of judgment is a data path. Ask what kind of material is moving, who owns the state at that point, what triggers the next transition, and whether the destination is local, user-controlled, internally managed, or external. That model is more precise than asking whether an application is simply “private.”
A local workflow with multiple owners
Meetily’s core workflow starts inside a Tauri desktop application. The Next.js interface sends commands to a Rust core, and the core manages native audio, model lifecycles, files, database state, and summary work. That placement gives the local application direct control over the first transformations of a meeting. It also makes the desktop host part of the security boundary: the operating system, account, permissions, local files, and installed package all matter.
The first material is raw sound. Microphone and system-audio streams are prepared locally, aligned, and mixed. The application keeps a mixed recording path for preserving the session and creates a VAD-filtered path for speech recognition. VAD, or voice-activity detection, decides which portions are likely to be speech and groups them into timestamped segments. Those segments are handed to local Whisper or Parakeet engines in the supported recording path.
That is a real local capability, not merely a local user interface over a remote speech API. The original audio need not be sent to a Meetily server for the current local transcription path. But the capability has conditions. The operating system must expose a microphone and, when needed, a usable system-audio source. Permissions must allow actual callbacks and samples, not just the creation of a nominal stream or tap. A model must be present and loadable. The build must include a compatible native runtime; acceleration is an optional build and runtime choice rather than a prerequisite for CPU execution. If one of those transitions fails, locality does not rescue the recording.
The next material is the transcript. Meetily’s local database stores meeting metadata, transcript rows, configuration, summary-process state, and transcript input. The meeting folder can store metadata JSON, structured transcript segments, and—when auto-save is enabled—the mixed audio assembled from incremental checkpoints. Recording-relative timestamps link transcript text to the audio. This gives the user a local and inspectable record rather than an opaque provider-side object.
The two storage layers are important to the final judgment. SQLite supports transactions, search, pagination, and coherent updates to related records. User-visible files support playback, recovery, import, retranscription, and external retention handling. Atomic JSON replacement reduces the chance of exposing a half-written document. Checkpoints reduce the amount of live audio held only in memory and can be merged after an interruption. These mechanisms make local ownership practical, but they do not make every database row and file commit as one transaction.
The same distinction applies to deletion. The database deletion path removes meeting-related rows in a controlled transaction. The examined evidence does not establish that deleting the database record recursively removes every audio file, metadata file, checkpoint, export, backup, or operating-system snapshot. A person or organization that has a strict retention rule must inspect both the database and the file layer. Local storage increases visibility and control; it does not eliminate the need for a retention process.
The summary is a separate transformation. Meetily can send the stored transcript to a local Ollama endpoint, invoke its built-in local AI sidecar, use a named cloud provider, or call a custom OpenAI-compatible endpoint. This means the application can preserve local audio and local speech recognition while moving transcript text to a remote summary service. It also means that a user can keep summary inference local, but only by accepting the local model’s memory, compute, setup, and maintenance costs.
The built-in sidecar makes the local choice particularly clear. A bundled helper process loads a local GGUF model, receives a JSON request over local standard input/output, generates the answer, and can be shut down after idle time or cancellation. The summary service does not need a public API request for that inference. Yet the model file had to be acquired first, and the current catalog points to external hosts for those downloads. “Local model” describes where the model runs after acquisition; it does not describe the entire artifact lifecycle.
Other network edges are separate again. Optional analytics is off by default in the current interface and is initialized only after opt-in. When enabled, the implementation sends product and performance events to PostHog. It removes explicitly flagged meeting names, file names, paths, folders, source paths, device names, and similar fields, and meeting-end reporting uses broad device categories rather than the original device names. The repository tests those exclusions. This is narrower than sending a transcript, but it is still an external service path.
Updates, profile or licensing operations, and packaged runtimes add further edges. The application configuration points the updater at a GitHub release manifest. Build configuration bundles or provisions components such as the sidecar, FFmpeg, and ONNX Runtime. The application also receives broad file-system capabilities appropriate to a desktop tool that reads audio, writes meetings, manages models, and runs native helpers. Those choices do not negate local processing. They define the larger trust surface that must be included in any serious evaluation.