Can you host SCORM without an LMS?
You can host SCORM without an LMS, but not on plain web hosting alone. Upload the unzipped package to any server and it will render; nothing will be recorded. SCORM expects the host to supply a JavaScript runtime API, and a static server does not. You need software that provides that API, or a format that does not need one.
Unzip a package onto a web server and the content loads normally. The manifest is ignored, because nothing is reading it. The first thing a SCO does on launch is search the window hierarchy for the object the host is supposed to have created — API in SCORM 1.2, API_1484_11 in SCORM 2004 — walking up through parent and then through opener. On a static server there is nothing to find.
What happens next is decided by the course, not the specification, and that is why the failure is so confusing. Careful content stops and says it cannot reach the LMS. Plenty of content catches the error, carries on, and behaves perfectly: pages turn, the quiz marks itself, a completion screen appears. Every value it writes goes nowhere. The call sequence, and the point at which it breaks, is walked through in the SCORM API explained.
So the question is not whether a web server can serve the files — it can. It is what supplies the runtime and the storage.
What does the LMS actually provide?
Less than most people assume, but all of it matters. Strip a platform back to what a SCORM package genuinely depends on and there are five jobs.
| Job | What it means in practice |
|---|---|
| Import | Unzip the package, read imsmanifest.xml, and work out which resource is the launchable entry point. |
| Launch | Open that entry point in a frame or window where the content can find the API object by walking the window chain. |
| Runtime API | Implement the API functions and error codes, and accept or reject each data model element the content writes. |
| Storage and identity | Keep status, score, location and suspend data per learner, keyed to a person, and hand it back on the next attempt. |
| Reporting | Turn that stored data into something a human can read: who completed, who passed, when. |
Only the first three are about SCORM. The last two are why most organisations bought an LMS at all, and they are the ones people forget to replace. A player that implements the API perfectly but has no idea who the learner is produces a tidy pile of anonymous attempts.
SCORM 2004 adds a sixth job for multi-SCO courses: reading the sequencing rules in the manifest, deciding which activity may run next, and rolling each SCO's result up into a course-level status. Single-SCO packages — most converted documents, slide decks and videos — never exercise it, which is why lightweight hosts tend to support them and stop there.
Option: a hosted SCORM player
The direct answer is to run something that does those jobs without being a full learning platform. A SCORM player is an application that imports a package, serves its files, injects the API object into the launch page, and persists the data model against whatever identity you give it. Self-hosted open-source players and hosted player services both exist; the trade-off between them is the usual one of control versus operational effort, not capability.
What to check before you commit content to one:
- Which versions it implements. SCORM 1.2 support is near-universal; SCORM 2004 support is patchier, and 2004 sequencing patchier still. Match it to the packages you actually ship.
- How identity arrives. Single sign-on, a signed launch link, an email capture form, or nothing at all. This determines whether a completion is attached to a person or to a browser.
- Whether suspend data survives. Resume is where thin implementations fail first. Test it by closing the tab mid-course and returning, rather than trusting the feature list.
- What it will hand back. A record you cannot export is a record you do not really have. Look for a per-attempt export or an API before you need it.
- How versions are handled. Replacing a course usually resets in-progress attempts. Find out what happens to them before the first update, not during.
One related pattern points the other way. If part of your audience does have an LMS, a dispatch package lets their platform import a thin launcher while the real content stays on your host, so one hosted copy serves both groups. That mechanism is covered in SCORM dispatch explained.
Option: link-launched xAPI
The other route is to stop needing the SCORM runtime at all. xAPI has no package and no API object to find: the content is an ordinary web page that posts statements over HTTPS to a learning record store. Host the page anywhere — the same static server that could not run SCORM is fine — point it at an LRS, and the tracking works, because the transport is a web request rather than a JavaScript object the host has to plant.
Two things move onto you in exchange. The first is the LRS itself, which is now the system of record for every result; what it stores and how you query it is covered in what is a learning record store. The second is identity, and it is the part that gets skipped. A statement names its actor, so something has to tell the page who the learner is and give it permission to write. That is what a launch link does — the same parameters cmi5 uses when a platform launches a unit:
https://learn.example.com/fire-safety/index.html ?endpoint=https%3A%2F%2Flrs.example.com%2Fxapi%2F &fetch=https%3A%2F%2Flaunch.example.com%2Ftoken%3Fk%3Done-time-key &actor=%7B%22mbox%22%3A%22mailto%3Aana%40example.com%22%7D ®istration=0c4b1e2a-6d9f-4a10-9b77-3c2f5d8e1a44 &activityId=https%3A%2F%2Fexample.com%2Fcourses%2Ffire-safety
Without an LMS, you write the small service that mints those links: it authenticates the person, calls the LRS for a scoped credential, and redirects. It is a modest amount of code, but it is code someone has to own, and it is the difference between attributable records and a pile of anonymous statements.
What you keep and lose
The three approaches are not better and worse versions of each other. They move work around.
| LMS | SCORM player | Link-launched xAPI | |
|---|---|---|---|
| Runs existing SCORM zips | Yes | Yes | No — content must be rebuilt or converted |
| Who the learner is | Enrolment records | Whatever the launch supplies | Whatever the launch link asserts |
| Resume and bookmarking | Data model, per SCO | Data model, if implemented properly | State API, if the content uses it |
| Reporting out of the box | Yes | Usually basic | LRS queries; often a dashboard you build |
| Enrolment, reminders, compliance | Yes | No | No |
| Detail captured | Status, score, one suspend string | Same | Any event you choose to send |
| Work you own | Administration | Hosting and identity | Hosting, identity, LRS and reporting |
Read down the last row and the pattern is clear: the lighter the host, the more of the surrounding job lands on you. A fair trade for a public course with anonymous learners; a bad one for compliance training an auditor will ask about.
Choosing an approach
Four questions settle it in most cases.
- Does a result have to belong to a named person? If yes, identity is the requirement to design around first, whichever route you take. If the content is genuinely public and you only want completion counts, a player with anonymous sessions is enough.
- Do you already have the packages? Finished SCORM zips, especially ones you cannot rebuild, point at a player. Content you are still authoring is free to go the xAPI route and skip the runtime entirely.
- Will anyone audit this? Regulated or contractual training needs exportable, attributable records with dates. Check the export path before you upload the first course, not the first time someone asks for evidence.
- Who maintains it in a year? A player is one moving part. An xAPI setup is a page, a launch service, an LRS and a report. Both are manageable; only one of them is manageable by accident.
One thing does not change. Whatever hosts the package still has to accept what it sends, and packages differ — status before score, a suspend string near the cap, a commit at the wrong moment. Watching a real runtime session against your chosen host, before learners see it, catches this in every setup.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.