This section provides some technical details on a few of the key server side components within

Filesets is a file-based CMS, and filesets are an important mechanism which allow different files within the CMS to be allocated to different categories, based on their file path. Fileset categories are then used to describe how a file and its contents are processed and replicated to clients, or to define user access to the contents of the fileset.

ORM provides an object-relational mapping layer as a way to represent data, other than file based content such as HTML, within the system. At its most basic, the ORM is used to map Jekyll front matter (found in source markdown files and containing meta-data about content files in the system) to meta-data tables on the client, where it can be used to perform queries on published content.

It is also possible to describe more complicated, multi-table data schemas using the ORM layer which source their data from e.g. JSON files added to the content repository, the contents of which are then replicated as relational data to mobile clients.

ACM provides a powerful access control mechanism (ACM) which provides flexible, fine-grained controls for accessing content and data published through the CMS.

Authentication methods

By default, Locomote uses HTTP basic authentication to authenticate client requests.

Filters allows authentication filters to be provided in filset definitions. These filters are JavaScript functions which are applied to the members of a fileset and can be used to rewrite the fileset according to the current user’s ACM group membership. This generally means filtering out individual members of the fileset, to prevent user access; but it is also possible to filter and rewrite the data associated with fileset members, allowing very fine-grained control over the content visible to any individual user.


The build system is used to process content added to a content repository to make it ready for publishing. The build system is an extendable, multi-step process. provides a number of standard process steps (described below), but it is easy to add more if needed.

The build process is a server side process that is automatically triggered each time content updates are pushed to a content repository.

In the standard setup, content builds are written to a separate repository branch, different to the branch that content updates are committed to. This separate branch is called the public branch, and is the branch that all ppubished repository content is taken from.


The Jekyll build step performs a Jekyll website build on content added to the repository. This reads markdown and other files in the repository, applies a Jekyll HTML theme to them, and generates styled HTML, CSS and other files which are then published to web or mobile.


The image build step is used to generate full multi-display image catalogs from a small number of source images. Source images can be placed into a directory structure, from where resized images targetting different display resolutions are generated and copied to alternative directory structures suitable for publishing to iOS or Android.


The docx build step is used to generate markdown and HTML files from Word documents which are added to the repository. This is useful for displaying the contents of Word files in a format more suitable for web and mobile. The step is capable of converting basic text formatting, images and tables to HTML.