# Violentmonkey: a WebExtensions userscript manager you can build from source > Violentmonkey runs userscripts in Chrome, Firefox and Edge through the WebExtensions API. It is MIT licensed, and the repository is written in JavaScript with a pnpm and gulp build. **violentmonkey/violentmonkey** — Violentmonkey provides userscripts support for browsers. It works on browsers with WebExtensions support. - Repository: https://github.com/violentmonkey/violentmonkey - Website: https://violentmonkey.github.io/ - Stars: 8,959 · Forks: 764 - Language: JavaScript - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/violentmonkey-violentmonkey ## What Violentmonkey is for, and who should care Violentmonkey is a userscript host. The README states the scope in one line: it provides userscripts support for browsers, and it works on browsers with WebExtensions support. A userscript is a small JavaScript file that a page loads alongside the site's own code, which is how people add keyboard shortcuts to a web app, remove a cookie banner, or rewrite a table on a page they do not control. The audience is narrow but real. If you maintain a browser extension and want a place to prototype a content script, a userscript manager is faster than rebuilding the extension for every change. If you are a user who wants one specific behaviour on one specific site, Violentmonkey is the host that runs the file. It is not a framework, not a package manager, and not a service. Nothing runs on a server; the manager lives in the browser. The project is MIT licensed and written in JavaScript. The repository lists browser builds for Chrome, Firefox and Edge, and the README points to two ports for browsers outside the WebExtensions family: Violentmonkey for Opera Presto and Violentmonkey for Maxthon. Those ports are separate repositories, which is worth knowing before you assume the main codebase covers every browser. ## How the extension is put together The repository layout tells you most of the architecture. Source lives under src/, translations under _locales/, and the build pipeline is gulpfile.js driven by scripts in package.json. The package name is violentmonkey and the version in package.json is 2.49.0. The devDependencies pull in Babel, ESLint, Jest, Vue compiler packages and the @violentmonkey/types package, which is the shape you would expect from a Vue-based extension UI bundled with webpack. The interesting part is the manifest version. Two dev scripts exist: "dev": "gulp dev" and "dev:mv3": "cross-env MV3=1 gulp dev". The same split appears in the build scripts, where "build": "cross-env NODE_ENV=production gulp build" sits next to "build:mv3": "cross-env NODE_ENV=production MV3=1 gulp build". So the codebase produces both a Manifest V2 and a Manifest V3 build from one tree. That matters because Manifest V3 changes how background code runs in Chromium browsers, and a userscript manager depends heavily on background work. The repository does not explain in the README how the two builds differ at runtime; you have to read the source or the release notes. There is also a self-hosted target: "build:selfHosted": "cross-env TARGET=selfHosted BETA=1 run-s build". The comment in the README says this build carries an update_url, which is the mechanism a browser uses to check for updates outside a web store. That is the path for anyone distributing the extension themselves rather than through the Chrome Web Store or Firefox Add-ons. ## Installing Violentmonkey and running a first script For normal use, the README points at the store listings rather than a manual install. The badges at the top of the README link to the Chrome Web Store entry, the Firefox Add-ons page, and the Microsoft Edge Add-on page. Install from the store for your browser and the extension appears in the toolbar. The README does not describe the in-browser first-run flow, so what you see after installation is not documented there. If you want to run the current development tree instead, the README gives the steps. Node.js and PNPM are required, and the README says the Node.js version should match the "node" key in package.json. Then: ```bash # Install dependencies pnpm ci # Watch and compile pnpm dev ``` After pnpm dev finishes, the README says to load the extension from 'dist/'. In Chrome and Chromium-based browsers that means loading it as an unpacked extension; in Firefox the README describes the automated test build as a temporary extension. Note the preinstall script in package.json, "npx only-allow pnpm", which blocks npm and yarn installs. If you run pnpm ci and nothing happens, check that you are actually on pnpm. Before you test any build that is not a store release, the README is explicit: do an export in Violentmonkey settings first. The test builds are generated automatically between beta releases, and the README warns they are likely to have bugs. Exporting gives you something to restore from, because the README does not document a rollback procedure. To build a release locally, the README lists two commands. The plain build is for normal releases, and the self-hosted build is for a release that has an update_url: ```bash # Build for normal releases pnpm build # Build for self-hosted release that has an update_url pnpm build:selfHosted ``` The test and lint path is a single script, "ci": "run-p lint test", which runs ESLint and Jest in parallel. Running pnpm run ci before you touch the source tells you whether your environment matches what the project expects. ## Where Violentmonkey falls short The release channel is the first limitation. The three most recent tags are v2.49.2 and v2.49.1, both labelled BETA, and v2.49.0. If you want the newest code, you are on a beta. The README also warns that automated test builds between betas are likely to have bugs. There is no documented stable-only channel in the README. Rollback is undocumented. The README tells you to export your settings before installing a test build, which is a backup instruction, not a recovery procedure. If an upgrade breaks a script you depend on, the README does not say how to get back to the previous version or whether settings migrate cleanly between versions. Documentation depth is uneven. The README covers development, test, build and release, but it does not explain how the Manifest V2 and Manifest V3 builds differ, what the self-hosted update_url points at, or how the Opera Presto and Maxthon ports relate to the main tree beyond being listed as related projects. For a project whose main artifact is a browser extension, the user-facing side of the README is thin. Finally, consider when this is the wrong tool. If you need a script to run on a schedule with no browser open, or to share state across machines, a userscript manager is the wrong layer. If you are building a product feature, embedding a userscript host inside your own extension adds a dependency you do not control. And if your target browser does not support WebExtensions, the main repository is not the answer; the README points to separate ports instead. ## Violentmonkey compared with Tampermonkey and Greasemonkey The obvious alternative is Tampermonkey, and the difference that the repository itself makes visible is licensing. Violentmonkey is MIT. Tampermonkey is not open source, which means you cannot read its source, file a patch, or build it yourself. Greasemonkey is the older name in this space and is the origin of the userscript format, but the README does not discuss it, so any comparison beyond the licence and the source availability would be guesswork. The practical difference in approach shows up in the build. Because Violentmonkey is MIT and its build is a gulp pipeline driven by package.json scripts, you can run pnpm dev, load dist/ as an unpacked extension, and test a change to the manager itself. You cannot do that with a closed-source manager. That is the whole argument for choosing it: not that it runs scripts better, but that the thing running your scripts is inspectable and forkable. The cost is the release channel described above. A closed-source manager with a paid tier has a commercial reason to keep stable releases stable. Violentmonkey's newest tags are betas, and the README treats test builds as expected to have bugs. If you want a manager you never think about, that trade may not be worth it to you. ## Maintenance, licence and the cost of upgrading The repository is not archived, and the last push was on 2026-09-21. Releases are frequent: v2.49.0 on 2026-09-06, v2.49.1 on 2026-09-09, v2.49.2 on 2026-09-20. Two of those three are marked BETA. That cadence means upgrade cost is mostly a matter of choosing when to move, not whether the project is alive. Upgrading from source means re-running the build. Node.js must match the "node" key in package.json, and the preinstall hook enforces pnpm, so a machine with a different Node version or with npm first in PATH will fail before the build starts. For store installs the browser handles the update, and the release notes for each tag are the only changelog the repository provides. The licence is MIT. That permits use, modification and redistribution, including in closed products, provided the licence text and copyright notice are kept. It does not grant trademark rights, so shipping a modified build under the Violentmonkey name is a question for the project, not something the MIT text settles. This is a description of the licence, not legal advice; read LICENSE in the repository for the binding terms. The self-hosted build is the one to look at if you plan to redistribute, because it is the target that carries an update_url. ## Conclusion Adopt Violentmonkey if you want an MIT-licensed userscript host for Chrome, Firefox or Edge and you are willing to install it from the stores rather than from a git checkout. Do not adopt it if you need a documented rollback path or a stable release channel, because the newest tags are betas. Before relying on it, check the version you installed, read the release notes for that tag, and export your settings from the Violentmonkey settings page before you install any test build. ## FAQ ### What is Violentmonkey used for? It provides userscripts support for browsers, meaning it runs small JavaScript files alongside the pages you visit. It works on browsers with WebExtensions support, and the README lists Chrome, Firefox and Edge builds. ### How do I install Violentmonkey on Chrome or Firefox? The README links store listings for the Chrome Web Store, Firefox Add-ons and the Microsoft Edge Add-on page; install from the one for your browser. To run the development tree instead, install Node.js and PNPM, run pnpm ci then pnpm dev, and load the extension from dist/. ### Is Violentmonkey safe to use? The repository is MIT licensed, so the source is readable and buildable, and the README warns that automated test builds between beta releases are likely to have bugs and that you should export your settings first. The repository contains no security audit, so safety beyond that cannot be confirmed from it. ### Which is better, Tampermonkey or Violentmonkey? The repository supports one concrete difference: Violentmonkey is MIT licensed and its build runs through gulp scripts in package.json, so you can compile and inspect it yourself. Tampermonkey's licence and internals are not described in the README, so a broader comparison is not possible here. ### How do I install Violentmonkey from GitHub? Install Node.js at the version matching the "node" key in package.json, plus PNPM, then run pnpm ci and pnpm dev. The README says to load the extension from dist/ afterwards, and the preinstall hook blocks npm and yarn. ### How do I use Violentmonkey scripts? A userscript is a JavaScript file the manager runs alongside a page, and the README describes the extension as providing userscripts support for browsers with WebExtensions support. The README does not walk through writing or importing a script, so the specifics are not covered there. ## Sources - [License: MIT](https://github.com/violentmonkey/violentmonkey/blob/master/LICENSE) - [Project website](https://violentmonkey.github.io/) - [README](https://github.com/violentmonkey/violentmonkey/blob/master/README.md) - [Releases](https://github.com/violentmonkey/violentmonkey/releases) - [violentmonkey/violentmonkey on GitHub](https://github.com/violentmonkey/violentmonkey) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/violentmonkey-violentmonkey