The FOLIO platform consists of both server-side and client-side components, and will grow to include library services that run on the platform as modules. Some sample modules are located in folio-sample-modules.

Several repositories in the folio-org GitHub organization host the core project code. Third-party modules may be hosted elsewhere.

A good starting point for understanding the FOLIO code is Okapi – specifically the Okapi Guide and Reference, which introduces the concepts and architecture of the FOLIO platform, and includes installation instructions and examples. Okapi is the central hub for applications running on the FOLIO platform and enables access to other modules in the architecture.

The FOLIO system is made up of the code in several GitHub repositories. Each repository contains the code for a single well-defined element of the system. These repositories fall into three categories:

  • server-side elements that provide services and the infrastructure that they run on;
  • client-side elements that provide a framework for using those services from a Web browser;
  • and a few that fall into neither of these categories.

PLEASE NOTE that this is a technology preview following the release early, release often philosophy. We want your feedback in the form of pull requests and filed issues and general discussion via the collaboration tools.


The key server-side element is Okapi itself: the FOLIO middleware component that acts as a gateway for access to all modules, handling redundancy, sessions, etc. Individual modules are provided in their own repositories, each named mod-name: note that these are mostly at the proof-of-concept stage. Some of these modules are built from specifications in RAML, the RESTful API Modeling Language: this process is facilitated by the code in the raml-module-builder repository.

  • okapi – Okapi API Gateway proxy/discovery/deployment service.

  • raml – Repository of RAML files, including JSON Schemas, traits and resource types centralized for re-usability. The API reference documentation is also generated. This repository is the master location for the traits and resource types, while each module is the master for its own schemas, examples, and actual RAML files. It is included in other repositories via a git sub-module, usually called raml-util.

  • raml-module-builder – Framework facilitating easy module creation based on RAML files.

  • mod-auth – Prototype of a JWT-based authentication/authorization module. Will be superseded by a more capable set of modules handling authentication by various methods, and generalized permissions-handling.

  • mod-users – Demo module to provide central user management. Based on the raml-module-builder framework.

  • mod-users-bl – Business logic “join” module to provide simple access to all user-centric data.

  • mod-metadata – Initial work on a FOLIO metadata store and related knowledge-base/cataloging concepts.

  • mod-loan-storage – Persistent storage of loans.

  • mod-configuration – Demo configuration module based on the raml-module-builder and a set of RAML and JSON Schemas backed by a MongoDB asynchronous implementation.

  • mod-circulation – Circulation demo based on the raml-module-builder and a set of RAML and JSON Schemas. Represents some of the necessary circulation functionality against MongoDB.

  • mod-acquisitions – Demo acquisitions module, based on the raml-module-builder framework, exposing acquisition APIs and objects against MongoDB.

  • mod-acquisitions-postgres – A second demo acquisitions module, also based on the raml-module-builder framework and exposing acquisition APIs and objects, but implemented with an asynchronous Postgres client.


Since Okapi represents all the FOLIO functionality as well-behaved web services, UI code can, of course, be written using any toolkit. However, we will provide Stripes, a toolkit optimized for accessing Okapi-based services and wrapping UI functionality into convenient modules. We envisage that most FOLIO UI work will be done in the context of Stripes.

Note that Stripes is still in the design phase, so although code exists and can be run, the APIs are likely to change.

  • stripes-core – The UI framework.

  • stripes-sample-platform – Configuration for a sample platform and to run a local Stripes UI development server.

  • stripes-connect – Manages the connection of UI components to back-end modules.

  • stripes-components – A component library for Stripes.

  • stripes-loader – Module loader for Webpack, to enable pluggable Redux applications. This module is responsible for pulling the required UI modules into a given Stripes UI.

  • stripes-logger – Simple category-based logging for Stripes.

  • okapi-stripes – Server-side module for generating UIs based on Stripes.

  • ui-users – Stripes UI module: administrating users.

  • ui-items – Stripes UI module: administrating bibliographic items.

  • ui-scan – Stripes UI module: items check-in and check-out with simulated barcode scanning.

  • ui-okapi-console – Stripes UI module: console for administrating Okapi.

  • stripes-experiments – Testing ground for prototype modules that may form part of Stripes.

Other projects

  • folio-sample-modules – Various sample modules, illustrating ways to structure a module for use with Okapi (e.g. hello-vertx and simple-vertx and simple-perl).

  • folio-ansible – Sample Ansible playbook and roles for FOLIO (and Vagrant). Get a FOLIO installation up and running quickly. Read the docs there, and follow to build the boxes. The current built boxes are also available to download from HashiCorp Atlas.

  • cql2pgjson-java – CQL (Contextual Query Language) to PostgreSQL JSON converter in Java.

  • – The source for this website.