# Gorse: Open-Source Recommender System Engine for Go Services > Gorse is an open-source recommender system written in Go that supports collaborative filtering, user-to-user and item-to-item recommendations, LLM-based rankers, and multimodal content via embeddings. It exposes a RESTful API and a GUI dashboard, and is designed to run as a distributed service inside an existing online platform. **gorse-io/gorse** — AI powered open source recommender system engine supports classical/LLM rankers and multimodal content via embedding. - Repository: https://github.com/gorse-io/gorse - Website: https://gorse.io - Stars: 9,836 · Forks: 919 - Language: Go - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/gorse-io-gorse ## The Problem Gorse Addresses Recommendation systems in online services require continuous data ingestion, model training, and real-time serving at request time. Building that pipeline from scratch demands both machine learning expertise and distributed systems work. Gorse is designed as a drop-in service that handles model training, offline recommendation generation, and real-time serving through a REST API, so that a product team can add personalized recommendations by importing their interaction data rather than building the ranking layer themselves. The README positions Gorse as "a universal open-source recommender system that can be quickly integrated into a wide variety of online services." The workflow is to import items, users, and interaction events (such as clicks, ratings, or purchases) into Gorse, after which the system automatically trains models and generates recommendations for each user. The service is written in Go and runs as a cluster of three node types. ## Cluster Architecture: Master, Worker, and Server Nodes Gorse uses a single-node training and distributed prediction architecture. The README describes three node roles: The master node handles model training, non-personalized recommendation (for example, trending items), configuration management, and cluster membership. Training runs on the master and the resulting model is distributed to the other nodes. The server nodes expose the RESTful APIs for data CRUD operations and handle online real-time recommendation requests. When a user makes a request for recommendations, it goes to a server node. The worker nodes handle offline recommendation generation for each user. Offline recommendations are precomputed and cached, so that when a server node receives a request, it can respond quickly without waiting for a fresh model inference. The GUI dashboard for monitoring, data import/export, and status checking runs on the master node. An administrator accesses it through a web browser to inspect training task progress, review recommendation quality, and manage data. Data is stored in MySQL (including MariaDB), MongoDB, Postgres, or ClickHouse. Intermediate results are cached in Redis, MySQL (MariaDB), MongoDB, or Postgres, depending on the deployment configuration. ## Quick Start with the Playground Mode The README provides a single-container playground mode for testing the system without setting up a full cluster: ```bash docker run -p 8088:8088 zhenghaoz/gorse-in-one --playground ``` The playground downloads sample data from GitRec (a repository recommendation demo) and imports it into the Gorse instance. The dashboard becomes accessible at http://localhost:8088 once the container starts. After the item-to-item recommendation task completes (visible on the Tasks page in the dashboard), the system is ready to test with custom feedback. The README shows inserting star events for a hypothetical user interested in LLM repositories, then querying for ten recommendations: ```bash curl http://127.0.0.1:8088/api/recommend/bob?n=10 ``` The playground mode is not suitable for production. It runs all components in a single container with no database separation, no cluster, and no persistent storage configuration. It is a demonstration environment for evaluating Gorse's behavior before designing a proper deployment. ## Inserting Data and Reading Recommendations via the REST API The operational pattern for integrating Gorse into a live service is to insert item and user records, then stream interaction events (feedback) as they occur, and to call the recommendation endpoint when the application needs a personalized list. Feedback records follow a JSON structure with FeedbackType, UserId, ItemId, Value, and Timestamp fields. The playground example in the README inserts star events using a JSON array payload to the feedback endpoint. After those events are processed, the recommendation endpoint returns ranked item IDs for the user. Gorse provides RESTful APIs for data CRUD across items, users, and feedback, and for recommendation requests. The Swagger UI is embedded in the running service and accessible at the /api path on the master node, which provides interactive documentation of all available endpoints. The go.mod shows that Gorse uses go-restful (github.com/emicklei/go-restful/v3) for the REST layer and goptuna (github.com/c-bata/goptuna) for hyperparameter optimization during model training. The gomlx and go-xla dependencies indicate support for XLA-accelerated ML operations. ## What Gorse Does Not Cover Gorse is a black-box recommendation service. It does not expose the trained model weights or provide tooling for inspecting why a specific item was recommended to a specific user. Teams who need explainability or auditability of individual recommendations will need to add that instrumentation separately. The cluster requires multiple infrastructure components: at least one of the supported databases, a Redis or compatible cache, plus separate processes for master, server, and worker nodes. The docker-compose.yml in the repository shows a multi-service setup with MySQL, worker, server, and master containers with linked dependencies. This is substantially more infrastructure than a single-binary service. The README does not document horizontal scaling limits, maximum item or user counts, or latency guarantees. Teams building systems with very large catalogs or high-traffic recommendation endpoints should run their own load tests against a staging deployment before relying on Gorse in production. Gorse's v0.5.x series (latest: v0.5.11, July 2026) is not at a 1.0 stable release. API stability between minor versions should be verified in the CHANGELOG before upgrades. ## Surprise as an Alternative and Apache-2.0 License The README's acknowledgments list Nicolas Hug's Surprise library as one of Gorse's inspirations. Surprise is a Python library for building and evaluating collaborative filtering algorithms, commonly used by data scientists for offline experimentation and research. The difference in approach is fundamental: Surprise is a Python library for batch analysis and benchmarking in notebooks, while Gorse is a Go service designed for deployment as a production recommendation API. Surprise has no REST API or cluster mode. Gorse is not intended for offline experimentation or notebook-driven evaluation. For teams that need a production-ready service and are comfortable with Go, Gorse provides the full serving pipeline. For teams exploring recommendation algorithms in Python before committing to a deployment architecture, Surprise fits the exploratory phase. Gorse is licensed under Apache-2.0. Apache-2.0 allows free use in commercial products and requires retaining copyright notices and the license text. It also includes an explicit patent grant clause. The last push to the repository was on September 22, 2026, and the most recent release is v0.5.11, published on July 14, 2026. ## Conclusion Gorse suits engineering teams that want a self-hosted recommender service with a REST API, a GUI for monitoring, and support for both classical collaborative filtering and LLM-based ranking, all in a Go deployment. It is not the right choice for one-off offline analysis or for teams already running Python ML pipelines who need notebook-level experimentation. Before deploying, confirm that your target database (MySQL, MariaDB, MongoDB, Postgres, or ClickHouse) is available and that you have a Redis or database instance for the caching layer, since both are required in a production cluster setup. ## FAQ ### What databases does Gorse support for storing recommendation data? The README states that Gorse stores data in MySQL (including MariaDB), MongoDB, Postgres, or ClickHouse. Intermediate results are cached in Redis, MySQL (MariaDB), MongoDB, or Postgres. ### Does Gorse support LLM-based recommenders? Yes. The README lists AI-powered support for both classical recommenders and LLM-based recommenders as a core feature. The multimodal content support (text, image, video via embedding) is also listed as a first-class capability. ### How do you fetch recommendations from Gorse after inserting feedback? After inserting user feedback events through the REST API and allowing model training to complete (tracked on the Tasks page in the dashboard), recommendations are retrieved by calling the /api/recommend/{userId} endpoint with an n parameter for the number of results. ## Sources - [Official documentation](https://gorse.io) - [Official README](https://github.com/gorse-io/gorse#readme) - [Project repository](https://github.com/gorse-io/gorse) - [Release notes](https://github.com/gorse-io/gorse/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gorse-io-gorse