Main Components of the Meetily Architecture: Frontend, Rust Core, and LLM Layers

Meetily combines a Next.js and React frontend, a Rust backend core that handles audio capture and local transcription, and optional external LLM services for summarization, all bound together by Tauri commands and events.

Meetily, from the Zackriya-Solutions/meetily repository, is an open-source meeting assistant built with a privacy-first, offline-capable design. The main components of the Meetily architecture divide into three logical layers that communicate through Tauri commands and events. Understanding these layers is essential for developers who want to customize the audio pipeline, extend the UI, or plug in new summarization providers.

Meetily Frontend Architecture: Next.js and React UI

The user-facing layer is a Next.js and React web view rendered inside a Tauri window. It manages all interactions—including starting recordings, displaying live transcripts, and browsing meeting history—without processing audio directly. Key files include frontend/src/app/page.tsx for the main recording interface, frontend/src/components/Sidebar/SidebarProvider.tsx for global React state, and frontend/src-tauri/src/utils.rs for UI helper utilities.

The frontend drives the Rust backend by invoking Tauri commands and listening for real-time events. To start a capture session, the UI calls the start_recording_with_devices_and_meeting command registered in frontend/src-tauri/src/lib.rs:

// frontend/src/app/page.tsx (simplified)
await invoke('start_recording_with_devices_and_meeting', {
  mic_device_name: selectedMic,
  system_device_name: selectedSystem,
  meeting_name: currentMeeting,
});

Live transcripts stream to the UI through the transcript-update event. The frontend subscribes via Tauri’s listen API and appends chunks to React state as they arrive:

import { listen } from '@tauri-apps/api/event';

await listen<{
  text: string;
  timestamp: number;
}>('transcript-update', event => {
  setTranscript(prev => [...prev, { ...event.payload }]);
});

For device selection, the UI fetches available hardware through the get_audio_devices command:

const devices = await invoke<AudioDevice[]>('get_audio_devices');

Meetily Backend Architecture: Rust Core and Command Registry

The Rust backend is the heart of the application and lives entirely under frontend/src-tauri/src/. It exposes functionality to the UI via #[tauri::command] functions and manages audio capture, speech-to-text, summary generation, persistence, and system integration.

Application Bootstrap in lib.rs

The entry point is frontend/src-tauri/src/lib.rs. Its run() function constructs the Tauri application, registers every command, initializes the system tray, and starts the Whisper engine, Parakeet engine, and builtin-AI summary sidecar:

// frontend/src-tauri/src/lib.rs
builder
    .plugin(tauri_plugin_notification::init())
    .manage(whisper_engine::parallel_commands::ParallelProcessorState::new())
    .setup(|_app| { /* subsystem initialization */ })

This file acts as the central registry, wiring together the audio, transcription, summarization, and notification subsystems so the frontend can call them by name.

Audio Capture and Processing Pipeline

The frontend/src-tauri/src/audio/ module handles the entire audio path. It discovers microphones and system devices, creates a ring-buffer mixer in frontend/src-tauri/src/audio/pipeline.rs, runs Voice Activity Detection (VAD) to filter non-speech, and streams valid chunks to the transcription engine.

Platform-specific capture implementations live under frontend/src-tauri/src/audio/devices/platform/:

• macOS uses ScreenCaptureKit (macos.rs)
• Windows uses WASAPI
• Linux uses PulseAudio

This abstraction keeps the rest of the stack OS-agnostic while the core pipeline handles mixing and level monitoring uniformly.

Speech-to-Text Transcription Engines

Meetily supports two local transcription backends for offline speech recognition. The Whisper engine in frontend/src-tauri/src/whisper_engine/whisper_engine.rs loads Whisper-cpp models and manages parallel processing. The Parakeet engine in frontend/src-tauri/src/audio/transcription/parakeet_provider.rs provides an alternative higher-accuracy inference path.

When a new text chunk is ready, the backend emits a transcript-update event—commonly triggered by whisper_engine::commands::whisper_transcribe_audio—that the frontend consumes in real time.

AI Summary Generation and LLM Routing

When the user requests a summary, the frontend invokes api_process_transcript defined in frontend/src-tauri/src/summary/commands.rs. This command routes the transcript to the selected provider.

Available backends include:

• Builtin AI sidecar: A local llama-helper process managed by frontend/src-tauri/src/summary/summary_engine/mod.rs for fully on-device inference
• External APIs: Thin wrapper modules under frontend/src-tauri/src/ollama/, openai/, anthropic/, groq/, and openrouter/ provide uniform access to cloud or self-hosted LLMs

A typical frontend call looks like this:

await invoke('api_process_transcript', {
  meeting_id: meetingId,
  model: 'builtin', // or 'openai', 'ollama', etc.
});

The generated summary is streamed back to the UI and stored in the local SQLite database.

Local SQLite Database and Persistence

All meetings, recordings, transcripts, and user preferences are stored in a SQLite database managed by frontend/src-tauri/src/database/. The frontend/src-tauri/src/database/setup.rs file creates the database on first launch, applies migrations, and places the file in the platform-specific app-data folder. As implemented in the Meetily source code, this guarantees that data remains local unless the user explicitly opts into an external LLM call.

Notifications and User Analytics

The frontend/src-tauri/src/notifications/ module wraps tauri_plugin_notification to display system-tray alerts and supports Do-Not-Disturb mode. Usage events are recorded only under user consent by the frontend/src-tauri/src/analytics/ module. Both systems are toggled from the UI and invoked through dedicated Rust commands such as those in frontend/src-tauri/src/notifications/commands.rs.

Meetily External Services Architecture: LLM Providers

Although Meetily is designed to operate offline, it can optionally reach out to external LLM services for summarization. According to the Zackriya-Solutions/meetily source code, the architecture treats these providers as pluggable backends. Whether the user selects a local Ollama instance or a remote OpenAI API, the request flows through the same summary::commands::api_process_transcript entry point before being dispatched to the appropriate client wrapper.

Cross-Platform Audio Abstraction in Meetily

Professional audio workflows require platform-specific backends, but Meetily avoids duplicating business logic by isolating OS differences under frontend/src-tauri/src/audio/devices/platform/. The macos.rs file implements ScreenCaptureKit capture, while equivalent modules target WASAPI on Windows and PulseAudio on Linux. The core audio API abstracts these details so that the VAD, mixing, and transcription layers remain unchanged across platforms.

Summary

• Meetily uses a three-layer architecture: a Next.js/React frontend, a Rust core backend, and optional external LLM services.
• The frontend controls recordings and displays transcripts by invoking Tauri commands like start_recording_with_devices_and_meeting and listening for transcript-update events.
• The Rust backend in frontend/src-tauri/src/ manages device discovery, ring-buffer mixing, VAD filtering, Whisper/Parakeet transcription, SQLite persistence, and system notifications.
• Summary generation is handled by summary::commands::api_process_transcript, which can target a local sidecar or external APIs including Ollama, OpenAI, Anthropic, Groq, and OpenRouter.
• Cross-platform audio support is achieved through pluggable device backends for macOS, Windows, and Linux without altering the core audio pipeline.

Frequently Asked Questions

What is the entry point for the Meetily Rust backend?

The entry point is frontend/src-tauri/src/lib.rs. Its run() function constructs the Tauri app, registers all commands via #[tauri::command], initializes the Whisper and Parakeet engines, and sets up the builtin-AI summary sidecar before the UI window appears.

How does Meetily stream live transcripts to the UI?

The Rust backend emits a transcript-update event each time the Whisper or Parakeet engine produces a new text chunk. The frontend listens through Tauri’s listen API and updates React state immediately, creating a real-time feed without polling the backend.

Where does Meetily store meeting recordings and transcripts?

All data is stored in a local SQLite database initialized by frontend/src-tauri/src/database/setup.rs. The database lives in the platform-specific application data directory, ensuring that transcripts and summaries remain on the user's device unless an optional external LLM is used.

Can Meetily transcribe and summarize meetings without an internet connection?

Yes. Meetily ships with local Whisper and Parakeet engines for speech-to-text and a builtin llama-helper sidecar for summarization. External LLM providers are entirely optional, so transcription, storage, and local summarization all function offline.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}