The AI layer: pragmatic rather than visionary – and that is meant as praise
Many CMS vendors have slapped AI on top as a marketing label over the past year. Magnolia takes a different approach: the AI features in 6.4 are consistently embedded in existing workflows without tearing them apart.
The most prominent example is the integrated AI image editor in the DAM. Authors can change aspect ratios, remove backgrounds, and add or delete elements directly in Magnolia – without opening an external editor. What sounds like a convenience feature has a strategic consequence: the context switch, which in practice regularly leads to versioning problems and shadow assets, is eliminated. The asset lives, versioned and approved, in one system.
The decision regarding the Image Recognition Module is remarkable: instead of hard-wiring AWS Rekognition as before, the module is now LLM-agnostic. Any multimodal model can be connected – 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 detail but a free pass.
Automatic metadata population (title, description, alt text) completes the picture. It can be triggered manually, as a bulk action, or fully automatically on upload. Multilingual. That sounds small, but in practice it is one of the most expensive manual processes in content teams – SEO-compliant alt texts for 50,000 DAM assets used to be a consulting engagement. As of 6.4, it is a button.
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 blocks, authors wait, the system struggles for breath. This is not a bug; it is the architecture of the previous JCR-based publication model – synchronous, lock-heavy, and linear in a system that is 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 keep working while publishing happens in the background. The result according to Magnolia: more than 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 have to provision the infrastructure themselves. This is not hiding complexity but an honest separation: whoever wants the performance carries the infrastructure responsibility. For modern cloud setups, this is not a problem. For classic on-premises installations in large corporations with rigid infrastructure processes, it will be a discussion.
Jakarta EE 10: the migration everyone has been waiting for
As of 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 finally left the javax namespace behind. Anyone who has developed custom modules for Magnolia in recent years knows how much latent pain lies in the javax vs. jakarta package name question.
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 on container infrastructure that requires EE9+ works without workarounds.
For existing custom modules, this means a migration – but a plannable one. Magnolia has been preparing the EE9 compatibility paths since 6.3; 6.4 completes the step.
WCAG 2.1 AA: compliance as a feature, not an obligation
The new UI framework in 6.4 – a step-by-step replacement of the Vaadin forms with its own components – brings not only performance but also WCAG 2.1 AA conformance in the authoring interface itself. Improved focus visibility, complete keyboard navigation, clean semantic structure. Preparation for WCAG 2.2 is already built in.
That sounds like a topic for accessibility specialists. But it is increasingly a procurement criterion: public-sector clients and regulated industries in the EU require WCAG conformance not only for the published websites, but increasingly also for the internal systems in use.
Assessment: where does Magnolia stand in 2026?
In the Gartner Magic Quadrant for Digital Experience Platforms, Magnolia held the Visionary position for the fifth consecutive time in 2025. That is less exciting than a leap into the Leaders quadrant – but also more honest. Magnolia is not a Salesforce Experience Cloud competitor. Its strength lies in composability: a stable, extensible platform that integrates into complex enterprise stacks without wanting to be everything itself.
Version 6.4 makes this promise more credible. The AI features are not decorations but are embedded in real authoring workflows. Swift Publication solves a genuine scaling problem. Jakarta EE 10 pays off technical debt. And the WCAG work anticipates regulatory requirements before they become urgent.
For Magnolia projects in planning or in ongoing operation, 6.4 concretely means: the upgrade path is clearer than with many previous releases, the infrastructure requirements for Swift Publication should be assessed early, and the LLM freedom in the Image Recognition Module provides leeway that you should use – especially if AI infrastructure already exists in your company.
Portalworks supports Magnolia projects from the architecture decision through to ongoing operation. Questions about evaluating 6.4 for your specific stack? Get in touch with us.
