Run Rails commands on the production server. Use when the user says "on prod", "on production", "on server", or wants to query/inspect production data.
Execute Rails commands on the production server via SSH.
Read DEPLOY_SERVER_IP, DEPLOY_SERVER_PORT, and DEPLOY_REMOTE_PATH from the .env file in the project root.
source .env
The production Docker setup uses SECRET_KEY_BASE from /rails/storage/.docker-env. All Rails commands must source this file first.
For simple one-liners:
ssh -p $DEPLOY_SERVER_PORT $DEPLOY_SERVER_IP "cd $DEPLOY_REMOTE_PATH && docker compose exec -T web bash -c 'source /rails/storage/.docker-env && bin/rails runner \"<ruby code>\"'"
For multi-line scripts (preferred):
Write a script to the mounted storage/ volume, execute it, then clean up:
ssh -p $DEPLOY_SERVER_PORT $DEPLOY_SERVER_IP "cat > $DEPLOY_REMOTE_PATH/storage/task.rb << 'RUBY'
<ruby code here>
RUBY
cd $DEPLOY_REMOTE_PATH && docker compose exec -T web bash -c 'source /rails/storage/.docker-env && bin/rails runner /rails/storage/task.rb'"
Always clean up after:
ssh -p $DEPLOY_SERVER_PORT $DEPLOY_SERVER_IP "rm -f $DEPLOY_REMOTE_PATH/storage/task.rb"
$ARGUMENTS describes what the user wants to do on production. Translate it into the appropriate Rails runner script.
image_processing gem warning in output is harmless — ignore it.web (Rails server) and jobs (Solid Queue worker). Use web by default.