If this is a new deployment, you may be able to shell into the server and run the container locally on the server. Shell into the container and try basic things like opening the rails console from within the container. Try touching a record to make sure the database connection is working. If all of that checks out, try running the rails server. You should have an entry point shell script or a CMD in the dockerfile which starts up the rails process. Typically, what I've found is that the deployment will go through, but there's something missing that keeps the rails server from running properly.

  dan.legrand  That's correct. I personally use ollama and have an haproxy server running in front of it. It allows me to use multiple computers/gpus to serve small models (typically 8B param ones). The haproxy acts as a load balancer between the computers so I can handle multiple requests concurrently and have the high availability. 

Ollama is a self hosted solution so the model and all of the inference happens on the machine that you have it hosted on. So, no prompts or inference goes out to other providers.

This episode, https://www.driftingruby.com/episodes/haproxy, is where I demonstrate setting up HAProxy with Ollama if you're interested.

Did you have anything specific with github actions or just an updated version of https://www.driftingruby.com/episodes/kamal-in-github-actions but with Kamal 2?

It depends on the episode. 

Most of them you'll need yarn. I've recently switched to importmaps to make it a bit easier to get going with the source codes.

# in the extracted folder
bundle
yarn
bin/rails db:prepare # or db:migrate db:seed or db:setup
bin/dev