How to set up Open edX discussion forums for a course team
Discussions in Open edX are a separate deployment and configuration piece that sits on top of the LMS and Studio, so plan them as their own workstream and do not assume they arrive with the course content. The key early decision is whether your course teams will use the native forum application or an LTI discussion provider, because that choice determines which services you run, where learner posts are stored, how moderators sign in and what you must back up. Make this decision before courses are built, since moving threads and re-linking course pages later is far more work than choosing correctly at the start.
The forum depends on the same foundations as the rest of the platform. The Open edX platform (edx-platform) is licensed under the GNU Affero General Public License version 3 and is built on Python, JavaScript and Django. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, and that recommendation is the practical starting point for most teams. Development requires Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached. Multi-node deployments also need a shared Django cache backend such as Redis or Memcached, so every node reads the same cached state. Confirm each version against the release you plan to run, because Open edX states that only the latest named release is supported.
If you deploy with Tutor, treat the forum configuration as code. Tutor is the official Docker-based Open edX distribution for production and local development, and it supports Kubernetes deployments and plugins. Capture the forum settings, any plugins and the LTI provider connection in your Tutor project so the build can be repeated in staging and production. Before you commit, check the release notes for your target release. The Verawood release notes cover the Studio sidebar, the instructor dashboard, the AI Extensions Framework, taxonomy management and LTI Advantage Complete certification. Confirm with the release notes and your own test environment whether anything there touches the forum or LTI settings you plan to use.
Write a decision record before any installation. It should name the forum option, the target release, the MySQL and cache topology, the people who will moderate, the people who will receive notifications and where backups are stored. Ask any prospective partner to state which of these items they will verify in your environment and what they will hand over, such as the Tutor project, configuration notes and a test plan using a staging course. Cost has two parts: the one-time work of deciding, configuring and testing, and the recurring work of upgrades and monitoring. Ask for a written scope that separates the forum build from course authoring, so each cost can be compared with your own team's effort.
What the forum module does in Open edX
This section maps the forum capabilities that the official docs and release notes for your named release should confirm. Each card names one capability area, what it affects for course teams and learners, and what to verify before you commit to a configuration.
Where discussions appear in courses
Discussion threads are attached to course content, so the first check is which course locations expose a discussion component and how learners reach them. Confirm in the docs for your release whether discussions appear in the course outline, inside units, or in a dedicated area, and whether course teams can turn discussion on or off per course. Verify the layout in a staging course before you promise a structure to course teams, because placement can differ between releases.
Thread and response structure
Confirm how the forum organizes posts: threads, responses, nested comments, and any topic categorization that course teams can configure. Record the nesting depth, sorting and search options, and whether learners can follow threads or group them by course section. These details shape how quickly learners find answers and how much reading staff must do, so ask course designers to review a sample thread on the release you run.
Staff moderation controls
List the actions that course staff, community moderators and administrators can take on posts and users, including editing, removing, and closing threads, and confirm each one in the docs for your release. Check which roles hold each permission, how moderators are assigned to a course, and whether moderation activity is logged. Map each action to a named role in your moderation policy before launch, since permission sets can change between releases.
Notifications and learner alerts
Identify which forum events generate notifications, such as a reply to a learner's post, and which channels deliver them. Notifications depend on the forum service and on the email delivery configuration in your environment, so confirm both the event list in your release's documentation and the outbound mail setup. Test with learner accounts on a staging site to check delivery and opt-out behavior before course launch.
Forum service and database dependencies
The native forum runs as a Python application backed by MySQL, so its service version and database version must match the Open edX release you run. Confirm the supported versions in the release documentation, and list every data store the forum uses so each one is backed up and included in upgrade and restore plans. Schedule forum upgrades with the LMS upgrade rather than treating them as separate projects.
LTI discussion provider alternatives
Decide whether the native forum covers your requirements or whether an LTI discussion provider should host discussions for specific courses. An external tool brings its own moderation, identity and data hosting model, so its capabilities and location need the same verification as the native forum. The Verawood release notes list LTI Advantage Complete certification among its additions, so confirm in those notes what that certification covers for any tool you evaluate.
Configuration decisions before the forum goes live
This table compares the main configuration choices for course discussions in Open edX: the forum engine, discussion scope, moderator roles and notifications. Read each row for when an option fits and what it costs to change after learners have posted. The main takeaway is that the engine, scope and moderation choices are the hardest to reverse once threads exist, so settle them in the written scope before the build starts.
| Decision | Option | When it fits | Cost to change later |
|---|---|---|---|
| Forum engine | Native Python forum application on MySQL | Discussions should live inside the LMS, with one platform to back up and operate | Moving to another engine means exporting posts and mapping users and course identifiers. Confirm the export path before launch. |
| Forum engine | LTI discussion provider | The institution already requires an external discussion tool, or the team wants that vendor's features | Learners and grades cross two systems, so identity, launch configuration and course links must be reworked if the provider changes. Confirm the provider's data retention terms. |
| Discussion scope | Course-level discussions | Each course runs its own cohort and moderators work within one course team | Converting later means reassigning existing threads course by course and checking settings in every course. |
| Discussion scope | Program-level discussions | Learners take linked courses and the program needs one community across them | Splitting or merging communities later affects thread history and moderator access across course teams. Confirm how the platform groups threads across courses. |
| Moderator roles | Course staff and designated moderators who can edit or remove posts | A small, named team handles moderation and edits must be traceable | Changing who holds edit and remove rights is a configuration change, but past actions remain in the record. Confirm whether edits and deletions are logged and who can view the log. |
| Notifications | Default on or off for each notification channel | Learners are expected to act on replies quickly, or the program wants low-noise defaults | Changing defaults after launch does not override preferences learners have already set. Decide defaults before enrollment opens and confirm which channels the release supports. |
Why the forum data layer decides the build order
The forum application's data store and cache have to be running and reachable before course content is loaded. Discussion threads are tied to course and unit identifiers, so a course imported before the forum service can write to its store leaves the team reconciling records later. Treat the forum data layer as a prerequisite stage in the build plan, not as a feature to switch on after the LMS and Studio are working. Ask the implementation team to show the order in writing, with each store and cache listed as a dependency of the first course import. The edx-platform development requirements list MySQL 8.0 and MongoDB 7.x, along with Memcached. That list does not settle which store holds forum data in your deployment. Confirm this with the forum application documentation for the named release you are installing, and record the answer in the architecture decision log. If the answer differs from what your team expects, the provisioning, backup and upgrade plans for that store change with it.
Multi-node deployments need a shared Django cache backend, such as Redis or Memcached, so that every LMS, Studio and forum worker reads the same cached state. A node that caches locally can serve stale enrollment, permission or thread data to learners on other nodes. Choose the cache backend before the second application node is added, because moving a live cache is harder than configuring it at the start. Confirm the backend's size, eviction behavior and failover approach with your operations team as part of the same decision. The cache is a separate failure domain from the data store. If it goes down, the platform may slow or show inconsistent results even while the database is healthy, so monitoring should cover both.
Before any course content is loaded, run a short set of checks that confirm the dependency order holds. From each application node, connect to the forum data store using the client and credentials for your release and confirm the connection succeeds. From every LMS, Studio and forum node, confirm that the shared cache backend answers and that a value written from one node is readable from another. Confirm the exact store and cache versions against the requirements for your release. Next, create a test course with one discussion unit and a test thread, restart one application node, and confirm the thread and its author are still present. Record the results, the versions and the owner of each store in the build log. Only then should the course content load begin.
The same checks should be repeated after each upgrade or topology change, such as adding a node or moving the cache to a managed service. Ask the implementation partner to include these checks in the written scope and deliverables, and ask your team to name who owns the backup and restore process for the forum store. Those owners will need to know the order of dependencies when they respond to an incident.
Build sequence for forum deployment and course enablement
The sequence moves from a verified data store and runtime foundation to a configured forum, tested moderation and notifications, a pilot course and a learner review, ending in a handover your team can operate. Each step closes with a named artifact, so you can see what exists before the next step starts. It applies to a self-hosted Open edX platform in infrastructure you control.
Confirm environment and data store readiness
DeployOpen checks the target environment against the Open edX requirements for your chosen release: MySQL 8.0 for the relational store, MongoDB 7.x where the release still requires it, Memcached or Redis as a shared Django cache for multi-node deployments, and the Python and Node.js versions for any build work. Your team confirms network paths, backup targets and secrets storage, and confirms the forum's own data store requirements against the documentation for the release you run. Done when a readiness checklist is signed off by both parties and every dependency has a named owner and a verification result.
Deploy the forum service to staging
Deploy the Python forum application alongside the LMS and Studio in a staging environment that matches the production topology, using the deployment method agreed in scope. Verify that the forum connects to MySQL, that threads and comments can be created, read, edited and deleted, and that learner and staff sessions pass through correctly. Keep the environment definition in version control so every later change can be traced. Output: a tested forum environment with a deployment record, health check results and a list of known issues that the client has accepted.
Configure forum settings and course defaults
Set the forum options that shape course discussion: the default discussion topics and categories, moderation options the release supports, how course teams are identified, and what learners see when discussions are disabled for a course. Record every setting and default in a configuration document kept with the code, and have the course operations lead approve each value. Output: an approved configuration record and a discussion setup guide for course teams.
Set up moderator roles and a runbook
Map the moderator, course team and staff permissions your policy requires onto the roles the forum supports, then test each role with test accounts in staging. Confirm who can edit, hide, pin or close threads, who can see reported content, and how learner identity appears in moderation views. Write a moderator runbook covering escalation paths, removal criteria, handling of personal data in posts and out-of-hours coverage, then have your legal or safeguarding owner review it. Output: a role matrix tested in staging and a signed-off moderator runbook.
Test notifications and sign off the matrix
Trigger each notification the forum sends, such as replies to a learner's post, mentions, moderation actions and any digest messages the release enables. Record the sender, recipient, timing and content for each one, and check mail delivery through your relay and unsubscribe handling. Confirm that no notification exposes post content to a user who should not see it. Consolidate the results into a notification matrix and ask the course operations lead and the privacy owner to sign it. Output: a signed-off notification matrix with pass or fail results and links to the fixes.
Enable and run a pilot course
Enable discussions in one pilot course, chosen with the course team for its size and enrollment mix. Load the course content, seed a small set of test learners and staff, and run the moderator runbook against representative activity across the course schedule. Log issues by severity, track which ones block launch, and confirm that any course reporting you rely on still shows discussion activity. Output: a pilot report with an issue log and a go or no-go recommendation for the remaining courses.
Review with learners and hand over
Run a short review with a small group of enrolled learners and instructors, covering how they find a discussion, post, search, receive replies and report content. Fix the issues that block use, record the rest in the backlog, and confirm your team has run accessibility checks on the discussion pages. Then hand over the configuration record, moderator runbook, notification matrix, pilot report and support model to the team that will operate the forum, with a walkthrough of each item. Output: a handover pack and recorded acceptance by the operating team.
What drives forum implementation effort and cost
This table lists the main factors that change the work for Open edX discussion forums, how each one raises or lowers effort, and how to contain it. Use it to frame a quote request, since most drivers are set by decisions made before the build starts. The main takeaway is that the forum work itself is usually smaller than the decisions around moderation, identity and upgrades that surround it.
| Driver | Effort effect and how to contain it | One-time or recurring |
|---|---|---|
| Number of courses and cohorts | Each active course and cohort adds discussion content, moderation scope and support questions. Contain it by agreeing which course runs use forums and by setting a naming and archiving convention before launch. | Setup is one-time; moderation load recurs with each run |
| Per-course or shared discussions | Per-course threads keep moderation local but multiply admin work across runs. Shared topics reduce duplication but need clear ownership. Decide the model with course teams before configuration. | Configuration is one-time; moderator time recurs |
| Custom moderation rules | Rules beyond the built-in flagging and roles need design, testing and documentation, and they must be re-checked at each upgrade. Keep rules few, written down and tested against sample threads. | Design and testing are one-time; rule review recurs with upgrades |
| Notification volume and channels | Email digests and per-thread alerts grow with enrollment and activity. Confirm which notification types the release provides and limit channels to what the learner audience needs. Test volume with a realistic sample before launch. | Configuration is one-time; mail volume and deliverability checks recur |
| SSO and identity mapping for moderators | Moderators need roles that match identity-provider groups. Mapping rules differ by provider (OAuth2, SAML 2.0, Shibboleth or LTI). Confirm the provider and the group attribute names early, and keep mappings in version control. | Mapping is one-time; access reviews and group changes recur |
| Chosen release and upgrade cadence | Open edX supports only the latest named release, so every upgrade retests forum behavior and moderation rules. Verawood is the current named release, with Willow and Xylon listed for later dates. Plan upgrades on the published schedule and budget for regression tests each time. | Initial release choice is one-time; each upgrade recurs |
| Number of environments | Each extra environment (development, staging, production) needs its own configuration, data seeding and test runs. Keep environments built from the same Tutor configuration to avoid drift, and limit test data copies that contain learner content. | Environment build is one-time; refresh and sync recur |
| Database and cache sizing | The forum application runs on MySQL, and multi-node deployments need a shared Django cache backend such as Redis or Memcached. Heavier thread volume raises load on both. Confirm sizing and backup scope before go-live. | Sizing and setup are one-time; backups and capacity reviews recur |
How forums connect to the rest of the Open edX platform
Course discussions read from and write to the LMS, Studio, identity, cache, database and analytics layers at the same time. A change in any one of them can alter what a learner sees in the forum, so each dependency needs its own check after every change.
LMS course experience
Learners reach course discussions from the LMS course pages, and course staff reach the same threads through instructor tools. Forum threads are associated with the course key, so a rerun, a new course key or a copied course can change which threads a learner sees. After any change to course runs or enrollment, sign in as a test learner and a staff account, open the discussion area of the course, post a thread, reply to it and confirm it appears under the correct course.
Studio content authoring
Course teams build course structure in Studio, and the LMS serves what Studio publishes. Discussion settings and any course content that prompts discussion are authored here, so an unpublished draft can differ from what learners see. Confirm which discussion-related settings your chosen release exposes in Studio. After a publishing change, check that the LMS discussion area still loads for the course and that the discussion settings saved in Studio match what the LMS shows.
Identity and single sign-on
Open edX third-party authentication supports OAuth2 providers (Google, Facebook, LinkedIn and Azure Active Directory by default), SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. The identity record determines the account a learner posts under and whether staff forum roles match the right person. After any change to a provider or attribute mapping, sign in through each provider, post a thread, confirm the display name and check that moderator and staff permissions still apply to the correct accounts.
Shared cache layer
Multi-node deployments need a shared Django cache backend, such as Redis or Memcached, so every application server reads the same cached state. If nodes keep separate caches, a post may appear on one server and not another, and a moderation action may take effect late. After any cache change, post on one application node, read the thread from another node, hide or edit a post as a moderator, and confirm the change appears on every node within the expected window.
Database layer
Open edX development requires MySQL 8.0 and MongoDB 7.x alongside Memcached. The forum application keeps its threads, comments and moderation records in MySQL, so a database restore, schema migration or version change affects forum data directly. Confirm the MySQL and MongoDB versions your Tutor release expects before you upgrade. After a restore or migration, compare thread and reply counts and spot-check reported posts and moderation history against a known baseline.
Analytics through Aspects
If the client runs Open edX Aspects, the event-routing-backends plugin captures tracking logs as xAPI statements, stores them in ClickHouse through Ralph or Vector, and presents them in Superset dashboards. Forum activity reaches these dashboards only when the relevant events are emitted and routed. Confirm which forum events your release sends. After enabling or changing the routing, create a test thread and reply, then confirm both events arrive in ClickHouse and appear in the Superset dashboard within your pipeline's normal delay.
Moderation and notifications that learners and staff can rely on
Moderator roles, post review, escalation paths and learner notifications form one system, so they should be designed together before the forum opens to learners. A flagged post needs a reviewer who can see it, a route to someone with more authority when the matter is serious, and a notification that tells the right people what happened. If one of these is decided late, the others usually inherit the gap. In Open edX, confirm the discussion roles available in your release, such as the discussion administrator, moderator and community TA roles, and map each one to a named staff responsibility on paper before anyone is granted access.
The client owns the moderation policy. DeployOpen configures and tests the technical controls, but it cannot decide what your organization treats as acceptable use, how quickly a flagged post must be reviewed, or who handles reports that involve a minor or a learner at risk. Settle these decisions before sign-off and write them in a form that staff can apply without interpretation. The list includes the acceptable use rules and their consequences, review response times by severity, the named safeguarding owner and a deputy for absences, whether moderators can remove content or only hide it, how long flagged content and moderation records are kept, and who may view them. Legal, safeguarding and HR teams should approve these decisions.
Confirm which notification types exist in your Open edX release and how each one is delivered before you write notification rules. Delivery channels, such as email, on-platform messages or digests, depend on your release and your configuration, so test them in a non-production environment and do not rely on documentation alone. Ask which events notify learners, which notify moderators, whether a learner can control what they receive, and whether outbound mail uses the sending service and domain you have approved. Also confirm how a reply or new activity on a thread reaches the person who started it. Give each notification an owner and an expected volume, because an unplanned flood of emails to moderators is a common reason response times slip.
Test the full path before launch using test accounts for each moderator role and for a learner. Flag a post as a learner, confirm that the reviewer queue shows it, escalate it as a moderator, and check that the safeguarding contact receives the notification and can act on it. Repeat the test in a course staffed by a different team to confirm that moderators cannot see content outside their scope. Record every result, including what failed. Then write a short runbook that lists each role, its duties, its response time and its escalation contact, and assign an owner to keep it current. Review moderation volumes and response times after the first live term and adjust staffing and rules. Reviewer time is the recurring cost most likely to grow, so ask for it to be quoted as a separate line.
Questions teams ask before they hire help with Open edX forums
What drives the cost of an Open edX forum setup project?
Cost follows the scope agreed in writing, and the largest drivers are the number of environments, how many course and learner systems the forums must connect to, and how much moderation and notification behavior you need to customize. Most engagements are fixed-scope, so the quote lists deliverables before work starts. Cost splits into one-time work (design, deployment, configuration, testing and handover documentation) and recurring work (hosting, upgrades, monitoring and any moderation support you buy). Ask the vendor to separate these lines, state which environments are covered and name who performs user acceptance testing. DeployOpen does not publish a price list, so the written scope is the basis for any quote.
How long does an Open edX discussion forum deployment take?
Duration depends on scope, the state of your existing Open edX environment and how quickly your staff make decisions and test. A deployment of the native forum on an existing, supported install is usually shorter than a project that adds a new hosting stack, an identity integration or custom moderation workflows. Plan time for infrastructure readiness, which often takes longest when cloud accounts or network approvals are involved, and for a test cycle run by course staff. The written scope should carry milestones tied to your approvals and list the dependencies the timeline assumes. Ask which late client inputs would move the date.
What must our team provide before outside help starts on forums?
Before work begins, your team should provide the following:
Environments: non-production and production hosts or clusters in your accounts, with access for the delivery team. Identity access: the sign-in source, admin roles and test learner accounts, with approval to use them. Moderation policy: who can flag, hide, pin and delete posts, what escalates and how long reviews may take. Course data: course structures and enrollment samples for testing, handled under your data policy. Staff for testing: instructors and moderators who run test threads and sign off on results.
Missing any of these usually moves the schedule, so list them in the scope and assign an owner to each.
Can an internal team set up Open edX forums without an outside partner?
Yes, if your team already runs Python and Django services, MySQL and a shared cache, and has people who can carry out Open edX upgrades. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Tutor, the official Docker-based distribution, is the practical path for most internal teams and supports Kubernetes deployments and plugins. Check three things: whether someone can own the MySQL 8.0 and cache layers, whether someone will track each named release and who handles moderation tooling after launch. Outside help is most useful where those gaps exist.
When does an LTI discussion provider replace the native Open edX forum?
Consider an LTI discussion provider when course teams already run discussions in a tool with moderation, analytics or notification features that the native forum would need custom work to match, or when one discussion tool must serve several learning platforms. The provider launches from course content through LTI, so confirm which launch, grade and identity data it receives, where it stores posts and how learners from your identity source are matched. Keep the native forum where course discussions must stay inside the LMS and your data policy. Ask for a written comparison covering moderation, notifications, data location and the cost of running a second system.
What ongoing work follows a forum launch in Open edX?
Ongoing work is mostly keeping the platform on a supported release, watching notification and moderation behavior, and maintaining backups and the cache layer. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time, so each platform upgrade carries forum changes you must test. Verawood is the current named release, and its release notes should be checked for forum-related items before any upgrade is scheduled. Recurring costs include hosting, monitoring, upgrade testing and any moderation staffing you pay for. Support and upgrades can run as a retainer, and the scope should name who tests forum features after each upgrade.
Does DeployOpen certify that our forum setup meets compliance rules?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. For forums, the evidence an assessor usually asks for includes moderator access roles, retention settings for posts, logs of moderation actions and how learner data is handled. Ask the delivery team to document these in the written scope and confirm which assessor will review them. Confirm with your assessor which standard applies before work starts, since requirements differ by regulation and by sector.
How DeployOpen scopes and delivers Open edX forum work
DeployOpen plans, implements, hardens, documents and supports Open edX discussion forums inside your own infrastructure, whether you run the Python forum application or an LTI discussion provider. Work starts from a written scope that names the Open edX release, the hosting model and the moderation and notification rules. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names the Open edX release, hosting model and chosen forum application or LTI provider.
- Moderation roles, notification rules and course-level discussion settings are agreed before the build starts.
- Quotes follow from the written scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Configure MySQL 8.0 and a shared cache backend for multi-node deployments, as the edx-platform requirements describe.
- Set up moderation workflows and notification delivery in a staging environment before any change reaches learners.
- Test posting, search, reporting and moderator actions across learner, instructor and staff roles before release.
How we hand over
- A written runbook covers deployment, configuration, backups and the steps for upgrading the forum component.
- A moderation guide for course teams and staff covers roles, reporting paths and escalation steps.
- Knowledge transfer to your platform team documents the LTI provider decision where one is used.
How we support
- Upgrade planning follows the named Open edX release, because the latest named release is the only one supported.
- Retainer options can cover patching, monitoring checks and review of forum settings after platform changes.
- Ask for a support scope that names response expectations and who handles forum changes in each Open edX release.
