PasteBar: a Rust and React clipboard manager with a licence question attached

A desktop app that stores your clipboard on your own disk

PasteBar is a clipboard manager for macOS and Windows that keeps unlimited history and lets you organise what you copy into clips, collections, tabs and boards. The positioning is local-first, and the privacy section on the README backs that up with local storage for privacy and security, plus a lock screen and passcode protection, PIN-protected collections, and a custom data location option.

The custom data location is the feature most likely to matter to you. Version 0.7.0 added the ability to choose where application data is written instead of using the default location, and the README is explicit about why: it makes syncing across devices through cloud storage or a shared network drive possible. That is a design decision worth naming. Rather than building a sync protocol, PasteBar lets you point the SQLite database at a directory your existing sync tool already watches.

The same release added backup and restore for the database and images, so exporting your whole history is a first-class operation rather than a side effect. If you keep anything sensitive in your clipboard, which given PIN-protected collections you probably do, having both a restorable export and a passphrase on the window is a sensible pairing.

Building it needs Node, Cargo and the Diesel CLI

The Quick Start on the README is short, and the honest version of it is that PasteBar is a Tauri app, so you need the Node and Rust toolchains plus whatever Tauri needs for your platform.

npm install
npm run build

The development path is slightly longer because the database has its own command line tooling:

cargo install diesel_cli --no-default-features --features sqlite
npm install
npm start

The `cargo install diesel_cli` step is the one people miss. The `package.json` carries a `diesel:migration:run` script that calls `diesel migration run`, so without that binary on your path the migrations cannot be applied at all. The `--no-default-features --features sqlite` flags matter too: the default Diesel build assumes Postgres, and this project uses SQLite.

One practical note about configuration. The `.env.sample` file in the repository root contains exactly two keys, `DATABASE_URL` and `MISSING_TRANSLATION_SAVE_PATH`, and both are empty. You have to fill in `DATABASE_URL` yourself before migrations will do anything, so copy the sample and set it rather than assuming a default exists.

What Rust does and what React does

The technology stack section splits cleanly. On the Rust side the README names Tauri for the app shell, Diesel as the ORM, and Reqwest, Anyhow, Serde and Tokio for networking, error handling, serialization and the async runtime. On the JavaScript side it lists TypeScript, React 19, React Query, Vite, TailwindCSS, Signals, Jotai and Zustand.

The repository layout follows that split exactly. `src-tauri/` holds the Rust side and is where the Tauri configuration lives, including the release configuration file that the build script points at. `packages/` and the root TypeScript configuration files hold the frontend, and `migrations/` plus `diesel.toml` handle the schema. A `tailwind-safelist.txt` is checked in at the root, which is the usual sign of dynamic class names that Tailwind's scanner cannot see in the source.

Looking at the scripts in `package.json` shows how the build is parameterised. `app:build` runs Tauri against the release config, and there are separate targets for `universal-apple-darwin`, `x86_64-apple-darwin` and `aarch64-pc-windows-msvc`, which lines up with the README claiming support for Apple Silicon, Intel, AMD and ARM. There is also a debug build variant and a `translation-audit` script that runs a TypeScript audit of the translation files.

Version 0.7.0 shipped in June 2025 while commits continued into 2026

The repository's most recent release is v0.7.0, published on 2025-06-25. Before that came v0.6.2 in September 2024 and v0.6.0 in August 2024, so the tagged history is sparse and the gaps between tags are long.

Commits tell a different story. The last push to the repository was on 2026-08-18, more than a year after the newest tag. Both facts are in the repository as published, and readers should hold them together rather than pick one. The working tree contains an active project with changes in it. The newest downloadable build for end users is the one from June 2025.

That gap is the kind of thing worth checking against your own needs. If you are planning to `npm run build` from a checkout, you get whatever is in the tree, which is ahead of 0.7.0 in ways the release notes do not describe. If you just want the application, you are installing 0.7.0 and its feature list. The README describes 0.7.0 as current, including a version badge that says 0.7.0 and a dedicated `WHATS_NEW_0.7.0.md` file, so the documentation has not been rewritten for the post-release work.

The licence answer changes depending on where you look

This repository has a genuine inconsistency about its licence, and you should see all three parts of it rather than a tidied version.

At the top of the README, the licence badge renders as the words Open Source and links to a file called `LICENSE`. In the Licence section further down, the text says the project is under a Creative Commons Attribution-NonCommercial, or CC BY-NC, licence with a limited commercial use exception, and points the reader to the LICENSE file for details. Meanwhile, the top-level listing of the repository contains a file named `CC-LICENSE` and no file named `LICENSE` at all. GitHub's own licence field for the repository is empty, meaning GitHub did not recognise a licence it could identify.

What that means practically is that the badge and the section point at a path that is not in the tree, while the file that is in the tree is named something else and describes a non-commercial terms set rather than a typical software licence. CC BY-NC is a content licence, not a software licence, so treating it as covering an application raises questions that only the author can answer. If you intend to fork PasteBar for commercial use, that exception is the entire question, and it needs a direct answer rather than an inference. Read `CC-LICENSE` first, then ask if the limited commercial use exception covers your use case.

Where PasteBar sits against Maccy and CopyQ

The clipboard manager category on macOS has well-known free alternatives, and the searches people run about PasteBar tend to pair it with Maccy and CopyQ, so it is worth being direct about the differences.

Maccy is a small native macOS app written in Swift with no database beyond what it needs, and its appeal is that it gets out of the way. CopyQ is a cross-platform Qt application with scripting and tab support, and it has existed long enough to have a plugin ecosystem. PasteBar's differentiators sit elsewhere: the Rust and React stack for people who want to work on it, the SQLite database with migrations, backup and restore of both database and images, PIN-protected collections, and the custom data location that makes external sync possible.

There is a real cost to that choice, and it is the Tauri build chain. Compiling a Tauri app locally is slower and has more moving parts than installing a Swift or Qt binary, and you need the Diesel CLI before the database layer will even initialise. The README's own quick start reflects that. What you get in return is a project you can extend in a mainstream language pair rather than a small utility you either accept or replace.

The translation story is also worth a look if you work in more than one language. The README lists support for English, Chinese, Ukrainian, Spanish, Italian, French, Russian, Turkish and German, points translations at a separate repository, and the root tree carries a `translation-audit` npm script to help keep those files consistent.

Editorial conclusion

PasteBar is worth reading if you want to see how a small desktop product handles the unglamorous parts of clipboard work, namely where the database lives, how migrations are run, and how a desktop app keeps its translations straight across nine languages. It is not the fastest option, and if you only need history on one machine the README's feature list is longer than the problem requires. The first thing to resolve before building is the licence, because the badge, the licence section and the repository contents disagree about which file holds the terms. The second is the release gap, since work continued on the repository after 2026-08-18 while the newest tag remained 0.7.0 from 2025-06-25, so check the commit log against the last published build before you depend on a feature.

Frequently asked questions

Official sources

1. Issues
2. PasteBar/PasteBarApp on GitHub
3. README
4. Releases