ARM64 Support

[androidacy-user]

Hello!

It looks like the docker images cannot be run on ARM64 only servers (such as the relevant AWS instances)

Would you mind adding support? Thanks!

[androidacy-user]

Note: ARM64 requires the relevant nginx and mongodb images to be used in place of bitnami ones, however, the countly images themselves are completely missing support for ARM64.

[Ghost-chu]

Same, Countyly's api and frontend images returns /usr/bin/tini: exec format error

[satyajitnayk]

Today I was trying to run Docker for countly-server in mac M1. But it does not work as mentioned above.
Getting this error no matching manifest for linux/arm64/v8 in the manifest list entries

I am planning to build countly-server sdk for golang. Help me out here how can i run server locally?

[androidacy-user]

Today I was trying to run Docker for countly-server in mac M1. But it does not work as mentioned above.
Getting this error no matching manifest for linux/arm64/v8 in the manifest list entries

I am planning to build countly-server sdk for golang. Help me out here how can i run server locally?

Ever since introducing their (extremely pricey) Flex offering they've been paying less and less attention to the open source self hosted stack. The self hosted version even has an ad for Flex now - which starts at $80/mo for 2k users tracked.

I wouldn't hold my breath for them to even try to support arm64.

[kanwarujjaval]

Hello
Please take a look at this guide for setting up on macos
https://github.com/Countly/countly-server/blob/master/.vscode/README.devsetup.md

[ar2rsawseen]

Hello
arm64 is not supported because of some dependencies that do not support it. And docker is not our primary release platform, it is an addition added by contributors who do not maintain it anymore.

We are developing this tool for ourselves, and if you like it, you are allowed to use it. But that's about it.
And yes, there will definitely be no additions because somebody asked for it unless developers agree with its priority and decide to dedicate time to this. It has been like this for years now, much longer before Flex :)

If we did not have any plans to add arm64 or did not accept it as contributions, I would have closed this issue a long time ago. But we are keeping it because we are open to this if somebody (internally or externally) wants to contribute and add this. But demanding does not work in Open Source anymore!

[androidacy-user]

Hello
arm64 is not supported because of some dependencies that do not support it. And docker is not our primary release platform, it is an addition added by contributors who do not maintain it anymore.

We are developing this tool for ourselves, and if you like it, you are allowed to use it. But that's about it.
And yes, there will definitely be no additions because somebody asked for it unless developers agree with its priority and decide to dedicate time to this. It has been like this for years now, much longer before Flex :)

If we did not have any plans to add arm64 or did not accept it as contributions, I would have closed this issue a long time ago. But we are keeping it because we are open to this if somebody (internally or externally) wants to contribute and add this. But demanding does not work in Open Source anymore!

Tl;Dr we don't make money off this, so add it yourself or get lost.

Also, before flex times, arm64 servers weren't exactly popular, and this is hardly the only issue to go months with no official response. The open source self hosted version is a second rate citizen to your Flex offering now, that's abundantly clear.

Nobody is "demanding" anything. But I'm sure you understand why it certainly looks like the self hosted offering has taken a backseat now and why some of us may be a bit frustrated about that. We saw it happen with Sentry and so many others, it looks like it's happening here too.

[ar2rsawseen]

The open source self hosted version is a second rate citizen to your Flex offering now, that's abundantly clear.

Well actually it is not. This is a core of all other products, both Flex and Enterprise. So what ever functionality are added here, would also propagate to other products. That is the reason why this product gets updates. It is a shared codebase between all the products. So it gets the latest features first.

The problem is when the feature is not needed for us and the paying customers at all. Unfortunately, we do not have time to add all the nice to-haves.
And at this point, we would not even accept such additions as contributions in many cases, because they would not be maintained later. We had multiple cases when people add stuff, we accept and then we need to manage that and make sure it is not broken. Like I guess docker now? :)

So now we align with what is needed for us and add only that, rest gets closed/rejected.

In the end, it is all about the resources :)

[ar2rsawseen]

Oh, and I know it may seem it is actually quite quiet here lately. This is also because we work on something big behind the scenes. Like a completely new architecture, separating ingestion, aggregation, and reporting. And it will first come here, and only then propagate to our other products.

We have not yet made all the decisions, but Countly Lite would be able to collect much more granular data and do more with it.

[Pezhvak]

I'm really interested in ARM64 since it's only growing in support in data centers. i think if people find this issue there will be enough to add the support.