Separate AVX and non-AVX Docker builds for MongoDB compatibility

[leodrivera]

Summary

This PR introduces separate Docker image builds for AVX and non-AVX compatible systems, addressing MongoDB compatibility issues across different CPU architectures and virtualization environments.

Changes

Dockerfile

• Added separate build stages for AVX (stage-release-all-in-one) and non-AVX (stage-release-all-in-one-noavx) versions
• Configured appropriate MongoDB versions for each build target
• Enhanced error logging for MongoDB process exit errors, specifically for AVX-related issues

Release Workflow

• Updated .github/workflows/release.yml to build and push three Docker images:
  1. minimal - Minimal bundle image
  2. non-avx - All-in-one bundle with non-AVX compatible MongoDB
  3. latest - All-in-one bundle with AVX-compatible MongoDB (builds last)
• Adjusted image tags to clearly differentiate between AVX and non-AVX versions

Documentation

• Enhanced README with detailed instructions for using both AVX and non-AVX Docker images
• Added troubleshooting section for AVX-related errors

Application Code

• Added logging improvements in cmd/start.go for better error diagnostics

Benefits

• Compatibility: Users can now choose the appropriate image based on their CPU capabilities
• Flexibility: Non-AVX images work on older CPUs and certain virtualization environments
• Clarity: Clear distinction between AVX and non-AVX builds through naming and tags
• Debugging: Enhanced error logging helps identify AVX-related issues more easily

Image Tags

• ghcr.io/<repo>:latest - AVX-compatible all-in-one image
• ghcr.io/<repo>:non-avx - Non-AVX compatible all-in-one image
• ghcr.io/<repo>:minimal - Minimal bundle image

Testing

• Release workflow builds all three images successfully
• Docker images are tagged correctly
• Documentation updated with usage instructions

[grishy]

@leodrivera looks like a good idea, thanks!

• Can you attach an example of the error that you saw so I can recheck the validation?
• Did you already check how error detection is working?

[grishy]

And as I see, we will have different versions of Mongo for different builds.
From here https://www.mongodb.com/docs/manual/administration/production-notes/#x86_64:

MongoDB 5.0 requires use of the AVX instruction set, available on select Intel and AMD processors.

I am thinking about the idea of two versions, maybe keeping only the check on error and telling users to set up their own Mongo instance. What do you think @leodrivera ?

[HarpBunny]

Just dropping by to say thank you so much for doing this! I ran into JUST this problem today. The any-sync-dockercompose repo also had a section for this in their FAQ and while my host machine's hardware is pretty old, that shows it's more than just me

Looking forward to the good news!

[leodrivera]

@leodrivera looks like a good idea, thanks!

• Can you attach an example of the error that you saw so I can recheck the validation?
• Did you already check how error detection is working?

Yeah, I've tested it on my device. It's Intel(R) Celeron(R) N4120 CPU @ 1.10GHz, which does not support AVX

Below is the log from the ghcr.io/<repo>:latest

leonardo@DietPi:~/docker/test_anytype$ docker compose logs                                                                         10.4s 
anytype_test  | 
anytype_test  | ┌───────────────────────────────────────────────────────────────────┐
anytype_test  | 
anytype_test  |                  Welcome to the AnySync Bundle!
anytype_test  | 2025-12-10T03:01:06.980Z        INFO    cli     loading config
anytype_test  | 2025-12-10T03:01:06.980Z        INFO    cli     loaded existing config
anytype_test  |            https://github.com/grishy/any-sync-bundle
anytype_test  | 
anytype_test  |     Version: 1.1.3-2025-12-01-avx-fix
anytype_test  |     Built:   c944e0c7a419e672ebf6df6e3385fd2482fef21d
anytype_test  |     Commit:  2025-12-08T12:53:48.045546635Z
anytype_test  | 
anytype_test  |  Based on these components:
anytype_test  |  ‣ github.com/anyproto/any-sync (v0.11.4)
anytype_test  |  ‣ github.com/anyproto/any-sync-consensusnode (v0.5.0)
anytype_test  |  ‣ github.com/anyproto/any-sync-coordinator (v0.8.1)
anytype_test  |  ‣ github.com/anyproto/any-sync-filenode (v0.10.0)
anytype_test  |  ‣ github.com/anyproto/any-sync-node (v0.10.1)
anytype_test  | 
anytype_test  | └───────────────────────────────────────────────────────────────────┘
anytype_test  | 2025-12-10T03:01:06.982Z        INFO    cli     client configuration written    {"path": "./data/client-config.yml"}
anytype_test  | 2025-12-10T03:01:06.982Z        INFO    cli     data directories prepared       {"mongo": "/data/mongo", "redis": "/data/redis"}
anytype_test  | 2025-12-10T03:01:06.982Z        INFO    cli     starting embedded MongoDB       {"addr": "127.0.0.1:27017", "dbpath": "/data/mongo"}
anytype_test  | 2025-12-10T03:01:06.983Z        INFO    cli     starting embedded Redis {"addr": "127.0.0.1:6379", "dir": "/data/redis"}
anytype_test  | [redis] 17:C 10 Dec 2025 03:01:06.992 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
anytype_test  | [redis] 17:C 10 Dec 2025 03:01:06.992 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
anytype_test  | [redis] 17:C 10 Dec 2025 03:01:06.992 * Redis version=7.4.6, bits=64, commit=00000000, modified=0, pid=17, just started
anytype_test  | [redis] 17:C 10 Dec 2025 03:01:06.992 * Configuration loaded
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.993 * Increased maximum number of open files to 10032 (it was originally set to 1024).
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.993 * monotonic clock: POSIX clock_gettime
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.994 * Running mode=standalone, port=6379.
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.995 * <bf> RedisBloom version 2.8.7 (Git=unknown)
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.996 * Module 'bf' loaded from /opt/redis-stack/lib/redisbloom.so
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.996 * Server initialized
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.996 * Reading RDB base file on AOF loading...
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.997 * Loading RDB produced by version 7.4.6
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.997 * RDB age 148 seconds
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.997 * RDB memory usage when created 0.96 Mb
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.997 * RDB is base AOF
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.997 * Done loading RDB, keys loaded: 0, keys expired: 0.
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.998 * DB loaded from base file appendonly.aof.1.base.rdb: 0.001 seconds
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.998 * DB loaded from append only file: 0.001 seconds
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.998 * Opening AOF incr file appendonly.aof.1.incr.aof on server start
anytype_test  | [redis] 17:M 10 Dec 2025 03:01:06.998 * Ready to accept connections tcp
anytype_test  | 2025-12-10T03:01:07.051Z        DEBUG   cli     process exited with error       {"process": "mongo", "error_msg": "signal: illegal instruction (core dumped)", "error": "signal: illegal instruction (core dumped)", "exit_code": -1}
anytype_test  | 
anytype_test  | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
anytype_test  | ⚠️  MONGODB AVX ERROR DETECTED ⚠️
anytype_test  | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
anytype_test  | MongoDB failed to start (exit code -1) (process exited)
anytype_test  | 
anytype_test  | This is an AVX-related error. Your CPU does not support AVX
anytype_test  | instructions required by MongoDB. The process was killed by the
anytype_test  | kernel with SIGILL (Illegal Instruction) before it could write
anytype_test  | any logs.
anytype_test  | 
anytype_test  | SOLUTION: Use the 'non-avx' image tag:
anytype_test  |   ghcr.io/grishy/any-sync-bundle:non-avx
anytype_test  | 
anytype_test  | ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
anytype_test  | 
anytype_test  | 2025-12-10T03:01:07.388Z        DEBUG   cli     waiting for TCP listener        {"addr": "127.0.0.1:27017", "attempts": 5, "elapsed": "404.696516ms"}
anytype_test  | 2025-12-10T03:01:07.893Z        DEBUG   cli     waiting for TCP listener        {"addr": "127.0.0.1:27017", "attempts": 10, "elapsed": "909.498385ms"}
anytype_test  | 2025-12-10T03:01:08.398Z        DEBUG   cli     waiting for TCP listener        {"addr": "127.0.0.1:27017", "attempts": 15, "elapsed": "1.414171636s"}
anytype_test  | 2025-12-10T03:01:08.902Z        DEBUG   cli     waiting for TCP listener        {"addr": "127.0.0.1:27017", "attempts": 20, "elapsed": "1.918859222s"}

[leodrivera]

And as I see, we will have different versions of Mongo for different builds. From here https://www.mongodb.com/docs/manual/administration/production-notes/#x86_64:

MongoDB 5.0 requires use of the AVX instruction set, available on select Intel and AMD processors.

I am thinking about the idea of two versions, maybe keeping only the check on error and telling users to set up their own Mongo instance. What do you think @leodrivera ?

My first idea was to do it like this, so that we could continue with only 2 types of build. However, MongoDB 4.4 only supports up to Ubuntu 20.04, while redis-stack-server uses Ubuntu 22.04. So, to avoid changing the base image of stage-release-all-in-one to an older one, I thought about dividing it into two builds, with the default being the one with the most recent MongoDB with that warning message.

[leodrivera]

Just dropping by to say thank you so much for doing this! I ran into JUST this problem today. The any-sync-dockercompose repo also had a section for this in their FAQ and while my host machine's hardware is pretty old, that shows it's more than just me

Looking forward to the good news!

Yeah, my host machine is a MiniPC with Celeron, so it does not support AVX. I confess I took some time to identify the root cause of why the stage-release-all-in-one was not working. Since the kernel kills the process before it could write any logs, I haven't had any information on what was causing it.

As in your case, you also have a CPU without AVX support, I think it's worth testing it on your machine to see if the warning message is appearing correctly.

[grishy]

I added notes to the README about the AVX issue for now. Thanks!