CourseLit: a self-hosted LMS for selling courses from your own site

The problem CourseLit addresses: renting your storefront versus owning it

Most course platforms are rented. You write the lessons on someone else's domain, you pay a monthly fee that scales with your revenue or your student count, and if the pricing changes you either absorb it or migrate. CourseLit takes the opposite position. The README describes it as an open source alternative to Teachable, Thinkific, Podia and similar products, and the pitch is that you sell courses and digital downloads from your own website. The repository topics list self-hosted first among the relevant tags.

The audience is narrow and specific. It is not the instructor who wants to upload a video this afternoon. It is the instructor who already has a domain, is willing to run a Node application and a MongoDB database, and wants the sales page, the checkout and the course player to live on infrastructure they control. CourseLit also carries a blog and CMS surface, which matters if you want the marketing site and the product in one codebase rather than a course platform bolted onto WordPress.

How CourseLit is put together: a pnpm monorepo with a media service on the side

The repository is organised as a monorepo, and the README says it uses pnpm workspaces to manage it. The top level splits into apps/, packages/, services/ and deployment/, with a pnpm-workspace.yaml and a lockfile at the root. The root package.json declares workspaces for packages/* and apps/*, and the dev script is filtered: pnpm --filter @courselit/web dev. So the runnable application is the web app, and the packages directory holds the shared modules it consumes.

One architectural decision is worth calling out because it is the biggest external dependency. CourseLit does not store media itself. The README states it uses MediaLit as its backend for managing media assets, describes that service as paid, and says you need an account on it to store files in the cloud. There is an escape hatch: setting MEDIALIT_SERVER to a self-run instance in the .env file points the app at your own deployment. That is a real trade-off rather than a detail. A self-hosted LMS that outsources file storage still has an external dependency, and the README does not document what happens to existing media if that dependency becomes unavailable.

Database migrations follow a similarly manual philosophy. They live in apps/web/.migrations, are named DD-MM-YY_HH-MM-<migration-purpose>.js so they sort chronologically, and the README describes them as complete scripts you run yourself rather than a framework-managed migration runner.

Installing CourseLit for development and running it locally

The README gives two paths. The cloud hosted version at courselit.app offers a free account with a 14 day trial and no credit card, which is the fastest way to see the product. Self-hosting follows the official guide at docs.courselit.app/en/self-hosting. For local development the README is explicit: clone the repository, cd into it, then edit the .env file inside apps/web with your environment's configuration before running anything.

From the repository root, the three commands are:

# Install dependencies
pnpm install

# Build the packages
pnpm build

# Start the app
pnpm dev

pnpm install resolves the workspace, pnpm build compiles the packages the web app depends on, and pnpm dev starts the web application. The README notes the project pins [email protected] in the packageManager field, so a mismatched pnpm version is a plausible first failure.

There is also a Vercel deploy button in the README that clones the repository with the root directory set to apps/web. It asks for DB_CONNECTION_STRING, AUTH_SECRET, SUPER_ADMIN_EMAIL, EMAIL_USER, EMAIL_PASS, EMAIL_HOST and EMAIL_FROM, and its build command sets NODE_OPTIONS=--openssl-legacy-provider before running yarn build. Note the mismatch: the documented local workflow uses pnpm, while the deploy button's build command uses yarn. If you take the Vercel route, that is the command that will actually run.

Once the app is up, the README points at codelit.dev as a live example of what a CourseLit site can look like. The admin dashboard screenshot in the repository shows the authoring surface: courses, a website builder and analytics, which the README itself describes as very limited as of now.

Where CourseLit will frustrate you

The migration workflow is the clearest example of a design choice that trades convenience for transparency. The README does not provide a migration CLI. Instead it tells you to create a blank Node project, install mongoose and nanoid, copy the migration script into that folder, and run it with the database connection string passed as an environment variable:

DB_CONNECTION_STRING=mongodb://<mongodb-url> node migration-script.js

The README is candid about this, saying you need some development chops, though not much. That is honest, but it means upgrades are not a single command, and the README does not document rollback. If a migration script fails halfway, the documentation is silent on how to recover.

Media storage is the second constraint. Because MediaLit is a separate paid service, a fully self-contained deployment is not the default. You can point MEDIALIT_SERVER at your own instance, but the README does not describe how to run that instance, so the escape hatch is really a pointer to another project rather than a documented path.

Analytics is the third. The README says the platform includes analytics and immediately qualifies that they are very limited as of now. Anyone leaving a hosted platform for its reporting will find less here, not more. And if you want a managed product with a support contract, CourseLit is simply the wrong category of tool.

How CourseLit differs from Moodle, Open edX and the hosted platforms

The related searches around this project surface Moodle, Open edX, LearnHouse and ClassroomIO, which is a fair comparison set. Moodle and Open edX are institutional LMS products. They are built around cohorts, enrolment, grading and academic administration, and they are typically deployed by an IT department rather than a solo instructor. CourseLit inverts that emphasis. Its README leads with selling, payment processing via Stripe, custom sales pages and a website builder. The learning features exist to support a commercial transaction, not to run a semester.

The hosted platforms are the other axis. Teachable, Thinkific and Podia give you a working storefront in an afternoon and take a cut or a subscription in return. CourseLit asks you to supply the deployment, the database and the media backend, and gives you the code under AGPL-3.0 in exchange. The difference is not feature parity. It is who holds the operational burden and who holds the customer relationship.

Against LearnHouse and ClassroomIO, which also appear in the search data, the distinguishing detail visible here is breadth: CourseLit ships a blog and CMS alongside the course tooling, so one application covers the marketing site and the product. Whether that is an advantage depends on whether you wanted a CMS.

Licence and the cost of staying current

The repository's package.json declares MIT, while the repository metadata and the README's licence badge point to AGPL-3.0. That discrepancy is worth resolving with the project before you build a commercial product on it, because the two licences carry very different obligations for anyone offering the software over a network. This is a factual gap in the project's own files, not a legal opinion, and it is the kind of thing you should confirm rather than assume.

The upgrade cadence is visible from the release history. Three releases between June and July 2026: v0.73.15 for course previews, v0.74.0 for course discussions, and v0.74.2 for reactions on community posts and comments. That is a steady stream of small feature releases, and the last push to the repository was on 2026-09-10, so the codebase is moving. Frequent releases are good for features and bad for upgrade cost, because each one may bring a migration script you have to run by hand. The root package.json includes a changeset workflow (pnpm exec changeset) for publishing packages, which tells you the maintainers treat releases as a routine, automated process on their side. The work of applying them lands on you.

Budget for that. A self-hosted CourseLit deployment is not a set-and-forget install; it is an application you will revisit whenever a migration directory gains a new file.

Editorial conclusion

Adopt CourseLit if you are comfortable with a Node and MongoDB stack and want the storefront, the course player and the checkout under one roof you control. Do not adopt it if you need a managed installer, a support contract or a hosted media pipeline without a third-party account. Before committing, read the self-hosting guide at docs.courselit.app, check the docker-compose.yml under deployment/docker for the full environment variable list, and confirm whether your deployment will use the hosted MediaLit service or a self-run instance via MEDIALIT_SERVER.

Frequently asked questions

Official sources

1. codelitdev/courselit on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases