Note Companion: an Obsidian plugin that files your notes and transcribes your meetings

The Inbox problem Note Companion was built around

Most note tools assume you will organize as you write. Note Companion assumes the opposite: you dump links, audio, meeting recordings and half-written fragments somewhere, and the cleanup never happens. The README names the audience directly, calling it best for "researchers, students, meeting-heavy workflows, and anyone with an 'Inbox' full of unprocessed notes."

The plugin has three jobs that reinforce each other. It reads a capture and proposes a folder, tags, a title and formatting. It turns audio, video and YouTube links into transcripts and structured notes. And it answers questions about your vault using context you point at with @mentions for files, folders and tags. The rename from File Organizer 2000 reflects that the organizer is now one feature among several rather than the whole product.

If your vault is already tidy and you never record meetings, the value proposition mostly evaporates. The plugin is aimed at the gap between capture and structure.

How the plugin, the backend and your provider keys fit together

Note Companion is a monorepo, not a single plugin bundle. The repository root holds a pnpm workspace with packages/, a Dockerfile, a docker-compose.yml, a Next.js web package referenced in the Dockerfile, and the Obsidian plugin under packages/plugin. The build script in package.json runs esbuild against packages/plugin/esbuild.config.mjs, so the plugin is bundled separately from the server.

The split matters because of where credentials live. The Obsidian plugin has no field for an OpenAI, Claude or Gemini key. Those keys are set on the backend. In cloud mode the plugin only holds a licence key, pasted into Settings, Note Companion, General. In self-hosted mode the plugin holds a Server URL and the keys sit in the server's .env.

That means every AI call leaves the plugin, goes to a backend over HTTP, and comes back. The README's troubleshooting section tells you to confirm the backend is reachable with curl http://localhost:3000/api/health, which is the clearest statement of the data flow in the documentation: plugin to server, server to provider. Model selection is server-side too. docker-compose.yml lists MODEL_PROVIDER with the options openai, anthropic, google, groq, mistral and deepseek, plus MODEL_NAME, and separate variables for MODEL_VISION, MODEL_TEXT, MODEL_CLASSIFY, MODEL_TAGGING and MODEL_FOLDERS if you want different models per task.

Installing the Note Companion Obsidian plugin and running a first test

The plugin installs the ordinary way. The README gives this path: Obsidian, Settings, Community plugins, Browse, search for "Note Companion", Install, then Enable. There is no manual file copy documented.

After enabling, open Settings, Note Companion. For cloud access you create an account at notecompanion.ai, copy the licence key from the web dashboard under API Keys, paste it into the General tab's License Key field and click Activate. The README is explicit that this field is for cloud access only and is not where provider keys go.

For self-hosting, the repository supplies a compose file. The image is jpfong/note-companion:latest and it maps port 3000.

services:
  app:
    image: jpfong/note-companion:latest
    ports:
      - "3000:3000"
    environment:
      - ENABLE_USER_MANAGEMENT=false
      - OPENAI_API_KEY=sk-...your_key_here...

ENABLE_USER_MANAGEMENT=false is what removes the licence requirement for a self-hosted instance. The compose file also shows commented-out lines for OPENAI_API_BASE, ANTHROPIC_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, DEEPSEEK_API_KEY and GOOGLE_VISION_API_KEY, and for MODEL_PROVIDER and MODEL_NAME. Uncomment only what you actually use.

Back in Obsidian, go to Settings, Note Companion, Advanced, enable Self-Hosting, and set Server URL to your backend, for example http://localhost:3000. Leave License Key empty or use a placeholder. Then run the README's quick test: open the Command Palette, choose Note Companion: Open Chat, and ask it to summarize a note and suggest tags. A response means the plugin reached the server and the server reached your provider.

Where Note Companion breaks, and who should not install it

The largest limitation is stated by the project itself: the Obsidian plugin is desktop-only. It is marked desktop-only in the plugin manifest, so Obsidian on iPhone, iPad and Android will not load it and may show it as unsupported. The README says the plugin is built and tested for desktop and that mobile is not tested or supported. A separate Note Companion mobile app exists in the repository for capture and cloud-backed workflows, but the README states development on it is on pause and that it is not a replacement for running the plugin inside mobile Obsidian. If mobile is your primary writing surface, this is the wrong tool today.

Transcription has its own ceiling. The troubleshooting section points at provider key validity, model availability and file size limits, and suggests splitting or compressing files larger than 25MB. That is a real constraint for long meeting recordings, and it pushes the problem back onto you.

Chat with local models is labelled experimental in the README, and the in-plugin Ollama path requires Catalyst access. The documented fallback is pointing the self-hosted backend at OPENAI_API_BASE=http://localhost:11434/v1. Even then, the troubleshooting list for a silent local model is CORS, network settings, a stopped server and firewall rules, which is a lot of surface area for a feature the project does not call stable.

The cloud path also has a privacy shape worth reading before you choose it. The README says files are processed through the API for AI analysis and that usage statistics are collected for billing and rate limits, while vault content is only processed when you explicitly use plugin features. Self-hosting with ENABLE_USER_MANAGEMENT=false is described as having no cloud usage tracking.

Note Companion compared with Obsidian's built-in plugins and plain Ollama

The obvious alternative is doing nothing beyond what ships with Obsidian. Obsidian has no built-in transcription or vault chat, so the honest comparison is manual work: you paste a transcript yourself, choose the folder yourself, add tags yourself. That costs no backend, no keys and no server, and it keeps everything local by default. Note Companion trades that manual effort for an HTTP dependency. The trade is only worth it if the capture-to-structure step is genuinely the bottleneck.

The second alternative is wiring a local model directly, for example running Ollama and calling it from a community chat plugin. Note Companion can use Ollama, but only through the backend: the documented route is OPENAI_API_BASE=http://localhost:11434/v1 on the self-hosted server. The difference in approach is that a direct chat plugin keeps one hop between editor and model, while Note Companion inserts a server that also owns transcription, classification, tagging and folder suggestions. You get more capability per capture and one more process to keep alive.

A third comparison is against hosted transcription and AI services used outside the editor. Those avoid the server entirely but put the organizing step back in your hands, which is the problem Note Companion exists to remove.

Maintenance, licence and what the repository does not answer

The last push to the default branch was on 2026-07-25, the same date as release 3.6.31. The two releases before it landed on 2026-07-04 and 2026-06-28, so the release cadence in the visible window is roughly monthly. The repository is not archived. That is a reasonable signal for a project of this shape, though the README does not document a support policy or a compatibility promise for future Obsidian versions.

The licence is MIT, which permits commercial and private use and modification. The practical licence question is not the code but the service: the cloud path depends on a licence key issued by notecompanion.ai, and the README does not describe what happens to an activated vault if that service stops or a key expires. For self-hosting, ENABLE_USER_MANAGEMENT=false is documented as removing the licence requirement, which is the escape hatch. Note that the plugin's own licence key field is a cloud credential, not a software licence, so the MIT grant and the service subscription are separate things.

Upgrade cost is mostly operational. The plugin updates through Obsidian. The backend does not: the compose file pins jpfong/note-companion:latest, and pulling a new image is a manual step. The README does not document a migration path for the server database or a rollback procedure, and SELF-HOSTING.md is referenced for Docker and service setups without its contents appearing in the README. Anyone running the backend in production should read that file rather than assume the compose example is the whole story.

Editorial conclusion

Adopt Note Companion if your problem is an Inbox folder of unprocessed captures and meetings you never write up, and you are willing to run either a cloud licence key or the Docker backend on port 3000. Skip it if you work primarily on Obsidian mobile, since the manifest marks the plugin desktop-only, or if you want to paste an OpenAI key straight into plugin settings, which the README says the plugin has no screen for. Verify two things before committing: that your chosen provider key and model work against the backend, and that ENABLE_USER_MANAGEMENT is set the way you want, because the Docker example ships it as false, which the README ties to no cloud usage tracking and no licence requirement.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes