Greasy Fork: the Rails application that powers the user-script platform, and what it costs to run your own
An online repository of user scripts.
At a glance
- What is it?
- Greasy Fork is the Ruby on Rails application that powers greasyfork.org, where user scripts and user styles are published, discovered and discussed. The repository is fully open source, but setup instructions live in an external wiki, and Elasticsearch as the search backend is the most demanding dependency for anyone running their own instance.
- Who is it for?
- Greasy Fork is the right codebase when you want to contribute to the live platform or study how a user-script hosting service is built in Rails. Running your own instance requires MySQL or MariaDB, Redis and Elasticsearch; the README defers all setup to a wiki page that is not in this repository.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly Ruby, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 6, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Discovery, sync and moderation: the six service areas the platform covers
Greasy Fork handles user scripts and user styles across six areas: discovery, publishing, community, moderation, localization, and external integration. Discovery lets visitors browse and search for scripts by website or keyword. Publishing covers uploading, updating and managing individual scripts. The community section offers discussion threads and author feedback. Moderation gives site reviewers tools for flagging and removing problematic content.
Localization and external integration are the two areas with the most architectural weight. Localization means the site runs in multiple languages maintained by community volunteers through Transifex. External integration is the feature that lets a script author keep source code in an external repository and have Greasy Fork pull updates automatically, either on a schedule or through webhooks triggered by code pushes.
Each area has consequences for the codebase's dependencies. Moderation requires user accounts, report queues and review workflows. External sync requires background job processing. Search across all scripts and styles requires a dedicated search service. None of these sit inside Rails as lightweight add-ons; each has its own infrastructure dependency, which becomes visible in the technology table.
A Ruby on Rails monolith backed by MySQL, Sidekiq and Elasticsearch
The application is a Ruby on Rails monolith with MySQL or MariaDB as its primary data store. Both MySQL and MariaDB appear in the same cell of the technology table, indicating either works as the data store. Background jobs run through Sidekiq with Redis as the queue backend. Sidekiq handles any work that should not block a web request: script synchronization pulls, moderation queue processing and notification delivery are the obvious candidates given the feature list, though the README does not specify which jobs are queued.
Search uses Searchkick, a Ruby gem that wraps Elasticsearch and integrates it with ActiveRecord models. This is the dependency with the highest operational cost. Elasticsearch runs on the JVM and requires memory allocation and its own configuration; every developer needs it running locally, and every self-hosted instance needs it in production. Searchkick provides the ActiveRecord integration and reindexing tools, but it does not remove the requirement for Elasticsearch itself.
The frontend pairs Turbo from the Hotwire suite, provided by @hotwired/turbo-rails ^8.0.5, with Vite as the JavaScript bundler. A vite.config.ts at the repository root configures the build. Testing uses Minitest for unit tests, Capybara for integration tests and Selenium as the browser driver for full-stack test runs.
What package.json reveals about the frontend that the README leaves out
The README points to package.json for exact dependency versions but does not describe what each library does. Reading the file adds three layers of detail the README skips.
First, Ace (ace-builds ^1.4.12) provides the in-browser code editor for writing and editing user scripts. Ace is a self-contained browser editor with syntax highlighting and keybinding support; it needs no server component. Second, Chart.js (^4.0.0) handles charts; the technology table names it as the charting component without specifying which data it visualizes. Third, @github/relative-time-element (^5.0.0) is the HTML custom element that GitHub developed for displaying timestamps such as 'three days ago'; it handles timezone conversion in the browser without server involvement.
Two dependencies appear in package.json without any explanation in the README: detect-browser (^5.2.0) and js-sha1 (^0.7.0). detect-browser is a library that identifies the visitor's browser from the user-agent string. js-sha1 computes SHA-1 hashes in JavaScript. Neither dependency appears in the README's feature list or in the technology table, so their purpose is not documented. Their presence shows that browser-specific behavior and client-side SHA-1 computation are part of the frontend, but no account of what either function does appears anywhere in the README or the technology table. A developer reading only the README would not know these two libraries are in the build at all.
Running locally requires the wiki; Procfile.dev, Capfile and .circleci reveal the rest
The README's contributing section links to a wiki page for running Greasy Fork locally. No installation commands appear in the README itself, and no Docker Compose file appears in the top-level directory listing. Anyone starting local development must visit the wiki, which is not part of this repository.
Two top-level files reveal what the development and production environments look like without being documented in the README. Procfile.dev is the development process file, used by tools such as Foreman or Overmind to start multiple processes at once. Given the dependency on Rails, Vite and Sidekiq, the development environment needs at least a web server process, a Vite asset builder and a Sidekiq worker running concurrently. Capfile at the repository root is a Capistrano configuration; Capistrano is a Ruby-based deployment tool that connects to remote servers over SSH and runs deployment tasks in sequence. The README does not describe production deployment at all, but Capfile identifies Capistrano as the mechanism in use.
The .circleci/ directory shows that continuous integration runs on CircleCI. The testing stack with Minitest, Capybara and Selenium gives the suite browser-level coverage. All of this operates outside the README's scope, which limits its prose to what contributors and translators should do rather than how the infrastructure runs.
Localization uses Transifex with English as the source and config/locales for storage
Greasy Fork runs in multiple languages maintained by community translators. Translation files live under config/locales, which is the standard Rails directory for I18n YAML files. English is the source locale, meaning all new strings are written in English first and submitted for translation afterward.
The repository is configured to work with Transifex through .tx/config at the root. Transifex is a translation platform that pulls source strings from the repository and pushes translated strings back. The .tx/config file maps local file paths to Transifex resource identifiers, so the sync between repository and translation platform runs automatically rather than through manual copy-and-paste.
Anyone wanting to add or improve a translation can follow the wiki link for translating Greasy Fork. This contribution path is framed as a community effort rather than a core team responsibility, which is consistent with how most open-source web applications approach localization: translations accumulate at different rates across languages depending on volunteer availability.
Self-hosting requires three external services and the COPYING terms apply to any fork
Running a full instance of Greasy Fork requires MySQL or MariaDB, Redis and Elasticsearch, in addition to a Ruby environment. Each is a stateful service with its own data directory, connection pooling and backup requirements. Elasticsearch consumes significant memory because it runs on the JVM; on a small server, memory allocation for Elasticsearch is the first constraint to appear.
No Docker Compose file appears in the top-level repository listing, which means no pre-built local orchestration of the three external services is provided. A developer following the wiki's local setup guide must start each service independently. For production, Capistrano's deployment model assumes servers are already running and configured; it handles code deployment, not infrastructure provisioning.
Under the terms in COPYING, anyone distributing or publicly running a modified version must make their modifications available under the same conditions. The full text of the applicable terms is in COPYING at the repository root. This means using the codebase as the foundation for a closed proprietary fork is not an option the terms allow.
Production deployment via Capistrano, no version tags, and a $10 hosting contribution
GitHub shows no version tags for this repository. The last push was on 2026-10-05. How the live site is deployed from the repository is not documented in the README, though the Capfile at root points to Capistrano as the deployment mechanism.
The README's support section asks users to donate $10 to cover hosting costs, with separate links for Stripe and PayPal. The phrasing frames this as a suggested contribution rather than a subscription or fee. No tier list, no sponsorship page and no recurring payment option appears in the README; the two payment links go directly to one-time payment flows.
The project has no public roadmap listed in the README. Contributions and bug reports go through the GitHub issue tracker, with development discussions documented there alongside existing bug reports. The README's contribution path sends all setup and code guidance to the wiki, which keeps the README itself short but also means the primary information about how to get a development environment running is one link removed from the repository.
Editorial conclusion
Greasy Fork is the right codebase when you want to contribute to the live platform or study how a user-script hosting service is built in Rails. Running your own instance requires MySQL or MariaDB, Redis and Elasticsearch; the README defers all setup to a wiki page that is not in this repository. Anyone forking it for a closed service should read COPYING first, because the terms prohibit distributing a modified version without publishing the source. Before writing a contribution, check the wiki's contributing guide, since the README points there for both environment setup and code submission guidelines.
Frequently asked questions
What is Greasy Fork?
Greasy Fork is the Ruby on Rails application that runs greasyfork.org, a platform for discovering, publishing and discussing user scripts and user styles. The repository contains the full source code for the web application.
How do I set up Greasy Fork locally?
The README links to a wiki page for local setup steps, which are not in the repository itself. The stack requires MySQL or MariaDB, Redis and Elasticsearch alongside a Ruby environment for the Rails backend.
Does Greasy Fork support user styles as well as user scripts?
Yes. The README describes Greasy Fork as a repository for both user scripts and user styles, and the feature table covers discovery, publishing and community discussion for both.
Can I fork Greasy Fork to run my own instance?
Running your own instance is possible; the full source code is available. Under the terms in COPYING, any public distribution of a modified version must make the modifications available under the same conditions.
How does Greasy Fork sync scripts from external sources?
The feature list covers synchronizing scripts from external sources and webhook-based updates, but the README does not document the mechanism. Technical details are in the project wiki.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/greasyfork-org-greasyfork)