# Gisto and the snippet manager that stopped needing a GitHub account > Gisto is a cross platform snippet manager built on GitHub Gists, GitLab Snippets, a self hosted Snippet-Bin server or plain browser storage, with search, tags and a rich editor on top. Version 2 is a full rewrite that swapped Electron for Tauri, and the desktop build ships unsigned, which is the one thing an adopter has to think about before clicking through a system warning. **Gisto/Gisto** — Gisto is a Cross-platform snippets management application that allows you and/or your team share code snippets fast and easily. Based on GitHub Gists or GitLab snippets Infrastructure which means you can use all your existing snippets by connecting your GitHub/GitLab account! - Repository: https://github.com/Gisto/Gisto - Website: https://gisto.org - Stars: 1,172 · Forks: 102 - Language: TypeScript - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/gisto-gisto ## Four backends, one editor Gisto is a code snippet manager with support for multiple snippet backends, a rich code editor, searching, tagging and sharing. The description in the repository is a snippet manager that runs on GitHub Gists, GitLab Snippets or a local in-browser database, and adds searching, tagging and sharing on top, with the option of saving snippets directly in the browser's local storage. The backend list is the most interesting part of the design, because it turns a question about tools into a question about policy. GitHub Gists is the default, using your GitHub account and the Gists API, with all snippets stored on GitHub and accessible at gist.github.com at any time, and it requires a GitHub personal access token. GitLab Snippets works the same way through the Snippets API, with a GitLab personal access token. Snippet-Bin is the self hosted option, a server inspired by the GitHub Gists API that provides the same experience with full data ownership, where the snippets never leave your infrastructure. The documentation describes deploying it with Docker behind your own domain or VPN, and it needs an instance URL and an API token. The stated reasons to use it are wanting a private snippet store without relying on GitHub or GitLab, needing to host behind a corporate firewall, or preferring to own the infrastructure. Local Storage is the fourth. No account required, snippets are kept in the browser's IndexedDB, and you can export and import them as JSON files from Settings. The documented reasons to use it are trying Gisto without setting up an account, needing offline first access, or preferring not to sync snippets to any external service. The feature list beyond that covers advanced search, tags, syntax highlighting, grouping by language, quick snippet actions, copy to clipboard and copy file contents to clipboard, editor settings, a theme colour changer, and opening a snippet in external tools such as plunkr, carbon.now.sh or jsfiddle. Multi-language support is listed but flagged as machine generated, experimental and not fully implemented. ## The 2.x rewrite swapped Electron for Tauri The README states plainly that the current version is a complete rewrite of the original Gisto, and the tracking issue for the new version is #387 on the repository. The reason for the rewrite is stated as well: the new version uses Tauri instead of Electron, which significantly reduces the file size. That is a meaningful change for a desktop app distributed as a download, and it is the kind of decision that only makes sense for a project whose users install the app rather than run it from a package registry. The repository is split accordingly. Progress on the current version is tracked on the main branch, and the previous version, up to 1.13.4, is tracked on the master branch. Both are still reachable, which matters for anyone with an existing installation who wants to stay on the old build rather than migrate, and for anyone whose workflow depends on behaviour that changed in the rewrite. The rest of the toolchain matches what a modern Tauri application looks like. The front end is a Vite and TypeScript project with a src/ directory and a src-tauri/ directory for the native shell, alongside e2e/ and test/ directories, a components.json file for the component library configuration, a netlify.toml for the hosted web app, and a Dockerfile and docker-compose.yml for running the development server in a container. There is also a hull of release automation in the package manifest. The changelog is generated with npx git-cliff, and there are release:major, release:minor and release:patch scripts that bump the version, regenerate the changelog and commit it with a conventional commit message before pushing. The cliff.toml file at the root configures the generator, and commitlint.config.js and husky enforce the commit format. ## The desktop build is not code-signed The README carries a section titled Important Notice About Installation, and it is the part of the documentation an adopter should read first. The application is not code-signed, and the stated reason is money: since this is an open source project and the maintainers do not have the resources to purchase code-signing certificates, the application is not signed. The consequence is that on Windows you may see a warning such as Windows protected your PC or Unrecognized app, and on macOS a message saying the app is from an unidentified developer. The documentation is clear that these warnings are normal for unsigned applications and do not mean the app is harmful, and it tells you to make sure you download from the official release page of the repository to avoid tampered files. Then it gives the bypass steps, on Windows clicking More info and selecting Run anyway, and on macOS going to System Preferences, Security and Privacy, General and clicking Open Anyway next to the blocked app message. The advice to click through a security warning is correct in context and dangerous out of context, because the same warning appears for genuinely malicious software. The mitigation the project offers is the release page, and the practical addition is to compare what you downloaded against the published release assets rather than trusting the file name. The alternative is the web app, which is hosted at app.gisto.org, with the old one still at web-gistoapp.netlify.app. A web app carries no signing problem at all, at the cost of running inside a browser. ## Tokens live in local storage and never leave The privacy and authentication section describes two modes, and the token handling is the part worth understanding. In GitHub and GitLab mode you authenticate with a GitHub access token or a GitLab personal access token, and you can create that token yourself from the account settings rather than going through an OAuth flow. The important line is that Gisto only saves the access token in your local storage and nothing else, and that the token is saved permanently until you log out or it expires. That is a straightforward and honest model. There is no Gisto server holding your credentials, because there is no Gisto server in the picture, and the token lives where the application's own data lives. The trade-off is that a personal access token with gist scope is a bearer credential stored on your machine, and the application with access to it is unsigned, which is the combination an organisation's security review will want to look at. In local mode there is no account at all, the snippets live in the browser's local database through IndexedDB, and the export and import as JSON files in Settings is the only way to move them between machines. The documentation also lists enterprise log-in as a feature under consideration, which is a hint about the direction of travel for teams that need a shared account rather than a personal token. ## Four ways to install, and one command on macOS The macOS path is the shortest. Homebrew is recommended and the cask is published in the project's own tap: ```bash brew install --cask Gisto/tap/gisto ``` Everyone else has three options. The website at gisto.org carries more information, the releases tab has downloads for macOS, Windows and Linux, and there is a web app at app.gisto.org with the previous one still available at web-gistoapp.netlify.app. The distribution is a plain download rather than a package in a language specific registry, which is normal for a Tauri application but it does mean you are responsible for the update path, since there is no brew upgrade for a cask you did not install, and no npm install for a desktop shell. For development, the repository has both a local path and a container path. The package manifest defines the dev script as vite --port 61570, and the container path uses the same port. The Dockerfile is based on node:20-bullseye-slim, installs pnpm 10.28.1 globally, installs dependencies with a frozen lockfile, and exposes 61570. The compose file builds that image, mounts the working directory, keeps node_modules in a named volume so the host copy does not win, and starts the same command with the host set to 0.0.0.0. The test and lint scripts are equally explicit. check runs lint, ts:lint, test and e2e in sequence, lint is eslint over ./src, ts:lint is tsc -b --noEmit, test is vitest run --dir src, and e2e is playwright test with ui and headed variants for local debugging. ## MIT, frequent releases, and a machine generated changelog The licence is MIT, with the text in the LICENSE file at the root of the repository, which for a tool that stores your snippets in a desktop app is about the most permissive arrangement available. The release record is the healthiest part of the picture. The recent releases are v2.15.0 on 2026-08-28, v2.14.0 on 2026-08-22 and v2.13.2 on 2026-07-16, so this is a project shipping minor versions every couple of weeks. The repository is not archived and the last push was on 2026-10-11. The changelog is generated rather than written, with npx git-cliff producing CHANGELOG.md from the commit history, and the release scripts commit the regenerated file before pushing the tag. That is efficient and it has a known cost, since a generated changelog reflects commit messages rather than a curated description of what changed, so the quality of the release notes is the quality of the commit messages. The commitlint configuration and the conventional commit format keep that from drifting. There is an AGENTS.md at the root for tooling that reads repository instructions, a CODE_OF_CONDUCT.md, a .prettierrc, an eslint.config.js and a .husky directory, which together describe a project with the usual hygiene of a modern JavaScript repository. One configuration detail is worth a mention for anyone running the app in a controlled environment. The .env.example file shows three Sentry related variables, a VITE_SENTRY_DSN, SENTRY_PROJECT and SENTRY_AUTH_TOKEN, which means the application can report errors to a Sentry project, and the DSN is a public key while the auth token is not. If your organisation forbids that kind of telemetry, the variable names tell you exactly what to look for. ## Conclusion Adopt Gisto if you keep a growing pile of code snippets and want search, tags, grouping by language and a real editor over them, and if you are comfortable with a desktop app that is not code-signed. Do not adopt it if your snippets must stay on infrastructure you fully control without running a server, since only the self hosted Snippet-Bin route gives you that and it means deploying a service. Verify three things first: which backend fits your data policy, since the GitHub and GitLab routes need personal access tokens and Snippet-Bin needs an instance URL and API token, that you download from the official release page rather than a mirror, and whether your operating system will let the unsigned build run without a workaround. The last push was on 2026-10-11 and the newest release is v2.15.0 from 2026-08-28. ## FAQ ### What is Gisto and what backends does it support? A cross platform snippet manager with search, tags, a rich editor and sharing. It runs on GitHub Gists, which is the default, GitLab Snippets, a self hosted Snippet-Bin server, or a local browser database using IndexedDB with JSON export and import. ### Do I need a GitHub account to use Gisto? No. Local mode stores snippets in the browser's IndexedDB with no account. GitHub Gists and GitLab Snippets need a personal access token, and the self hosted Snippet-Bin backend needs an instance URL and an API token. ### How do I install Gisto? On macOS with brew install --cask Gisto/tap/gisto, or download the build for macOS, Windows or Linux from the releases tab, or use the web app at app.gisto.org. The desktop build is not code-signed, so Windows and macOS will show a security warning that you have to clear. ### What changed in Gisto 2.x? The current version is a complete rewrite of the original Gisto and uses Tauri instead of Electron, which significantly reduces the file size. Progress is tracked on the main branch, while the previous version up to 1.13.4 stays on the master branch. ### How do I run the Gisto development server? The dev script runs vite --port 61570, and the container path uses the same port, with the Dockerfile based on node:20-bullseye-slim and pnpm 10.28.1. Checks run with pnpm check, which chains eslint, tsc, vitest over src and playwright end to end tests. ### What licence is Gisto released under? MIT, with the licence text in the LICENSE file at the root of the repository. The last push was on 2026-10-11 and the newest release is v2.15.0 from 2026-08-28, with the changelog generated by git-cliff from the commit history. ## Sources - [Gisto/Gisto on GitHub](https://github.com/Gisto/Gisto) - [License: MIT](https://github.com/Gisto/Gisto/blob/main/LICENSE) - [Project website](https://gisto.org) - [README](https://github.com/Gisto/Gisto/blob/main/README.md) - [Releases](https://github.com/Gisto/Gisto/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gisto-gisto