Meetily: a local-first open-source AI meeting assistant

Meetily is an AI meeting assistant focused on privacy and local processing. It captures meeting audio on your machine, transcribes it in real time, and then uses AI to generate meeting summaries.

The problem is practical: meeting audio and transcripts often contain customer data, code, financial details, medical or legal information, and internal decisions. Meetily keeps transcription, storage, and optionally summarization closer to your own device or infrastructure.

What Meetily is

Meetily describes itself as a privacy-first AI meeting assistant with real-time transcription, summaries, local processing, and self-hosting. The repository is MIT licensed, mainly written in Rust, and uses Tauri plus Next.js for the desktop app.

It mainly does four things:

• captures microphone and system audio;
• runs local speech-to-text with Whisper or Parakeet;
• stores meeting metadata, transcripts, and summaries;
• generates minutes with Ollama, local models, or other LLM providers.

It supports macOS, Windows, and Linux. Some README links still use the old meeting-minutes repository name, so prefer the current GitHub page and official site when downloading.

Who it is for

Meetily fits users who do not want recordings or transcripts to leave the machine, teams replacing cloud meeting bots, organizations with compliance or confidentiality requirements, users who want Ollama or an internal OpenAI-compatible endpoint, and developers studying a Tauri + Rust + Next.js local AI app.

If you only meet occasionally and do not care about cloud upload, SaaS tools are easier. Meetily is about control, not zero setup.

Main features

Local-first

Transcription models, recordings, transcripts, and summaries can stay on the local machine. For professional teams, that makes the data boundary easier to explain.

Real-time transcription

Meetily can generate transcripts while a meeting is running. The README mentions Whisper and Parakeet models and emphasizes that cloud transcription is not required.

Parakeet is attractive for speed; Whisper has a broader ecosystem and more references. The right choice depends on OS, GPU, language, and accuracy needs.

AI summaries

Meetily can send transcripts to an LLM for summaries. Listed providers include:

• Ollama, for local-first use;
• Claude;
• Groq;
• OpenRouter;
• OpenAI;
• custom OpenAI-compatible endpoints.

For maximum locality, start with Ollama. If your organization has a model gateway, use the OpenAI-compatible endpoint path.

Audio mixing

The README mentions microphone plus system audio capture, audio mixing, ducking, and clipping prevention. This matters because recording only the microphone often misses other speakers, while recording only system audio may miss your own voice.

Import and re-transcription

Import & Enhance can import existing audio files, create transcripts, and re-transcribe meetings with a different model or language. This is useful for old recordings or important meetings that deserve a more accurate rerun.

Rough architecture

Meetily is a Tauri desktop app:

• frontend: Next.js for meeting management, transcript display, and settings;
• backend: Rust Core exposed through Tauri commands;
• Audio Engine: microphone and system audio capture;
• Transcription Engine: local speech-to-text models;
• Database: local SQLite for metadata, transcripts, and summaries;
• Summary Engine: Ollama or another LLM provider.

The tradeoff is familiar: the desktop app stays relatively light, but building from source means dealing with Node.js, Rust, Tauri, system audio permissions, model dependencies, and GPU acceleration.

Installation

Normal users should download a release package.

Windows

Download the latest x64-setup.exe and run the installer.

The README still points to:

1

https://github.com/Zackriya-Solutions/meeting-minutes/releases/latest

If that changes, start from:

1
2

https://github.com/Zackriya-Solutions/meetily
https://meetily.ai

macOS

Download the .dmg, for example:

1

meetily_0.4.0_aarch64.dmg

Install it like a normal macOS app:

1. open the .dmg;
2. drag Meetily to Applications;
3. launch it from Applications.

Apple Silicon machines are a good fit for local AI because unified memory and Metal acceleration help the local-model experience.

Linux

Linux mainly uses source builds. The README quick start is:

1
2
3
4

git clone https://github.com/Zackriya-Solutions/meeting-minutes
cd meeting-minutes/frontend
pnpm install
./build-gpu.sh

The current repository is:

1

git clone https://github.com/Zackriya-Solutions/meetily

If old commands redirect or directory names differ, confirm the current build script location first.

Building from source

docs/BUILDING.md covers Linux, macOS, and Windows.

Linux dependencies

Ubuntu/Debian:

1
2

sudo apt update
sudo apt install build-essential cmake git

Fedora/RHEL:

1

sudo dnf install gcc-c++ cmake git

Arch Linux:

1

sudo pacman -S base-devel cmake git

Development and production builds:

1
2

./dev-gpu.sh
./build-gpu.sh

macOS build

Install Homebrew dependencies:

1

brew install cmake node pnpm

Then run:

1
2

pnpm tauri:dev
pnpm tauri:build

The docs say macOS uses Metal GPU acceleration by default.

Windows build

Windows needs Node.js, Rust, Visual Studio Build Tools with the Desktop development with C++ workload, and CMake.

1
2

pnpm tauri:dev
pnpm tauri:build

The docs describe Windows as CPU-only by default. For GPU acceleration, see docs/GPU_ACCELERATION.md.

Understanding GPU acceleration

The Linux scripts try to detect GPU support:

A display driver is not enough. For CUDA, at least verify:

1
2

nvidia-smi
nvcc --version

You can force a backend with TAURI_GPU_FEATURE:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

TAURI_GPU_FEATURE=cuda ./dev-gpu.sh
TAURI_GPU_FEATURE=cuda ./build-gpu.sh

TAURI_GPU_FEATURE=vulkan ./dev-gpu.sh
TAURI_GPU_FEATURE=vulkan ./build-gpu.sh

TAURI_GPU_FEATURE=hipblas ./dev-gpu.sh
TAURI_GPU_FEATURE=hipblas ./build-gpu.sh

TAURI_GPU_FEATURE="" ./dev-gpu.sh
TAURI_GPU_FEATURE="" ./build-gpu.sh

Real-time transcription depends heavily on CPU/GPU, memory, model size, and audio length. Test with a short recording first.

Choosing a summary model

Transcription and summarization are separate. Speech-to-text cares about accuracy, language support, and speed; summarization cares about turning a long transcript into decisions, action items, and useful minutes.

For privacy-first use:

• transcription: local Whisper or Parakeet;
• summary: Ollama local model;
• storage: local SQLite;
• network: avoid cloud providers where possible.

For better summaries, keep transcription local but send transcripts to Claude, OpenRouter, Groq, OpenAI, or an internal OpenAI-compatible endpoint. That changes the privacy boundary because the transcript leaves the machine.

Community Edition vs PRO

The README says Meetily Community Edition will remain free and open source. Meetily PRO targets professional users and teams with higher transcription accuracy, custom summary templates, advanced export, automatic meeting detection, self-hosted deployment, and team features.

Community Edition is best for individuals, local-first use, open-source use, and customization. PRO is for teams that need stronger workflow, export, and deployment management.

Things to watch

Recording meetings can have legal and company-policy requirements. Confirm notice and consent rules before using any recording tool.

Local-first also does not mean zero risk. Once recordings and summaries are stored locally, think about disk encryption, backups, access control, and device loss.

AI summaries are not the meeting record. Keep the original transcript for important meetings and review final minutes manually.

Some README links still contain meeting-minutes; use the current repository and official site when release names or directories differ.

Deploy a Local Meeting Assistant on a NAS

The AI ​​meeting recording assistant is most suitable for local deployment scenarios where the team has a large number of meeting recordings, interview audios, course screen recordings or customer communication records, but does not want all audio to be uploaded to a third-party cloud service. NAS is just right for this: it is always online, has hard disk space, can run Docker, and is also convenient for centralized storage of recording files.

This article is organized according to “Tutorials + Troubleshooting + FAQs”. The goal is to help you set up a local AI meeting recording process on the NAS: the audio is uploaded to the NAS, the service is converted into text, and then local or private LLM is used to generate summaries, action items, and to-do lists.

First confirm which type of assistant you want to deploy

There are roughly three routes to local AI conference minutes:

On NAS, it is recommended to start with “Transcription + Summary”. The complete platform has more functions, but the deployment complexity, database, permissions, backup and upgrade costs are also higher.

Hardware judgment before NAS deployment

Let’s first see if the NAS can handle transcription and summarization.

Minimum recommendations:

• 4GB memory allows for light testing.
• 8GB memory is more suitable for long-term operation.
• x86 NAS is more compatible than ARM NAS.
• Having a graphics card or GPU will be faster, but is not required.
• Hard disk space must be reserved for audio, transcribed text and model cache.

If your NAS performance is weak, you can use the “NAS storage + another computer inference” approach. The NAS is responsible for saving recordings and results, and the transcription service runs on a mini-host, desktop or GPU machine.

Recommended architecture

A practical local architecture can be designed like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Meeting recording
  ↓
NAS shared directory
  ↓
Docker service
  ↓
Whisper / faster-whisper transcription
  ↓
Ollama / OpenAI-compatible LLM summary
  ↓
Markdown / TXT / SRT / web results

The advantage of this structure is that the components are clear. If the transcription fails, check STT. If the digest fails, check LLM. If the file cannot be found, check the mounting directory.

Prepare catalog

First prepare several directories on the NAS:

1
2
3
4
5
6

/volume1/docker/meeting-ai/
├── config/
├── input/
├── output/
├── models/
└── logs/

use:

• input: Put the audio to be processed.
• output: Banished script, subtitles, summary.
• models: Put Whisper or other model cache.
• config: Put the configuration file.
• logs: Put the running log.

If you plan the directory first, troubleshooting will be much easier later.

Docker Compose Example

The images and parameters of different conference assistant projects are different, but the ideas are similar. Here is an example of a common structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

services:
  meeting-ai:
    image: your-meeting-assistant-image:latest
    container_name: meeting-ai
    restart: unless-stopped
    ports:
      - "7860:7860"
    volumes:
      - /volume1/docker/meeting-ai/input:/app/input
      - /volume1/docker/meeting-ai/output:/app/output
      - /volume1/docker/meeting-ai/models:/app/models
      - /volume1/docker/meeting-ai/config:/app/config
    environment:
      - TZ=Asia/Shanghai
      - WHISPER_MODEL=small
      - LLM_BASE_URL=http://ollama:11434
      - LLM_MODEL=qwen2.5:7b

If your NAS uses Synology Container Manager, Feiniu Docker, TrueNAS Apps or Portainer, the core is the same: image, port, directory mounting, environment variables.

Should Ollama also be deployed on NAS?

If the NAS performance is sufficient, Ollama can also be deployed on the NAS; if the performance is weak, it is recommended to put Ollama on a stronger machine.

Advantages of NAS native deployment:

-The data is all on the intranet.

• Simple configuration.
• Long term online.

shortcoming:

• Large model inference is slow.
• Memory is easily stretched.
• Transcribe and summarize at the same time.

A more stable solution is:

1
2

NAS: storage, Web UI, task queue
Mini PC or desktop: Ollama / GPU inference

Then point LLM_BASE_URL to the intranet address of that machine in the configuration.

How to deal with audio formats

Common conference recording formats include mp3, m4a, wav, and mp4. In order to reduce problems, it is recommended to uniformly convert to wav or standard mp3.

You can use ffmpeg to preprocess:

1

ffmpeg -i meeting.m4a -ar 16000 -ac 1 meeting.wav

meaning:

• -ar 16000: Convert sampling rate to 16k.
• -ac 1: Convert to mono.
• meeting.wav: Output for use by the transcription model.

If the original file is a video, you can also extract only the audio:

1

ffmpeg -i meeting.mp4 -vn -ar 16000 -ac 1 meeting.wav

How to choose a transcription model

Common choices are Whisper or faster-whisper. Larger models generally have better accuracy, but also higher speed and memory usage.

The Chinese conference is recommended to start from small. If the transcription quality is not good enough, try medium again. Do not use the largest model at the beginning, otherwise it will be difficult to determine whether the model is slow, the CPU is slow, or the service is stuck when troubleshooting.

Summary word suggestions

Once the transcription is complete, LLM can be used to generate structured minutes. Prompt words can be fixed into templates:

1
2
3
4
5
6
7
8

Generate Chinese meeting minutes from the transcript below.

Requirements:
1. Extract the meeting topic.
2. List the key discussions as bullet points.
3. Separately list action items, including owner, task, and deadline; if the owner or time is unclear, write "not specified".
4. Preserve important numbers, project names, and risks.
5. Do not invent information that is not in the transcript.

For local models, if the verbatim manuscript is too long, it should be summarized in segments and then summarized. Don’t cram several hours of meetings into one sitting.

Common errors: Container startup fails

Typical performance:

1
2
3

container exited
permission denied
exec format error

Common reasons:

• Mirroring architecture is not supported by your NAS CPU.
• Insufficient permissions on the mounting directory.
• Environment variables are missing.
• The port is occupied.
• The configuration file path is written incorrectly.

Check order:

1. Look at the container log.
2. Confirm that the image supports amd64 or arm64.
3. Check directory permissions.
4. Change to an unoccupied port.
5. Start with the minimum configuration first, and then gradually add models and LLM.

exec format error It is likely that the image architecture does not match.

Common error: No response after uploading audio

Possible reasons:

• The upload directory is not mounted inside the container.
• The service only scans specific suffixes.
• The file was scanned by the task before it was finished writing.
• The file name contains special characters.
• The background task queue is stuck.

It is recommended to test with a simple file name first:

1

meeting-test.mp3

Do not use long file names containing spaces, Chinese brackets, or special symbols from the beginning. After running through, test the real file again.

Common error: Transcription is very slow

Slow translation on NAS is common and may not necessarily be due to a faulty deployment.

Optimization method:

• Change to a smaller Whisper model.
• Convert the audio to 16k mono first.
• Cut long meetings into segments.
• Avoid both transcribe and LLM summarization filling up the CPU.
• Put the transcription tasks on more powerful machines, and NAS only does storage.

It’s not surprising on a low-power NAS if an hour-long meeting takes dozens of minutes. The key is to be able to finish the run stably.

Common errors: Transcription garbled characters or language recognition errors

Possible reasons:

• Automatic language detection failed.
• The audio is too noisy.
• Abnormal sampling rate or audio channel.
• The model is too small.
• The mixed Chinese and English scenes are too complicated.

Processing method:

• Explicitly specify the language as Chinese.
• First use ffmpeg to unify the audio format.
• Change to small or medium model.
• Try to improve the recording quality for multi-person meetings.
• Keep the original audio of important meetings for easy review.

Common error: Ollama connection failed

Typical performance:

1
2
3

connection refused
failed to connect to Ollama
model not found

Troubleshooting:

• Is Ollama running?
• LLM_BASE_URL is written correctly.
• Whether the localhost accessed in the container points to itself, not the NAS or host.
• Is the model already ollama pull.
• Whether the NAS firewall allows intranet access.

If the conference assistant is in a container, http://localhost:11434 usually refers to the container itself. When Ollama is on the host or another machine, the corresponding intranet IP must be written.

Common errors: poor summary quality

Poor summary quality is usually not a deployment issue but an input and model issue.

Common reasons:

• There are too many typos in the verbatim manuscript.
• The session is too long and one input is out of context.
• The local model is too small.
• There is no constraint output format for prompt words.
• The action items are not clearly stated in the original text.

Improvement method:

• Start with a 10 to 20 minute segmented summary.
• Make a summary at the end.
• Require the model to be marked “uncertain”.
• Use fixed fields for action items.
• Manual review of important meetings.

A local model can save costs, but don’t expect it to automatically complete information that wasn’t said in the meeting.

Frequently Asked Questions: Not enough NAS memory

If the NAS has small memory, it is recommended to:

• Select base or small as the transcription model.
• Don’t run big LLM on NAS.
• Limit concurrent tasks to 1.
• Close unnecessary containers.
• Place the model cache on a volume with sufficient space.

If OOM occurs frequently, it means that this NAS is more suitable for storage and not suitable for use as the main inference machine.

What to pay attention to about privacy and permissions

Meeting recordings often contain sensitive information, and on-premises deployments cannot ignore permissions.

suggestion:

• Set access permissions for the input/output directory.
• Do not expose the Web UI directly to the public network.
• Use VPN or reverse proxy authentication for external network access.
• Regularly clean temporary audio and intermediate files.
• Important meeting results retain the manual review process.
• If you connect to cloud LLM, you need to know which texts will be uploaded.

“Deployed on NAS” does not automatically equal security, permissions and network boundaries still need to be managed by yourself.

Recommended implementation process

The first deployment can be done in this order:

1. Create input, output, models, and config directories on the NAS.
2. Use Docker to run the conference assistant service.
3. Upload a 1-minute test audio.
4. Confirm the transcribed link using the tiny or base model.
5. Change to the small model to test the Chinese accuracy.
6. Connect to Ollama or OpenAI compatible LLM for summary.
7. Configure regular cleanup and permission control.
8. Process the real meeting recording again.

Don’t start with a two-hour session recording test. Use short audio to verify the link first, which saves time and facilitates troubleshooting.

FAQ

Is it possible to perform complete local offline transcription on NAS?

Yes, but only if the transliteration model, digest model, and all dependencies are local. If the abstract calls the cloud LLM, it is not completely offline. It is recommended to clearly distinguish the sources of STT and LLM in the configuration.

Can Synology, Feiniu, and TrueNAS be deployed?

As long as you can run Docker or similar container services, in theory it’s OK. The differences are mainly in paths, permissions, port mappings and CPU architecture.

Is ARM NAS suitable for running?

Lightweight transcription can be run, but image compatibility and performance must be confirmed in advance. Many AI images give priority to amd64 by default, and ARM devices are prone to architecture mismatches.

Does the meeting recording assistant require a GPU?

uncertain. CPU can also transwrite, but it is slower. Acceptable for short audio and low-frequency use; GPU machines are recommended for a large number of meetings or long videos.

In what format should the output be saved?

It is recommended to save at least txt or md verbatim, srt subtitles, and md abstract. Markdown is best for subsequent searching, archiving, and human editing.

Can it automatically identify different speakers?

This depends on whether the tool you are using supports speaker diarization. It is more complex and resource intensive than ordinary transcription. The important meeting recommended that “speaker recognition” be regarded as an enhanced feature and not a required feature in the first version.

Can I directly monitor the meeting recording folder automatically?

Yes, but please note that the file writing is completed before processing. Otherwise, the task will start to be transcribed before the recording is uploaded, and it is easy to fail. You can use the temporary directory to add and move it after completion.

Can the local model summary be directly used as a formal record?

Not recommended. AI summaries are good as first drafts, especially if action items and responsibilities require human review. Be even more cautious about client meetings, legal meetings, and important decision-making meetings.

Summary

Meetily matters because it moves the meeting AI pipeline back toward the local machine: capture, transcription, storage, and optionally summarization. For privacy- and compliance-sensitive teams, that is more controllable than a convenient but opaque cloud bot.

It is not a no-setup tool. Start with a release package to test transcription and summary quality, then decide whether source builds, GPU tuning, or internal model integration are worth the engineering time.