Sefaria-Project is a Django and React reading platform for Jewish texts

The README is an invitation to use the API, not to patch the site

The opening line is the positioning statement. Sefaria is a digital library and platform for accessing Jewish texts and text-based learning, and the developers invite others to build on the largest open-source database of Jewish texts in history to build apps and services utilizing the Jewish canon. Everything after that is signposting. There is a Developer Portal with the docs, an interactive API reference, tutorials and installation instructions, and a Discord community for interested developers. The route for questions about the API or the technology is a contact form on the portal, and general questions about using Sefaria.org go to a separate address. So the repository is published in the hope that people will build on top of it, and the readme is careful to separate that from the business of running the site.

Contributions are welcome and deprioritised at the same time

The section on contributions is the most unusual part of the readme and worth reading carefully. There are endless avenues for improving and expanding Sefaria, so the project has to select its projects carefully, whether fixing a bug or developing a feature, and its priorities are guided by both the long-term organisational vision and user research. As a result, the readme says it rarely prioritises public code contributions, because they are not aligned with the product pipeline, while saying it appreciates feature requests and bug reports and is happy to hear suggestions. Then it gives the alternative explicitly. If you are looking to build a feature that supports Torah study, you are highly encouraged to build a Powered by Sefaria project rather than submitting a pull request, with a list of community projects linked from the developer docs. A contributor who reads this properly does not open a pull request with a new feature at all, they build something next to the library.

The code is Django, React and a lot of surfaces

The repository layout is large and describes the shape of the application. There is a manage.py and a sefaria/ directory, so the Python side is Django, and there are api/, api-tests/, reader/, semantic_search/ and django_topics/ directories covering the read interface, the API and the topic taxonomy. The JavaScript side is a node/ directory with a webpack configuration, a package.json named sefaria-web whose description is the server for rendering React components for Sefaria, and a stories/ directory for shared components. There is also a dedicated multi-surface build setup, with separate webpack configs for the diff page, explore, the main sefaria bundle and the timeline, and a build-categorizeSheets script for the sourcesheets tooling. A playwright.config.ts and a playwright.mobileweb.config.ts sit next to an e2e-tests/ directory, so browser testing is part of the workflow rather than an afterthought, and there is a distinct semantic_search/ directory, which suggests retrieval over the corpus is a first-class feature.

Running it locally means four services in Docker

The docker-compose file gives the local stack, and it is four services with a fixed set of ports. The web service builds from the Dockerfile, maps 8000, mounts the current directory at /app, and depends on the other three. The db service is mongo:4.4 on 27017 with a named volume. The cache service is redis on 6379. The node service runs the npm start script on 3000, and the postgres service runs with a sefaria database, exposing 5433 on the host mapped to 5432 in the container, which is a deliberate shift to avoid colliding with a local Postgres.

  web:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    depends_on:
      - db
      - cache
      - postgres

The Dockerfile itself is a Python image on python:3.12-slim-bookworm with git and gcc installed for pip git packages and compiled dependencies, and it ends by running the Django management command. The requirements file is autogenerated by pip-compile, so the Python dependencies are locked and the comment on each line records which package pulled it in, which is a habit worth copying in a project of this size.

The front end has its own build and its own Storybook

The JavaScript build is a webpack project with several entry points and a build script for the client bundle, the server bundle, and the individual page bundles. The watch scripts run webpack with progress and watch options, and a concurrently script runs the stylesheet compiler alongside the webpack watcher. The Storybook section explains how shared React components are developed and reviewed, with the Vite builder. The steps are simple, and the constraint is the detail worth noting, because Storybook 8 requires the active LTS releases, so Node 18 or newer is needed.

npm run storybook

The dev server then runs at http://localhost:6006. Stories live in the stories/ directory, each story can import components from static/js, and every story automatically receives the global Sefaria stubs defined in .storybook/preview.js. That last detail is the reason the Storybook exists at all. Sefaria's React components reach into a global context object for locale, version, and interface state, and a shared stub object lets those components render outside the real application, which is what makes component-level review possible on a platform whose components are otherwise tightly coupled to server-rendered context.

Where the project is not what a reader might expect

There are two things to understand before you build anything. The first is that this is a live website, not a library, so the repository contains a production system with all the accompanying surface, including a helm-chart/ directory whose releases are the version tags you see, a multiserver-monitor.py, an sso/ directory, a remote_config/ directory, a promotions/ directory, a sourcesheets/ directory and an envs/ directory of environment definitions. The deployment story is Helm and Google Cloud oriented, and the release tags in the repository are chart versions, not application versions, which tells you how the project ships. The second is that the data is the durable asset. The readme's framing of an open source database of Jewish texts as the thing worth building on means that for most users the right dependency is the API rather than the code, and the code becomes relevant mainly when you want to self-host, to extend the interface, or to contribute to the site itself, which the readme says it rarely prioritises.

Editorial conclusion

Sefaria-Project suits a developer who wants to build a Torah study tool on top of a real corpus of Jewish texts rather than a toy sample, because the API and the data are the product and the code is open under GPL-3.0. It is the wrong repository to send a pull request to, because the README says contributions are rarely prioritised and points people at the Powered by Sefaria programme instead, and it is the wrong thing to fork as a starting point for an unrelated web application, since the Django configuration, the data model and the React build are all shaped around this one library. Before building on it, read the developer portal docs and the API reference, and decide early whether you are a consumer of the API or a contributor to the site, because the project treats those as two different activities. The last push was on 2026-10-19 and the release tags are Helm chart versions rather than application releases.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Sefaria/Sefaria-Project on GitHub