The distinction matters because the claimed success depends on a newer, unreleased Soda build, while the publicly released Bottles version contains an earlier one. The available evidence is also a self-report, supplemented by a secondary account, rather than an independently repeatable test with a published setup procedure, logs, or patch set.
What has actually been reported
The core report is specific enough to deserve attention. A public developer update dated September 10, 2026 said that Microsoft Office 365 had been installed in a Windows 10/11 Wine prefix through Bottles 67.4 using Soda 11.0-11. The developer said installer compatibility had been fixed and, after extensive work on user-interface glitches, the applications could be opened and used.
That is a narrower and more credible description than saying that Microsoft has released Office for Linux. Bottles creates and manages Wine prefixes: Windows-like environments in which Windows applications may run on Linux through Wine-derived compatibility technology. The reported result is therefore a compatibility-layer experiment, not a native Linux port.
The precise Microsoft 365 build named in coverage, Version 2608 Build 20326.20144, is real. Microsoft’s Current Channel release notes list that build with a September 8, 2026 date. This establishes that the report was referring to a genuine current Microsoft 365 release rather than an invented version number.
It does not, however, establish that the same build is necessarily the final build any given installer will offer on every Windows 10 or Windows 11 machine. Update channels, account configuration, and installation state can affect which build is presented. More importantly, confirmation that a build exists is not confirmation that it will function reliably under Wine.
The unreleased-component problem
The largest practical limitation is deployment. Bottles 67.4 was publicly released on September 7 as a test release for ARM64 Linux through cpak, and its announcement says it includes Soda 11.0-10. The developer’s Microsoft 365 result instead names Soda 11.0-11.
That single-version difference is decisive. Soda 11.0-11 was not publicly released in the material available for this assessment, and no public change set, installation instructions, or reproducible package was surfaced. A Bottles user installing the available 67.4 release therefore does not have the complete configuration said to have worked.
This is not a pedantic version-number caveat. Wine compatibility often turns on small changes in window rendering, networking, authentication flows, installers, registry handling, or Windows API behavior. If 11.0-11 contains the fixes that made this test possible, moving back to 11.0-10 could mean encountering the very installer or interface failures the developer described fixing.
For now, the accurate conclusion is that a developer has reported a promising result in a configuration ahead of the public Bottles release. It is not yet a generally available “install Microsoft 365 on Linux” capability.
Authentication, licensing, and OneDrive remain unverified
A secondary report adds encouraging detail, saying that two-factor authentication passed, the Microsoft 365 entitlement was detected, and OneDrive integration worked. Those would be especially significant milestones if independently demonstrated. Modern Microsoft 365 is a subscription service, so getting an application window on screen is only one part of the problem. A usable outcome also needs account sign-in, licence recognition, token renewal, cloud connectivity, and continued operation after restarts and updates.
At present, those details should be treated as reported rather than established. The available dossier does not include a primary test artifact demonstrating two-factor authentication, entitlement recognition, OneDrive behavior, or the reported memory-use figure. It also does not show whether the installation survives a restart, a licence-token refresh, application updating, document open-and-save cycles, or prolonged normal use.
The unanswered workload questions are substantial. There is no evidence here that the result has been tested across Outlook, Excel, PowerPoint, add-ins, VBA, enterprise authentication rules, or corporate device-management environments. None of that disproves the developer’s result. It defines the boundary between an early compatibility breakthrough and software that an individual or organization can responsibly depend on.
Unsupported means more than “not officially recommended”
Microsoft’s published system-requirements material for Microsoft 365 client applications lists Windows, macOS, Android, and iOS platform columns. Linux is not included. The Bottles and Wine route is consequently unsupported by Microsoft.
For a home user, that generally means accepting more troubleshooting risk and the possibility that an update breaks a formerly functioning setup. A support agent may reasonably ask the customer to reproduce an issue on a supported platform. For users whose work depends on a particular Office feature or consistent access to subscription services, that can turn a successful installation into a fragile arrangement.
For businesses, schools, and public-sector organizations, unsupported status has wider implications. Help desks need a reproducible configuration; security teams need predictable update behavior; and administrators need a clear escalation path when sign-in, storage integration, or document workflows fail. An experimental Wine prefix does not automatically satisfy those operational requirements, even when it works well on one developer’s machine.
That does not diminish the engineering value of the work. It simply sets the right threshold for deployment decisions. Compatibility experimentation and supported production use are different categories.
Why the CrossOver record tempers the excitement
CodeWeavers’ current compatibility listing for Microsoft Office 365 on Linux rates it as “Installs, Will Not Run” and identifies CrossOver 26.1.0 as the last tested version. That record is important context because CrossOver is another Wine-derived product with a commercial focus on application compatibility.
Some reporting around the Bottles claim incorrectly stated that CodeWeavers last tested Office 365 with CrossOver 26.3.0. The listing instead names 26.1.0. The correction matters because compatibility listings are version-specific and can become outdated quickly.
Still, the CodeWeavers result should not be read as a direct refutation of the Bottles developer’s report. The reported Bottles setup uses a different, unreleased Soda revision and may include fixes not present in the tested CrossOver build. The applications, account states, test dates, and environment details may differ as well.
What the CrossOver status does show is that modern Microsoft 365 remains a difficult target across Wine-derived systems. It reinforces the need for independent reproduction before readers infer broad usability from a single claimed success.
What Windows users should take from this
For Windows users considering Linux, this news is most relevant as an indicator of progress, not as a migration checklist. If Microsoft 365 desktop applications are essential to your work, the dependable path remains a supported Microsoft platform. Linux users who test the Bottles route should preserve a working Windows option for time-sensitive projects until the configuration is publicly released and independently validated.
The practical risks are not limited to whether Word initially launches. The difficult moments are likely to occur at authentication prompts, account recovery, subscription checks, updates, document handoffs, and less common application features. A setup that opens a document today may still fail at a critical point after a service-side or client-side change.
Users who nevertheless experiment should make the decision with realistic expectations: this is unsupported software running through an evolving compatibility layer, and the reported working runner has not yet been made available as part of the public Bottles release described here. It should be approached as testing, not as a replacement for a supported Office workstation.
The milestone to watch next
The next meaningful step is not another assertion that the applications launched. It is a public release of the required Soda version, accompanied by enough technical detail for other users to reproduce the setup. Independent tests should confirm installation, sign-in, licensing, restarts, updates, cloud integration, and ordinary document work across more than one machine and account type.
It would also matter to know whether the relevant fixes are made available beyond this particular Bottles configuration. There is currently no evidence that the work has been accepted upstream in Wine or that it will automatically carry over to CrossOver, Lutris, or other Wine-based projects. Such transferability should not be assumed without public patches, merges, or release notes.
For now, the Bottles report is best understood as an early and technically interesting compatibility claim: Microsoft 365 may have crossed an important hurdle in one unreleased environment, but public availability, independent verification, and Microsoft support have not followed. That is promising news for Linux compatibility work, while remaining insufficient evidence for a broad claim that Microsoft 365 desktop apps now run reliably on Linux.