No the logs are completely empty. The container is running though, so it’s not exiting due to a crash, but the application simply doesn’t start / serve. I can also jump into the container terminal etc. So everything seems to work, but the application is obviously not running…
Any other setting I could try? I’m running the default docker settup with caddy and localhost domain.
@kaylumah Which version are you running? Is Squidex v7 working on your Mac?
I do not have a mac, this is one of the main issues with this topic here 
If the container is running you could execute bash inside the container and just run it manually. Perhaps you see what is going on then.
Currently my project is running on squidex:6 , but I will test with 7 and circle back here
On Squidex7 I don’t get any logging either. Just checked with a colleague on an intel Mac and he gets logging on squidex7
Thanks for checking @kaylumah! So we have the same situation - I tried running dotnet Squidex.dll from within the container but it’s - as expected - the same result. But for me it’s not only logging, the server does not even start, so I’m not able to use Squidex 7 on Apple Silicon for local development. I’d be interested what could have changed between these majors resulting in this behaviour.
One big change is definitely the dotnet version that has been upgraded from .net 6 to .net 7
Ok thanks Sebastion, this is already helpful. Seems like other people have the same issue: https://forums.docker.com/t/dotnet-restore-never-completes-on-m1-mac-when-targeting-linux-amd64-platform/132337/5
A possible solution is outlined on Github:
I got it to work, by using the
mcr.microsoft.com/dotnet/runtime:7.0-bullseye-slim-amd64image, but without specifying the platform for thedocker buildx, or thedotnet publish.
I was not aware that github has mac-os runners. This could be a chance to build mac images in github. If someone wants to have a look it would be really appreciated 
Perhaps we can just build multiplatform images from mac?
Hi Sebastian,
I tried to build multiplatform images from Mac, but it fails to build “AMD64” platform images due to missing /broken dotnet framework libraries.
I spent several hours trying to solve it, but failed. I would have to set up a VM with Windows and try it out from there, but I’m simply overloaded with “new year” requests from work.
Will try it when I get some breathing room.
Krzysztof
P.S. I’m successfuly using Squidex in ARM64v8 targeted image for local development on Mac M1 Max
Ok now I’m confused - are there ARM64v8 targeted images available already? If so, what’s the image name / registry? Because the title of this thread tells something different
I guess he has built his own image.
Ok I see - so what do need to test the mac os runners via github? Should I test to get the Dockerfile built locally and then translate it into Github action? Where is the Github Action config located?
Yes, I would try locally first, then fork and get the runner working: https://github.com/Squidex/squidex/blob/master/.github/workflows/dev.yml
Hi Sebastian,
just wanted to give you a quick update on the progress here. I am able to build a running version of Squidex v7 on arm64. I needed to change the frontend image as well, because Chrome is not supported on arm64, but Chromium is:
FROM node:18.10-slim
ENV CHROME_BIN=/usr/bin/chromium
# Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
# Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer
# installs, work.
RUN apt-get update \
&& apt-get install -y chromium fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 --no-install-recommends \
&& apt-get clean
WORKDIR /puppeteer
# Install puppeteer so it's available in the container.
RUN npm init -y \
&& npm install puppeteer
Afterwards, building both frontend image and finally main image with:
# from dev/frontend-build/
docker buildx build . -t squidex/frontend-build:18.10 --platform linux/arm64
# from root
docker buildx build . -t squidex/squidex-arm --platform linux/arm64
So to make it working we would have to change the frontend image to use Chromium - would that be an option for you?
Yes, you can provide a PR for that. But it does not solve the problem that you have to build on MacOS.
Couldn’t this be solved by making use of the multi platform builds docker buildx is offering? If not, we would probably have to look into the OS X runners you proposed for Github Actions right?
There are a lot of bugs with buildx and mac os right now.
@Sebastian @arm1n I created a pull request to change the frontend to use Chromium instead of Chrome as a first step for multi-platform images. See: https://github.com/Squidex/squidex/pull/1013. I got the Docker image working locally with ARM64 on my M1 Mac.
The Squidex 7 x64-images are apparently not working in Docker Desktop on Apple Silicon (M1) using Rosetta 2 emulation. The Squidex 6 images work fine though…