User Authentication Methods in Meetily: Local API Keys and Optional Bearer Tokens

Meetily does not implement traditional user authentication such as passwords, OAuth, or user accounts; instead, it stores optional LLM provider API keys and a generic bearer token locally for external service calls.

The open-source Zackriya-Solutions/meetily repository is built as a privacy-first, locally-run desktop application. Understanding the user authentication methods in Meetily requires examining its Rust-based Tauri backend, where all credential handling is designed to keep data on the user's machine without remote login flows.

No Built-In User Login or Account System

Meetily never contacts an external authentication service for user login. All UI state is managed locally via React contexts and Tauri commands, with no credential validation flow in the core application logic. The SidebarProvider and ConfigContext contexts, along with standard Tauri commands, do not reference any username or password validation.

LLM Provider API Key Authentication

Since Meetily generates AI summaries and transcripts, it integrates with multiple LLM providers. Because the app has no centralized account system, it authenticates to these services using per-provider API keys stored in a local settings database.

Local Storage via the Settings Repository

API keys for providers such as OpenAI, Anthropic, Groq, and custom OpenAI-compatible endpoints are persisted in the local database through the setting repository. The setting_repo.save_api_key(provider_name, api_key).await? pattern stores credentials on disk without transmitting them to a Meetily backend.

You can see the storage implementation in frontend/src-tauri/src/database/repositories/setting.rs around line 75, where keys are written to the local store alongside other application preferences.

Runtime Retrieval and Provider Usage

At runtime, the summary module and provider clients retrieve these keys from the settings repository. For example, frontend/src-tauri/src/summary/mod.rs at line 18 documents the optional API key pattern, while provider-specific files such as frontend/src-tauri/src/openai/openai.rs (line 99), frontend/src-tauri/src/anthropic/anthropic.rs (line 69), and frontend/src-tauri/src/groq/groq.rs (line 67) read the stored key and attach it to outgoing HTTP requests.

This design means Ollama users do not need an API key at all, because the model runs entirely on the local machine.

// Example of storing an LLM API key (OpenAI) via the settings repository
let api_key = Some("sk‑…".to_string());
setting_repo.save_api_key(provider_name, api_key).await?;

Optional Bearer Token for Custom Backends

In addition to provider keys, Meetily supports an optional generic authentication token for users who run a custom backend server. This token is not required for standard desktop usage, but it enables authenticated communication when a self-hosted endpoint expects authorization.

Token Retrieval from the Tauri Store

The get_auth_token function in frontend/src-tauri/src/api/api.rs at line 208 reads the token from Tauri’s encrypted store under the exact key authToken. The function signature is async fn get_auth_token<R: Runtime>(app: &AppHandle<R>) -> Option<String>, returning None when no token is configured.

// Retrieve an optional auth token from the encrypted Tauri store
async fn get_auth_token<R: Runtime>(app: &AppHandle<R>) -> Option<String> {
    let store = app.state::<Store>();
    match store.get("authToken") {
        Ok(Some(token)) => {
            // Truncate for log safety
            let truncated = if token.len() > 6 {
                format!("{}***", &token[..6])
            } else {
                token.clone()
            };
            log_info!("Found auth token: {}", truncated);
            Some(token)
        }
        _ => {
            log_warn!("No auth token found in store");
            None
        }
    }
}

Attaching the Token to Outgoing Requests

The make_api_request function in the same file (lines 260-267) conditionally adds the token as a Bearer header. If auth_token is Some, the request builder sets the authorization header before the HTTP call executes.

// Adding the token (if any) to a generic request
let mut request = reqwest::Client::new()
    .post(url)
    .json(&payload);

if let Some(token) = auth_token {
    log_info!("Adding authorization header");
    request = request.bearer_auth(token);
}

Summary

• Meetily has no built-in user login, sign-up, OAuth, or password system according to the Zackriya-Solutions/meetily source code.
• LLM provider API keys are stored locally in the settings database and passed to client code at runtime.
• An optional generic authToken can be placed in Tauri’s encrypted store to enable Bearer authentication against custom backends.
• All credential handling is local-only, aligning with the application’s privacy-first architecture.

Frequently Asked Questions

Does Meetily require a user account to function?

No. Meetily is designed as a locally-run desktop application that never contacts an external authentication service for user login. All recordings, transcripts, and summaries are stored and processed on the user's machine without any remote account creation step.

How are API keys stored in Meetily?

API keys are stored in the local settings database through the setting repository in frontend/src-tauri/src/database/repositories/setting.rs. They are persisted on disk alongside other application preferences and are only retrieved when the app needs to call an external LLM provider.

Can I use Meetily without sharing API keys with a remote server?

Yes. If you use Ollama, which runs entirely on your local machine, you do not need to provide an API key. The only time a key is required is when you choose to use cloud-based providers such as OpenAI, Anthropic, or Groq for summary generation.

What is the optional auth token used for in Meetily?

The optional authToken is read from Tauri’s encrypted store and added as a Bearer header to outgoing HTTP requests through make_api_request in frontend/src-tauri/src/api/api.rs. It exists solely to support users who run a custom backend that expects bearer token authentication, and it is not used by default.

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