Adapt Authoring Tool: a server-side course builder for the Adapt e-learning framework

What the tool is for, and what it is not

The Adapt authoring tool is a web-based user interface for the Adapt Framework, and its purpose is stated precisely: use it to create responsive, single-version HTML5 e-learning courses for delivery on a web server or a SCORM-compliant learning management system.

Those three words in that sentence are the design. Responsive means one build works on a phone, a tablet and a desktop. Single-version means there is no separate mobile course to maintain. HTML5 means the course is web technology rather than a packaged format, with the consequence that delivery to a web server and delivery through SCORM are two ways of hosting the same content rather than two things you build.

The framework itself is described as a free and easy to use framework and authoring tool that creates fully responsive, multi-device HTML5 e-learning content, and there is a public demo of what the output looks like.

So the tool is a front end for a specific framework, not a general course builder. That distinction is what makes it worth examining rather than dismissing. A general course builder produces a proprietary package, and a framework produces a directory of files you can host yourself, version, diff and integrate with your own systems. The authoring tool is the piece that lets a non-developer produce what the framework consumes.

The features list is short and tells you the shape of the thing. It is a web application built on Node.js, Backbone.js and MongoDB for creating, editing and publishing Adapt content. It supports all core extensions and components, which is the sentence that matters most, because a course can then use the whole framework. And it allows uploading and linking of course assets, which is the part of course building that turns into file management work in a hand-rolled setup.

The licence is the GNU General Public License version 3, the primary language is JavaScript, and the project homepage is adaptlearning.org.

The server side, and what the dependencies reveal

The repository is a Node.js application in the conventional shape, and the tree shows how it is arranged. There is index.js and server.js at the root, a lib/ directory for the application code, routes/ for the HTTP layer, a frontend/ directory, a plugins/ directory, a conf/ directory for configuration, a migrations/ directory, a test/ directory, and three top-level scripts: install.js, upgrade.js and the Gruntfile.js that drives the build.

The package metadata shows the server stack. Express 4 provides the HTTP layer, with body-parser, cookie-parser, method-override and compression alongside it, and express-session with connect-mongodb-session for sessions held in MongoDB rather than in memory. consolidate and handlebars are the view layer, and the Grunt plugins for handlebars and requirejs show that the front end is built with Handlebars templates and RequireJS modules, which matches the Backbone.js description in the feature list.

Two dependency groups are worth calling out because they explain specific behaviours. The password hashing uses bcrypt-nodejs, which is a pure JavaScript implementation rather than a native binding, and that choice keeps the install free of a compilation step at the cost of speed. The media handling uses ffmpeg-static and ffprobe-static with fluent-ffmpeg and archiver, which is how the tool deals with uploaded video and produces packaged course output.

The migration tooling is the other notable piece. The package scripts are:

  "scripts": {
    "test": "grunt test",
    "create-migration": "npx migrate-mongo create -f conf/migrations.js"
  }

migrate-mongo is in the dependency list, and the create-migration script scaffolds a new migration from a configuration file in conf/. For an application that stores authored courses in MongoDB, that means the stored document shape can change over time without losing existing courses, which for a tool that people have invested hundreds of hours of authoring time in is the difference between a version bump and a migration weekend.

The engines field requires Node 22 or newer, which is a modern floor for a project whose earlier releases predate it, and the test suite is driven by Grunt with mocha, run through grunt test.

Publishing to a web server or into an LMS

The delivery target is where the authoring tool's output becomes an operational question, and the documentation is explicit that the same course can go either way.

Delivery on a web server means the course is hosted as files and reached by a URL, which fits an organisation that has its own hosting and its own user accounts, and which is the natural fit for a framework whose content is HTML5 rather than a packaged format.

Delivery to a SCORM-compliant learning management system means the course is packaged so an LMS can launch it, track it and record the result. That is the requirement in most corporate and academic training contexts, and it is why the tool supports producing both from the same authored content rather than making the author decide at the start.

The consequence for an authoring team is worth spelling out. Because a course is a single version that is responsive rather than a set of device variants, the authoring work does not multiply per platform, and the delivery work does not either. The same JSON content and the same assets are what get published, and the difference between web and SCORM delivery is a packaging and hosting decision rather than a content decision.

The asset handling is what makes that practical. Uploading and linking course assets is listed as a feature, and the server-side media stack is what supports it. In a hand-built course you would end up with a folder of media files, a manifest of paths, and a rule that the paths are relative and survive being moved to a different server. The authoring tool keeps the course and its assets in a repository in MongoDB and the filesystem together, so the linkage is maintained as part of the content rather than being re-established by hand each time something moves.

The upstream framework is a separate repository, adapt_framework, and the documentation points at the authoring tool's own wiki for the full set of guides, including installation, course authoring and developer guides, so the details of the content model live there rather than in this repository.

The community around it, and where the project sits

The authoring tool is one part of a larger project, and the surrounding communication channels are documented in detail.

There is a community site, a technical forum for troubleshooting, a dedicated responsive e-learning forum, a Gitter channel, a Twitter account, and GitHub issues for bugs and for feature requests. What matters is that the technical forum and the issue tracker are separate destinations: the forum is for troubleshooting and discussion, and issues are for reporting bugs and giving feedback, which is the split you want in a project with a real user base.

The contribution route is documented in the repository, in CONTRIBUTING.md, and the tooling in the tree supports it: a .travis.yml for continuous integration, a Gruntfile.js for the build and the test task, a CHANGELOG.md, an INSTALL.md, an .editorconfig, and a package-lock.json for reproducible installs.

The release history shows a steady but unhurried project. The tags are v0.11.5 from 2025-01-15, v0.11.4 from 2024-11-05 and v0.11.3 from 2024-02-23, and the last push to the repository was on 2026-08-04. The version is still below 1.0, which is common for an application whose data model lives in a database that its users have to keep across upgrades.

The team is the Adapt Learning organisation, and the framework and the authoring tool are versioned separately, which is a detail that matters for anyone pinning versions: the authoring tool has to be compatible with the framework version it produces content for, and the compatibility notes live in the wiki rather than in the repository.

Where the Adapt authoring tool is the wrong tool

The first limit is the commitment to the framework. The tool authors Adapt content and nothing else. If your organisation has standardised on a different authoring tool, or on hand-built HTML, this produces content that only the Adapt framework can run, and the cost of switching later is a re-authoring rather than a migration. That cost is the price of a framework, and it is only worth paying if the framework's other properties, the responsive single-version output, the plugin ecosystem, the SCORM packaging, are worth it to you.

The second is that it is a server application with a database. Running it means Node 22 or newer, a MongoDB instance, a place to store the uploaded assets, and a way to back all of it up. A team that wants an authoring tool for one course does not want to operate a service, and for a small number of courses the framework's own file format is often the simpler route, because a course is a directory of JSON and assets that can be edited directly and version-controlled.

The third is the interface's age. The front end is Backbone.js with Handlebars templates and RequireJS modules, and the server is Express 4. That is a coherent stack and it is what the project has used for years, but it is not a modern reactive front end, and a user interface that a designer has to extend will be extended in a 2015-era framework. The tool is a service for instructional designers rather than a component you can drop into a modern design system.

The fourth is the version below 1.0 combined with a database. A tool that stores your work in MongoDB and whose schema has to be migrated between versions is a long-term dependency, and the migration tooling is what makes it manageable, but the discipline of running the migrations and backing up the database belongs to the operator. The authors of hundreds of hours of course content are the ones who feel a mistake.

And the fifth is the media pipeline. ffmpeg-static and ffprobe-static with fluent-ffmpeg means the tool processes uploaded video itself, which is convenient when it works and is another moving part to monitor when a new ffmpeg release changes behaviour. It also means the server needs enough disk and CPU to handle whatever your authors upload.

Editorial conclusion

Adapt Authoring Tool is worth running if your organisation already produces Adapt content, because a web authoring interface is what makes the framework usable by instructional designers rather than only by developers, because the tool supports all core extensions and components so a course can use the full framework rather than a subset, and because the course and asset handling, including video processing, is handled by the server rather than by each author's workstation. It is the wrong tool if you are not committed to the Adapt framework, and it is the wrong tool for a one-off course. Before you deploy it, check three things: that you have Node 22 or newer, since that is the engine requirement in the package metadata, and a MongoDB instance to store the courses; that you read the installation instructions in the project wiki, because the repository ships an install.js, an upgrade.js and a migrations directory, and the presence of a migrate-mongo script means a schema change to the stored courses is a migration rather than a manual step; and that you look at the release history before planning, because the tags are v0.11.5 from 2025-01-15, v0.11.4 from 2024-11-05 and v0.11.3 from 2024-02-23, so the project is on a zero major version with a steady but slow cadence.

Frequently asked questions

Official sources

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