A new open-source project on GitHub offers developers a way to screen photos and artwork for sexually explicit material. The project, nsfw_sherlock, is written in Go and runs its models through ONNX Runtime. According to the project's README on GitHub, it ships as a single binary, exposes both HTTP and gRPC interfaces, and can mark the parts of an image that contain explicit content. An optional module can also detect words inside pictures. The repository carries a publication timestamp of 12 October 2026.
What the tool does
Image moderation has become a routine task for websites, marketplaces, and apps that accept user uploads. Human reviewers cannot inspect every file, so many platforms rely on classifiers that assign a risk label to each image before it goes live. nsfw_sherlock follows that model. Its README describes it as an image classification service that handles both photographs and anime-style illustrations, a useful distinction because stylised artwork often confuses general-purpose filters.
The service does more than issue a single yes-or-no answer. According to the README, a full analysis returns a verdict of sfw, suggestive, or explicit, along with an NSFW score. The project also looks for explicit regions, which means it can point to the area of an image that triggered the result rather than only labelling the whole picture. The README says the engine combines the outputs of its different checks into the final result.
Errors follow a consistent structure. The README says failed requests return an error message, a status field marked as failed, and a flag indicating an error occurred. Consistent error formats matter for developers who need to build retry logic or log failures in automated pipelines.
Two interfaces and optional text detection
The default interface is HTTP. Operators who prefer a typed, binary protocol can switch to gRPC by setting an environment variable, according to the README. The gRPC service exposes three operations: Detect, DetectLabels, and Analyze. The README notes that the service definition file contains the request and response types, so client code can be generated from it.
Text detection is optional and relies on Tesseract, an open-source optical character recognition engine. The README says Tesseract detects words in images, which can matter for moderation because explicit content is sometimes embedded in text overlays or captions added to pictures. Operators who do not need this step can turn it off with a configuration flag, and the README states that disabling OCR also disables text detection.
Where the source build differs
The README draws a clear line between the Docker image and a build from source. The Docker image includes the models and OCR support, and the project says it runs on Linux systems with amd64 and arm64 processors. Docker Hub and GHCR publish the same images. A source build, by contrast, leaves out OCR by default. In that configuration, the README says the engine always reports the text-detection field as false, a detail that anyone using the source build should account for in their logic.
To enable OCR in a source build, the README lists several prerequisites: Tesseract, Leptonica, their development libraries, and English language data. The build then needs an OCR build tag. Teams planning a custom deployment should plan for these dependencies in advance.
GPU acceleration: options and limits
Because the service runs through ONNX Runtime, it can use hardware accelerators where they are available. The README describes two routes. For NVIDIA hardware, the project provides a CUDA-enabled image for Linux amd64. The README says the host needs a compatible NVIDIA driver and the NVIDIA Container Toolkit, and it names a device index variable that selects which GPU the service uses, defaulting to the first one.
AMD hardware requires more manual setup. According to the README, users must install ROCm and a MIGraphX-enabled ONNX Runtime library, select the appropriate provider setting, and point the service to that library. The project does not publish an AMD-specific image, so this path is for operators comfortable building their own environment.
The README also contains important caveats. If the chosen provider is not available, the service stops at startup rather than quietly falling back to a slower mode. Operators whose models include unsupported operators can still run those parts on the CPU. The README is candid that GPU inference has not been tested on physical NVIDIA or AMD hardware, which means organisations with production GPU requirements should run their own benchmarks and validation before relying on the setup.
Licensing and commercial use
The code is released under the AGPL-3.0 licence. That licence has strong copyleft requirements, which can affect companies that modify the software and offer it over a network. The README adds a separate warning: model licences apply independently of the code licence, and developers should review them before commercial use.
The README singles out one model, described as the compat model, which carries non-commercial and no-derivatives restrictions. Anyone who plans to export or redistribute that model should read its licence first. The runtime is based on the onnxruntime_go binding, and OCR relies on the gosseract wrapper and Tesseract itself.
The project also includes a download script that uses pinned SHA-256 digests for the runtime and models, and the engine compares each model digest against a manifest at startup. The README presents these checks as a way to confirm that the files in use match the expected versions.
What comes next for developers
nsfw_sherlock is a developer-facing component rather than a finished consumer product. Its value lies in offering a self-hosted option for teams that want to keep image analysis in their own infrastructure. The README also mentions continuous integration checks, including static analysis, a vulnerability scanner, and a Docker smoke test, and it says release jobs publish images only after those checks pass. Those details suggest the maintainer is aiming for a production-minded workflow.
Potential adopters should weigh several factors before deploying. They need to confirm that the model licences fit their use case, test GPU paths on their own hardware, and decide whether OCR is worth the extra dependencies. Projects like this one tend to evolve quickly, so checking the repository for updates before integrating is sensible. For now, the README makes clear what the project offers and where its limits lie, giving teams a concrete starting point for evaluating self-hosted image moderation.
Related: Open-Source n8n Bot Calculates Czech Tax on Broker Investments · Software License Renewal Tracker Sends Timely Reminders
Comments (0)