The Open edX community has moved the platform forward again with Verawood, the 22nd community release of Open edX and the latest step in its six-month named-release cycle. But Verawood is different from a release built primarily around visible interface changes. Ulmo modernized many parts of the experience that learners, authors, and administrators interact with every day. Verawood goes deeper.

This release begins reshaping how Open edX frontends are assembled, how permissions are enforced, how instructors manage courses, how reusable content behaves, how notifications are delivered, and how operators deploy and extend the platform.

In other words, Verawood is not simply adding more features to Open edX. It is strengthening the architecture those features will run on for the next generation of the platform. Open edX identifies Verawood as its 22nd community release, and the project’s release-management page now identifies Verawood as the current release.

Key Upgrades of the Open edX Verawood Release

Several changes define the Verawood release:

• A new Instructor Dashboard frontend becomes the default instructor experience.

• Frontend-base introduces a new composable frontend architecture designed to gradually replace independently deployed MFEs.

• Role-Based Access Control for Course Authoring brings more granular Studio roles through Open edX AuthZ.

• Notifications become enabled by default, with smarter email delivery and new ORA reminders.

• Content Libraries gain additional flexibility, while Legacy Libraries become unsupported.

• LTI components become easier to duplicate and reuse while Verawood maintains LTI Advantage Complete certification.

• Open edX introduces official PostgreSQL support for fresh installations.

• Core XBlocks continue moving toward a more modular architecture through xblock-contrib and xblocks-extra.

• Aspects v4 brings the Verawood analytics stack to Python 3.12 and Superset 6.

• Tutor v22 updates the runtime stack and introduces important upgrade requirements, including a mandatory Meilisearch reindex.

The common theme is clear: Verawood reduces fragmentation.

Frontends become more composable. Permissions become more intentional. Content becomes easier to reuse safely. Integrations become more portable. Platform infrastructure becomes easier to evolve without continuously rebuilding the same pieces.

For Instructors: The Instructor Dashboard Finally Gets a Modern Home

One of the most visible Verawood changes is the modernization of the Instructor Dashboard.

For years, instructor tools have lived inside an interface that carried significant legacy code and UI patterns. It worked, but it increasingly looked and behaved differently from newer areas of Open edX.

Verawood changes that by making the new Instructor Dashboard frontend application the default experience.

1. A Dedicated Instructor Experience

The redesign does more than update fonts and buttons.

The broader Instructor Dashboard initiative is intended to separate instructor operations from the learner-facing course experience, giving educators a clearer product area for running their courses rather than treating instructor tools as a secondary tab attached to the LMS.

The new application covers major instructor workflows including course information, membership, cohorts, learner extensions, student administration, data downloads, exams, certificates, and Open Response Assessment workflows.

What this means for instructors: course administration starts feeling like a first-class Open edX experience rather than a legacy control panel embedded inside the learner interface.

2. Modern UI Patterns with Paragon

The modernization effort moves Instructor Dashboard interfaces toward the same Paragon-based design language used across newer Open edX experiences. That gives administrators and instructors greater consistency in spacing, components, interaction patterns, accessibility, and theming.

For institutions operating heavily customized Open edX instances, this also creates a cleaner foundation for future enhancements because instructor workflows are moving toward the modern frontend stack instead of accumulating more functionality inside legacy LMS templates.

3. Compatibility for Existing Integrations

This modernization does introduce an important integration change.

Platforms that previously customized Instructor Dashboard tabs through the org.openedx.learning.instructor.dashboard.render.started.v1 filter need to move toward the newer org.openedx.learning.instructor.dashboard.tabs.generated.v1 mechanism and appropriate frontend slots.

For organizations with custom instructor workflows, this should be treated as an upgrade task not merely a visual change.

4. A Legacy Escape Hatch Remains

Verawood does not immediately eliminate the old Instructor Dashboard.

Operators can use the instructor.legacy_instructor_dashboard Waffle flag to disable the redirect to the new application and temporarily return to the legacy interface.

That gives institutions time to validate integrations and custom functionality before completing their transition.

For Course Teams: Role-Based Permissions Move from Libraries into Course Authoring

Ulmo introduced Open edX’s new authorization model around Content Libraries. Verawood takes the next major step: bringing the AuthZ model into course authoring.

The goal is to replace increasingly fragmented authorization logic with a shared system that can answer a simple but critical question consistently:

Who is allowed to perform which action on which Open edX resource?

The Four New Course Roles

The AuthZ model defines four standard course roles.

The permission matrix goes much deeper than those labels. Open edX defines separate permissions around files, grading, course updates, library updates, groups, tags, certificates, import/export, course teams, schedules and other Studio functions.

Why the Course Editor Role Matters

This is one of the most practically useful changes. Previously, many institutions had difficulty giving instructional designers or subject-matter experts editing access without also granting broader operational privileges.

The Course Editor role creates a clearer separation between creating content and publishing content. That supports safer workflows for universities, training providers, large enterprises, and organizations where course production passes through formal review or approval stages.

Course Auditor: Built for QA and Governance

The Course Auditor role provides view-only Studio access. That is particularly useful for compliance reviewers, instructional quality teams, accessibility reviewers, accreditation teams, or stakeholders who need visibility without the ability to accidentally modify production content.

Important: Course AuthZ Is Opt-In in Verawood

Verawood does not automatically replace the legacy course permission model everywhere.

The new system is controlled through the authz.enable_course_authoring feature flag. Operators can introduce it at the individual course, organization, or whole-instance level.

When disabled, the legacy permission system remains in effect.

This staged rollout is deliberate. Large Open edX installations can validate role mappings and performance on a controlled group of courses before expanding the authorization model across the platform.

Migration and Rollback Are Built into the Transition

Open edX also provides a migration strategy for existing CourseAccessRole assignments.

The design supports forward migration into openedx-authz and rollback for equivalent legacy roles, reducing the risk of moving production course teams onto the new model.

What this means for administrators: Verawood transforms AuthZ from a Content Library experiment into a platform-wide security architecture that is beginning to govern the core Studio authoring experience.

Content Libraries in Verawood: Reuse Without Losing Local Flexibility

Ulmo made Content Libraries substantially more powerful by supporting reusable Sections and Subsections. Verawood builds on that foundation with changes that make centrally managed content easier to adapt inside individual courses.

1. Override Library-Sourced Titles

Starting with Verawood, authors can rename content imported from a library without breaking its connection to the source. This works across library-sourced Sections, Subsections, Units, and Components. That solves a common content-governance problem.

A central library might contain a reusable module called:

Introduction to Data Protection

One course may need it displayed as: Week 2: Protecting Customer Data

Another might need: Mandatory Privacy Fundamentals

The underlying learning object can remain centrally governed while each course presents the title most appropriate to its own context.

2. Override Text Inside Structural Blocks

Verawood also allows course teams to override Text components contained inside reusable library-sourced Sections, Subsections, and Units. The rest of the reusable structure remains connected to the library.

What this means for authors: centrally managed learning modules no longer need to be completely rigid.

Institutions can maintain a reusable “master” module while customizing selected wording for departments, programs, regions, clients, or course runs.

3. Legacy Libraries Reach the End of the Road

This release also marks an important transition. Legacy Content Libraries are no longer supported in Verawood.

Open edX directs course teams to migrate them into the newer Content Libraries experience introduced in previous releases. The new Library model supports components, Units, Subsections, and Sections and is designed around reuse, syncing, structured authoring, and the new authorization framework.

For institutions that postponed migration during Ulmo, Verawood makes that technical debt much harder to ignore.

For Learners: Notifications Become Smarter and More Automatic

Ulmo introduced the modern notifications experience. Verawood turns it from a feature operators explicitly activate into part of the platform’s default communication infrastructure.

Notifications Are Now Enabled by Default

The previous opt-in flags have been replaced with opt-out flags. Unless operators intentionally disable them, both platform notifications and notification emails are enabled in Verawood.

This is a subtle but significant shift. Open edX is effectively treating notifications as a standard part of the learning experience rather than an optional add-on.

Smarter “Immediate” Emails

Immediate notifications can easily become overwhelming when several events happen in a short period. Verawood introduces a configurable buffering system. The first immediate notification is sent normally. Additional immediate-cadence notifications created during the buffer window can be combined into a single email. The default buffer is 15 minutes.

What this means for learners: fewer bursts of near-identical emails without losing timely awareness.

ORA Reminder Notifications

Open Response Assessments depend on learners completing multiple stages often including peer review or self-review after submitting their own response. Verawood introduces ora_reminder notifications for learners who have submitted an ORA but still need to complete required peer or self-review stages.

By default, the system can send up to three reminders at 48-hour intervals, although operators can configure these values. This is an important evolution in the notification system because alerts are beginning to respond to unfinished learning workflows, not merely activity events.

No More Cron Jobs for Notification Digests

Verawood also changes how daily and weekly notification digests are scheduled. The old send_email_digest management command becomes a no-op and is deprecated. Digest delivery is now scheduled automatically through Celery when qualifying notifications are created. Default delivery is 17:00 UTC for daily digests and Monday at 17:00 UTC for weekly digests, although operators can customize those schedules.

For platform teams, that removes another manually managed piece of notification infrastructure.

Notification Preferences Move to V3

Integrations relying on course-level notification preference records or the V2 notification configuration API need to move forward. Verawood removes course-level notification preferences and the V2 configuration API in favor of account-level preferences and the V3 API. That matters especially for customized platforms, mobile integrations, and third-party services built around older notification models.

Reliable LTI Reuse: Copy Once, Configure Less

External learning tools are deeply embedded in many Open edX deployments. Verawood improves one of the most frustrating parts of that workflow: copying LTI components safely.

LTI 1.3 Components Can Retain Their Configuration

Starting with Verawood, directly configured LTI Consumer XBlocks can be duplicated or copied into another unit or course. For LTI 1.3, the copied component retains important configuration including the Client ID, Deployment ID, Keyset URL, and Access Token URL.

Previously, copying an LTI block could lead to configuration loss or force authors to repeat registration work. What this means for course teams: reusable LTI-based activities behave much more like reusable learning components rather than fragile one-off integrations.

LTI Store Still Provides the Scalable Option

For tools used widely across an institution, the reusable LTI Store introduced earlier remains the more centralized model. Operators define a configuration once and course teams reference it through a Filter key. Changes to the central configuration then affect all XBlocks that use it. Combined with Verawood’s duplication improvements, Open edX now supports both:

Local reuse through safer component copying, and central reuse through the LTI Store.

Verawood Is LTI Advantage Complete Certified

The Verawood release has achieved LTI Advantage Complete certification. That certification covers LTI 1.3 Core together with Assignment and Grade Services, Names and Role Provisioning Services, and Deep Linking.

For institutions integrating external assessment engines, simulations, video platforms, labs, content libraries, and specialized learning tools, this certification provides an important interoperability baseline.

Frontend-base: The Architectural Change That May Define Open edX’s Next Era

The biggest long-term change in Verawood may not be immediately visible to learners.

It is frontend-base. Verawood is the first Open edX release to support this new frontend architecture.

The Problem with the MFE Model at Scale

Open edX modernization has relied heavily on Micro-Frontends. MFEs successfully allowed areas such as Learning, Account, Profile, Authoring, and Learner Home to evolve independently.

But that independence has a cost.

Each frontend can require its own build, deployment, runtime configuration, plugin handling, branding integration, and application lifecycle. As the number of MFEs grows, operators can end up maintaining a fleet of frontends instead of one coherent application.

The New Model: One Shell, Multiple Frontend Apps

Frontend-base changes that model. Instead of treating every frontend experience as an independently deployed MFE, frontend applications can be loaded as packages inside a unified frontend shell.

Verawood includes four frontend-base applications:

Tutor’s implementation allows these applications to be enabled or disabled without rebuilding the Tutor image. When an application replaces an existing MFE, the corresponding MFE is disabled.

Why This Matters

Frontend-base is designed to improve several areas at once:

• Page transitions: applications can operate inside a shared frontend environment.
• Build efficiency: fewer independently assembled applications can reduce duplication.
• Customization: a broader plugin architecture can operate across the frontend.
• Branding: shared shell-level behavior provides a more centralized customization surface.
• Long-term maintenance: teams can evolve frontend functionality without maintaining as many separate applications.

This is more than a frontend refactor. It is Open edX beginning to move from a collection of modern applications toward a composable frontend platform.

A Migration Signal for Customized Instances

Verawood keeps the Authn and Learner Dashboard frontend-base apps disabled by default, giving operators time to test them. But Open edX explicitly encourages operators to evaluate existing branding, plugin, and MFE customizations because these may eventually need to be ported to the frontend-base architecture.

For highly customized Open edX deployments, Verawood should therefore trigger a frontend compatibility review even if you do not enable every frontend-base application immediately.

External Scripts: Analytics and Third-Party Services Become Easier to Inject

Frontend customization also becomes more flexible in Verawood. Previously, Open edX had specialized handling around integrations such as Google Analytics. Verawood expands this capability so operators can configure MFEs and frontend-base applications to load arbitrary external scripts.

That can support integrations such as: analytics tools, customer-support widgets, experimentation platforms, compliance scripts, monitoring services, or other externally hosted JavaScript. The important architectural improvement is that operators no longer need a platform-specific implementation every time they want to load another external service.

PostgreSQL Support: Open edX Adds Another Relational Database Option

Historically, Open edX deployments have centered around MySQL for relational data.

Verawood introduces official PostgreSQL backend support. There is one major limitation: PostgreSQL support applies to fresh installations only. Verawood does not provide an automatic migration path for converting an existing production Open edX installation from MySQL to PostgreSQL.

That distinction is important.

For new installations, PostgreSQL creates additional infrastructure choice. For existing installations, it should not be interpreted as a recommendation to replace MySQL during the Verawood upgrade.

XBlocks Get a Major Architectural Cleanup

Verawood continues another long-running Open edX modernization effort: extracting learning components from the core platform into more maintainable packages.

PDF XBlock Becomes Part of Platform Core

The PDF XBlock is now installed by default. Sites that previously installed a third-party PDF implementation need to review their configuration carefully because duplicate xblock.v1 entry points can trigger an AmbiguousPluginError.

Core Blocks Move to xblock-contrib

Several historically built-in blocks have been extracted from openedx-platform into the shared xblock-contrib repository. The extracted implementations are the Verawood defaults.

These include:

• HTML, Video, Problem, Word Cloud, Annotatable, LTI, and Poll blocks.
• The legacy built-in versions are deprecated, with removal planned in a later release.
• For operators, the immediate experience should largely remain familiar.

Architecturally, however, it is significant. Open edX is reducing the amount of feature code embedded directly inside its central monolith.

More XBlocks Consolidate into xblocks-extra

Other standalone repositories are being consolidated into xblocks-extra, including Audio, Feedback, Image Modal, Qualtrics Survey, SQL Grader, and Submit-and-Compare. Operators who explicitly installed the standalone versions should migrate their dependencies.

The broader direction is unmistakable: Smaller core. Cleaner ownership boundaries. Easier independent maintenance.

Aspects Analytics 4: A New Analytics Baseline

Organizations using Open edX Aspects also get a major upgrade path with Verawood. Aspects v4 is the version aligned with Verawood and later releases.

The upgrade brings the analytics environment onto Python 3.12 and includes Superset 6.0. This is explicitly considered a breaking major-version upgrade, so operators should treat it as a planned analytics migration rather than a routine package bump.

For organizations already using Aspects to centralize learner analytics and in-context reporting, Verawood therefore modernizes both the learning platform and its analytics foundation at the same time.

The AI Extensibility Framework: Important, but Still Experimental

AI is understandably one of the most anticipated areas around Verawood.

Open edX previewed an AI Extension Framework as part of the Verawood direction: an architecture intended to let organizations introduce AI capabilities into both LMS and Studio through extension points instead of hard-coding a single AI product into the platform.

The implementation repository shows why this work is promising. The experimental framework currently demonstrates: AI-powered content summarization, context-aware assistance, Learning and Authoring frontend integrations, modular workflow configuration, multiple LLM providers through LiteLLM, and event observability through Aspects.

But there is an important distinction. The project’s own GitHub repository currently describes it as an experimental proof of concept and explicitly warns that it should not yet be used in production environments.

Why This Is Still a Big Deal

Open edX is not choosing one proprietary AI assistant and embedding it permanently into the platform. Instead, the project is exploring an extensibility layer through which different organizations can eventually connect different providers, workflows, policies, models, and use cases.

That approach aligns strongly with the open-source philosophy of Open edX. The future opportunity is not “Open edX has one AI tool.”

It is: Open edX can become a platform where AI tools themselves are pluggable.

For now, institutions should treat the framework as a technology to evaluate and prototype; not as a production-ready headline feature.

Verawood Transformation: Before vs. After

Explore the Official Open edX Verawood Release Notes

Want to explore every Verawood update directly from the source? Review the official Open edX release notes for detailed product changes, technical updates, deprecations, and operator guidance.

Button: Explore Verawood Release Notes

Tutor v22: Verawood’s Deployment Stack Gets a Major Upgrade

For most organizations deploying Open edX through Tutor, moving to Verawood also means moving to Tutor v22. Tutor v22.0.0 was released on August 6, 2026 and is the Tutor release aligned with Open edX Verawood.

1. Python 3.12 for the Open edX Image

Tutor v22 updates the Open edX Docker image to Python 3.12.13. Tutor itself also expands compatibility to Python 3.13 and 3.14, raises its minimum supported Python version to 3.10, and drops Python 3.9 following its end of life.

Operator impact: custom Tutor plugins, Python dependencies, and custom Open edX images should be tested against the newer Python environment before production deployment.

2. Node.js Moves to 24.16.0

The Open edX Docker image also moves to Node.js 24.16.0. This modernizes the JavaScript build environment used by Open edX and should be included in compatibility testing for organizations maintaining custom frontend builds or frontend-related Docker customizations.

3. Core Infrastructure Dependencies Are Updated

Tutor v22 refreshes several services that form part of the standard Tutor deployment stack.

The final v22.0.0 release includes:

• Caddy 2.11.4
• Redis 7.4.10
• MongoDB 7.0.39
• MySQL 8.4.11

MongoDB remains on the 7.0 series tested by Open edX, while MySQL stays on the 8.4 LTS line. These are primarily platform-maintenance and security updates, but organizations with custom infrastructure, external databases, or strict version-management policies should include them in their Verawood compatibility review.

4. Meilisearch Requires Special Upgrade Planning

The most important Tutor v22 upgrade warning concerns Meilisearch.

Tutor v22 upgrades Meilisearch from 1.8.4 to 1.36.0. The new version uses an incompatible on-disk database format. Meilisearch 1.36.0 therefore cannot start using an index created by 1.8.4.

Fortunately, Meilisearch contains a derived search index rather than the authoritative Open edX course data, so the correct migration strategy is to discard the old index and rebuild it from the platform’s source data.

The official Tutor v22 release procedure instructs operators to stop the platform, remove the old data.ms index, start the updated services, initialize them, and then reindex Studio and active course content.

For large Open edX installations, reindexing may take significant time and search results will remain incomplete until the process finishes.

Operator Note: Treat the Meilisearch migration as part of your Verawood maintenance window rather than as a routine post-upgrade cleanup step.

Rollback also requires planning. Meilisearch 1.8.4 cannot read a database already converted to the newer 1.36.0 format, so operators who require rollback capability should preserve their pre-upgrade Meilisearch data along with the rest of their platform backup.

How to Upgrade an Ulmo Tutor Deployment to Verawood

A major Tutor upgrade should be treated differently from a routine patch update. Tutor recommends reading the release notes, backing up the deployment, verifying plugin compatibility, and testing the new release in a sandbox before upgrading production.

Step 1: Back Up the Existing Ulmo Deployment

Create a complete backup before changing Tutor or platform services. Tutor does not support simply downgrading an upgraded environment, making a tested backup particularly important for major named-release upgrades.

Step 2: Review Custom Plugins and Images

Check compatibility for:

• Tutor plugins
• custom Open edX Docker images
• edx-platform forks
• custom XBlocks
• frontend customizations
• themes
• analytics integrations
• external search infrastructure

Any custom edx-platform branch should also be rebased and tested against the appropriate Verawood release tag.

Step 3: Install Tutor v22

For an upgrade specifically targeting the initial Verawood Tutor release, pin the version explicitly:

pip install "tutor[full]==22.0.0"

Using an explicit version prevents a future package upgrade from unintentionally installing a later major Tutor release when following these instructions.

Step 4: Handle the Meilisearch Migration

Before bringing the Verawood stack fully online, stop the existing platform and remove the incompatible old Meilisearch index according to the official Tutor v22 release instructions. After the updated services are running, initialize the platform and rebuild the Studio and active-course search indexes.

Do not treat this step as optional when upgrading a standard Tutor deployment that contains the old Meilisearch 1.8.4 index.

Step 5: Run the Tutor Release Upgrade

For a normal major-release upgrade, tutor local launch can detect that the environment was generated by an older Tutor release and execute the required release-specific upgrade tasks.

There is an important exception.

If you run tutor config save before the first launch—for example because you need to rebuild custom Docker images—the previous-release information used for automatic detection may no longer be available.

In that situation, explicitly run:

tutor local upgrade --from=ulmo

before completing the launch. Tutor v22’s CLI officially accepts ulmo as a valid source release.

Step 6: Launch and Validate Verawood

After the required upgrade tasks and Meilisearch preparation are complete, launch the platform and validate:

• LMS and Studio availability
• course search
• Studio search
• background workers
• custom plugins
• custom themes
• MFEs and frontend-base applications
• XBlocks
• LTI integrations
• notification delivery
• analytics

For production environments, this validation should first be completed against a restored copy or sandbox environment before the same procedure is applied to the live platform.

What Tutor v22 Means for Operators

Tutor v22 is not simply a version-number change attached to Verawood. It modernizes the Open edX runtime and supporting services while also introducing an upgrade that requires deliberate search-index migration.

For operators, the central message is therefore not “upgrade Tutor and relaunch.”

It is:

Back up, validate your extensions, account for the Meilisearch format change, run the correct release-specific migration path, rebuild search indexes, and then verify the complete Verawood environment before returning it to production traffic.

Review Tutor v22 on GitHub

Planning your Verawood deployment with Tutor? Explore the official Tutor v22 release on GitHub for version changes, upgrade considerations, dependency updates, and the latest technical guidance for operators. View Tutor v22 on GitHub

What Verawood Means for Organizations Running Open edX

Verawood may initially look less dramatic than a release dominated by learner-facing redesigns.

Its strategic impact is arguably larger.

• For universities, granular course roles make it easier to separate faculty authors, publishing teams, quality reviewers, and administrators.
• For corporate learning teams, reusable library content can be centrally governed while still adapting terminology to individual programs.
• For large Open edX operators, frontend-base creates a path toward fewer isolated frontend deployments and a more coherent customization model.
• For integration-heavy platforms, more reliable LTI duplication and LTI Advantage certification reduce friction around external learning tools.
• For technical teams, PostgreSQL support, XBlock extraction, external script loading, Tutor runtime upgrades, and a cleaner AuthZ layer all make the platform more extensible.

And for organizations beginning to experiment with AI, the new AI extensibility work signals an important architectural direction: AI should be added to Open edX through replaceable, configurable extensions rather than locking the platform to a single vendor or model.

How Edly Can Help You Prepare for Verawood

Verawood is exactly the kind of Open edX release where the upgrade itself is only part of the work.

The more customized your platform is, the more important it becomes to review what sits around the core installation.

• Frontend branding may need to be tested against frontend-base.
• Custom instructor workflows need to be validated against the new Instructor Dashboard.
• Course-role mappings need a controlled AuthZ migration strategy.
• Legacy Libraries need to be migrated.
• Third-party XBlocks need compatibility checks.
• LTI integrations should be validated after copying and configuration changes.
• Aspects needs a planned major-version upgrade.
• Typesense, Meilisearch, custom profile fields, storage settings, external scripts, and custom Tutor plugins all need their own review.

For organizations that do not want to manage this complexity alone, Edly’s Open edX engineering, managed hosting, customization, migration, and platform-support capabilities can turn the Verawood transition into a controlled modernization project rather than a reactive software upgrade.

The opportunity is not simply to “get onto Verawood.”

It is to use the release as a checkpoint to reduce old customizations, adopt newer extension mechanisms, move reusable content onto the modern Library architecture, tighten course permissions, and prepare your frontend strategy for where Open edX is heading next.

Conclusion: Verawood Is the Architecture Release

The most important thing to understand about Verawood is that its biggest changes are connected.

• The new Instructor Dashboard is built on a newer frontend direction.
• Frontend-base reduces frontend fragmentation.
• AuthZ reduces permission fragmentation.
• Content Library improvements reduce duplicated content while preserving local flexibility.
• LTI changes reduce duplicated integration configuration.
• XBlock extraction reduces code trapped inside the central platform.
• Notification changes reduce manual scheduling and fragmented preferences.
• PostgreSQL expands infrastructure choice.
• Aspects modernizes analytics.
• Tutor v22 modernizes the runtime underneath everything.
• And the AI Extensibility Framework begins exploring how future intelligent capabilities can be added without turning Open edX into a closed, vendor-specific AI product.

Ulmo made Open edX feel more modern. Verawood begins making the platform itself more modern.

For institutions planning to run Open edX for years rather than months, that distinction matters. Verawood is not simply another release to install.

It is a transition toward an Open edX ecosystem that is more composable, more permission-aware, more reusable, easier to extend, and better prepared for the next generation of digital learning.

Upgrade to Every Major Open edX Release With Edly!

Major Open edX upgrades involve much more than updating a version number. From custom plugins and themes to XBlocks, MFEs, integrations, databases, and infrastructure, every release needs careful compatibility testing and migration planning.

Edly helps its Open edX clients move confidently to every major release, handling upgrade planning, staging, compatibility checks, migrations, testing, deployment, and post-upgrade validation so your team can benefit from the latest Open edX capabilities without the usual upgrade hassle.

Upgrade Your Open edX Platform with Edly