The AI Layer: Pragmatic Rather Than Visionary—and That’s the Praise
Many CMS providers have slapped “AI” on top as a marketing label over the past year. Magnolia is taking a different approach: The AI features in 6.4 are consistently embedded in existing workflows without disrupting them.
The most prominent example is the integrated AI image editor in the DAM. Authors can change aspect ratios, remove backgrounds, or add and delete elements directly in Magnolia—without opening an external editor. What sounds like a convenient feature has a strategic consequence: it eliminates the context switch that, in practice, regularly leads to versioning issues and shadow assets. The asset lives, is versioned, and approved within a single system.
Noteworthy is the decision regarding the Image Recognition Module: Instead of hard-coding AWS Rekognition as before, the module is now LLM-agnostic. Any multimodal model can be integrated—whether OpenAI, Google Gemini, Azure AI Vision, or a self-hosted open-source model. For companies with existing AI contracts or data protection requirements, this is not a minor detail but a game-changer.
Automatic metadata filling (title, description, alt text) rounds out the picture. It can be triggered manually, as a bulk action, or fully automatically upon upload. Multilingual. That may sound minor, but in practice it’s one of the most expensive manual processes in content teams—SEO-compliant alt text for 50,000 DAM assets used to be a consulting project. Starting with version 6.4, it’s a single click.
Swift Publication: The Silent Architecture Problem Is Solved
Anyone who has ever worked in a multi-cluster Magnolia setup knows the pain: a large publication gets stuck, authors wait, the system struggles. This isn’t a bug; it’s the architecture of the previous JCR-based publication model—synchronous, lock-heavy, and linear in a system that’s supposed to be built for parallel enterprise workloads.
Swift Publication is the answer, and it is architecturally consistent. The new, asynchronous engine separates the publication process from the authoring tool: changes are sent to an external version store (S3 or Azure Blob Storage) and distributed via a message broker. Authors continue working while publication occurs in the background. The result, according to Magnolia: over 70% faster publication in complex multi-cluster setups.
The catch is communicated transparently: Swift Publication is a separate enterprise module that requires additional infrastructure—an external version store and a message broker. PaaS customers get this out of the box; on-premises operators must provision the infrastructure themselves. This isn’t hiding complexity, but an honest separation: those who want the performance bear the infrastructure responsibility. For modern cloud setups, this isn’t a problem. For traditional on-premises installations in corporations with rigid infrastructure processes, this will be a point of discussion.
Jakarta EE 10: The Migration Everyone Has Been Waiting For
Starting with version 6.4, Magnolia runs on Jakarta EE 10 as its baseline—and thus on Tomcat 10+, modern servlet containers, and a Java ecosystem that has javax-namespace. Anyone who has developed custom modules for Magnolia in recent years knows how much latent pain lies in the javax vs. jakartapackage name issue.
In practical terms, this means: New integrations with modern frameworks, libraries, and containers are possible without namespace shims. Security updates for the EE layer come from an active upstream. And deployment to container infrastructure requiring EE9+ works without workarounds.
For existing custom modules, this means a migration—but one that can be planned. Magnolia has been preparing the EE9 compatibility paths since 6.3; 6.4 completes the transition.
WCAG 2.1 AA: Compliance as a Feature, Not a Requirement
The new UI framework in 6.4—the gradual replacement of Vaadin forms with proprietary components—brings not only performance but also WCAG 2.1 AA compliance to the authoring interface itself. Improved focus visibility, full keyboard navigation, clean semantic structure. Preparation for WCAG 2.2 is already built in.
This sounds like a topic for accessibility specialists. However, it is increasingly becoming a procurement criterion: Public contracting authorities and regulated industries in the EU require WCAG compliance not only for published websites but increasingly also for the internal systems they use.
Positioning: Where does Magnolia stand in 2026?
In the Gartner Magic Quadrant for Digital Experience Platforms, Magnolia held the “Visionary” position for the fifth consecutive year in 2025. That’s less exciting than a jump into the “Leaders” quadrant—but also more honest. Magnolia is not a competitor to Salesforce Experience Cloud. Its strength lies in composability: a stable, extensible platform that integrates into complex enterprise stacks without trying to be everything itself.
Version 6.4 makes this promise more credible. The AI features aren’t just window dressing; they’re embedded in real authoring workflows. Swift Publication solves a genuine scaling problem. Jakarta EE 10 resolves technical debt. And the WCAG work anticipates regulatory requirements before they become urgent.
For Magnolia projects in the planning phase or already in operation, 6.4 means in concrete terms: The upgrade path is clearer than in many previous releases, the infrastructure requirements for Swift Publication should be evaluated early on, and the LLM flexibility in the Image Recognition Module provides leeway that should be utilized—especially if AI infrastructure already exists within the company.
Portalworks supports Magnolia projects from architectural decisions through to live operations. Questions about evaluating 6.4 for your specific stack? Get in touch with us.
