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). Each module has its own documentation.

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-configuration – Configuration module based on the raml-module-builder and a set of RAML and JSON Schemas backed by a PostgreSQL asynchronous implementation.

  • mod-authtoken – Filtering requests based on JWT tokens.

  • mod-login – Handles username/password login.

  • mod-login-saml – Handles SAML login.

  • mod-permissions – Handles permissions and permissions/user associations.

  • mod-users – Provides user management.

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

  • mod-user-import – Importing new or already existing users into FOLIO.

  • mod-inventory – Provides basic physical item inventory management.

  • mod-inventory-storage – Persistent storage to complement the inventory module.

  • mod-circulation – Circulation capabilities, including loan items from the inventory.

  • mod-circulation-storage – Persistent storage to complement the circulation module.

  • mod-graphql – Executing GraphQL queries.

  • mod-kb-ebsco – Broker communication with the EBSCO knowledge base.

  • mod-notes – Notes on all types of objects.

  • mod-notify – Notifications to the users.

  • mod-codex-mux – Codex Multiplexer.

  • mod-codex-mock – Codex mock module - for testing and development.

  • mod-codex-ekb – Codex wrapper for the EBSCO knowledge base.

  • mod-codex-inventory – Codex wrapper for local inventory.

  • mod-cataloging – FOLIO metadata management / cataloging module.

  • acq-models – Shared repository for the models of the various acquisition modules.

  • mod-finance – Persistent storage of finance-related data (i.e. funds, ledgers, transactions, etc.).

  • mod-orders – Persistent storage of order data.

  • mod-vendors – Persistent storage of vendor data.

  • mod-pg-embed – Helper module to start embedded Postgres. Helper for developers that starts the “embedded” postgres server and sets up the environment so that other modules can locate the database.

  • inventory-sample-data – Provides scripts for data preparation and deployment, e.g. MARC.


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.

The stripes-core documentation roadmap is the starting point. Each module has its own documentation.

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. Includes extensive documentation.

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

  • stripes-components – A component library for Stripes. Includes documentation for each library, and guides to assist their development.

  • stripes-smart-components – A suite of smart components. Each communicates with an Okapi web-service in order to provide the facilities that it renders.

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

  • stripes-form – A redux-form wrapper for Stripes.

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

  • stripes-cli – Command-line interface for creating, building, and testing Stripes UI modules.

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

  • ui-inventory – Stripes UI module: administrating locally created instances, holdings records and items.

  • ui-requests – Stripes UI module: making requests on items.

  • ui-checkin – Stripes UI module: checking in items with simulated scans.

  • ui-checkout – Stripes UI module: checking out items with simulated scans.

  • ui-circulation – Stripes UI module: Circulation.

  • ui-eholdings – Stripes UI module: E-holdings.

  • ui-search – Stripes UI module: searching, sorting, filtering and viewing records from the FOLIO Codex, an aggregation of bibliographic metadata from multiple sources.

  • ui-organization – Stripes UI module: managing organization settings.

  • ui-finance – Stripes UI module: management of ledgers, funds, and budgets.

  • ui-vendors – Stripes UI module: Vendors.

  • ui-plugin-find-user – Stripes UI plugin: User-finder.

  • ui-trivial – Stripes UI module: example application.

  • ui-developer – Stripes UI module: developer facilities, e.g. managing local developer settings.

  • eslint-config-stripes – The shared eslint configuration for stripes applications and extensions.

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

  • stripes-demo-platform – Stripes platform for building the demo site.

  • 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 Vagrant Cloud.

  • folio-install – Runbooks for FOLIO installation.

  • ui-testing – Regression tests for FOLIO UI. The testing framework is explained. Guidelines for module developers.

  • folio-tools – Various tools and support glue for FOLIO CI.

  • okapi.rb – Ruby client to communicate with an OKAPI cluster. Also known as “okapi-cli”.

  • – The source for this website.