Error while building bitwarden images for version 2025.6.1
When I updated bitwarden via the update-bitwarden.sh script I got the following error:
=> ERROR [4/4] RUN set -e; set -x; dotnet /bitBetter/bitBetter.dll && mv /app/Core.dll /app/Core.orig.dll && mv /app/modified.dll /app/Core.dll && rm -rf /bitBetter && rm -rf /newLicensing.cer 0.5s
------
> [4/4] RUN set -e; set -x; dotnet /bitBetter/bitBetter.dll && mv /app/Core.dll /app/Core.orig.dll && mv /app/modified.dll /app/Core.dll && rm -rf /bitBetter && rm -rf /newLicensing.cer:
0.239 + dotnet /bitBetter/bitBetter.dll
0.325 Unhandled exception. System.IO.FileNotFoundException: Could not find file '/app/Core.dll'.
0.350 File name: '/app/Core.dll'
0.350 at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
0.350 at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
0.350 at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException)
0.350 at System.IO.File.OpenHandle(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
0.350 at System.IO.File.ReadAllBytes(String path)
0.350 at bitwardenSelfLicensor.Program.Main(String[] args) in /bitBetter/Program.cs:line 31
0.422 Aborted (core dumped)
------
Upon further inspection in the api image I found, of course, the absence of the file Core.dll and on top of that a big difference in file and directory count inside the app folder: 182 files and directories in bitwarden/api:2025.5.3 vs 23 files and directories in bitwarden/api:2025.6.1.
I got the same big count difference while inspecting the identity image.
Unfortunately my Docker skills are kind of limited, and therefore I don't think I will be able to help further alone.
The weird part is that the installation has survived the not-successful update: I suspect that's because the "new" images are in fact the old ones with an updated tag, that is a 2025.5.3 image with a 2025.6.1 tag.
I ran into the same issue.
If the unmodified application is still working that would indicate to me that there has been a change in the way the licenses are applied.
The strange part was that I build the API solution from the main branch in the Bitwarden repo and the Core.dll was still present. Honestly I would be surprised if the selfhosted application was still running as expected.
In the meantime I had the time to dig a bit into the bitwarden/server repo's commits and I think I found the commit that broke BitBetter: bitwarden/server@63f5811aa9475aea9ecbcbe73e20cf1aefb6ca08
You can clearly see that there is a lot of code change concerning the different components, including the Dockerfiles of the images.
I think this would be a great starting point, but again I don't think I would be of much help since I'm not practical with the code of Bitwarden nor with C#.
The problem lies in this line: https://github.com/bitwarden/server/blob/b511b0550ca9e7a0dde0476b7226d4f7e7b61071/src/Api/Dockerfile#L33 This creates a single dll archive file containing all its dependencies. In order to make bitbetter work again we would have to create the api and identity image from the source code. Like this one could simply replace the licensing.cer file by our created certificate. By doing so, the whole bitbetter magic could be skipped as it is no longer required.
Additionally, I recommend setting /p:PublishSingleFile=true to false inside the api Dockerfile, since the licenseGen image relies on the Core.dll file of this image.
Interesting observation. @Genva do you think you'd be able to open a draft PR? Maybe with some starting code I'd be able to help at least testing some things out
@Fly7113 I created a PR feel free to check it out
I believe this only impacts the standard deployment right now. The unified branch builds fine on 2025.6.