Ah, the image isn't clickable, but you can try to click on the title.

I'm working on a beginners course that should be released sometime this year.

 ☒ You are correct! Having the bundle volume doesn't map to your development machine's bundle directory. Honestly, I don't think I would want to do this anyways since there are some gems that compile native extensions. Since I develop on a macOS machine, doing this could introduce unexpected errors from the compiled gems. Having the bundle volume is still useful though if you have multiple services that rely on the application code (sidekiq, jsbundling, and cssbundling). So, when you run bundle in the app docker container, the installed gems would be available to the other services.

It's just a preference for than anything. I could have a conditional, but this felt cleaner.

That would be my assumption. I'm not sure what the architecture is on the App Runner, but I would assume that it is a x86/amd64 CPU. I too am working on an Apple Silicon chip and whenever I deploy, I do need to take into consideration the difference in the chipsets. I normally catch any issues in my CI/CD (which runs on an Intel CPU) so it hasn't been too big of a deal here.

Good point. I think if I were to avoid the initial query, I would leave the post index action blank and have the turbo frame tag call an entirely different route. That should work as well.