Configure a Linux Ruby app for Azure App Service
This article describes how Azure App Service runs Ruby apps in a Linux container, and how you can customize the behavior of App Service when needed. Ruby apps must be deployed with all the required gems.
This guide provides key concepts and instructions for Ruby developers who use a built-in Linux container in App Service. If you've never used Azure App Service, you should follow the Ruby quickstart and Ruby with PostgreSQL tutorial first.
Show Ruby version
To show the current Ruby version, run the following command in the Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
To show all supported Ruby versions, run the following command in the Cloud Shell:
az webapp list-runtimes --os linux | grep RUBY
You can run an unsupported version of Ruby by building your own container image instead. For more information, see use a custom Docker image.
Set Ruby version
Run the following command in the Cloud Shell to set the Ruby version to 2.7:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "RUBY:2.7"
If you see errors similar to the following during deployment time:
Your Ruby version is 2.7.3, but your Gemfile specified 2.3.1
rbenv: version `2.3.1' is not installed
It means that the Ruby version configured in your project is different than the version that's installed in the container you're running (
2.7.3 in the example above). In the example above, check both Gemfile and .ruby-version and verify that the Ruby version is not set, or is set to the version that's installed in the container you're running (
2.7.3 in the example above).
Access environment variables
In App Service, you can set app settings outside of your app code. Then you can access them using the standard ENV['<path-name>'] pattern. For example, to access an app setting called
WEBSITE_SITE_NAME, use the following code:
- Check if a Gemfile exists.
bundle install --path "vendor/bundle".
bundle packageto package gems into vendor/cache folder.
Use --without flag
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings BUNDLE_WITHOUT="development,test"
If this setting is defined, then the deployment engine runs
bundle install with
The post-deployment steps don't precompile assets by default. To turn on asset precompilation, set the
ASSETS_PRECOMPILE app setting to
true. Then the command
bundle exec rake --trace assets:precompile is run at the end of the post-deployment steps. For example:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASSETS_PRECOMPILE=true
For more information, see Serve static assets.
By default, the Ruby container starts the Rails server in the following sequence (for more information, see the start-up script):
- Generate a secret_key_base value, if one doesn't exist already. This value is required for the app to run in production mode.
- Set the
RAILS_ENVenvironment variable to
- Delete any .pid file in the tmp/pids directory that's left by a previously running Rails server.
- Check if all dependencies are installed. If not, try installing gems from the local vendor/cache directory.
rails server -e $RAILS_ENV.
You can customize the start-up process in the following ways:
Serve static assets
The Rails server in the Ruby container runs in production mode by default, and assumes that assets are precompiled and are served by your web server. To serve static assets from the Rails server, you need to do two things:
Enable serving static files - To serve static assets from the Ruby container, set the
RAILS_SERVE_STATIC_FILESapp setting to
true. For example:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings RAILS_SERVE_STATIC_FILES=true
Run in non-production mode
The Rails server runs in production mode by default. To run in development mode, for example, set the
RAILS_ENV app setting to
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings RAILS_ENV="development"
However, this setting alone causes the Rails server to start in development mode, which accepts localhost requests only and isn't accessible outside of the container. To accept remote client requests, set the
APP_COMMAND_LINE app setting to
rails server -b 0.0.0.0. This app setting lets you run a custom command in the Ruby container. For example:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings APP_COMMAND_LINE="rails server -b 0.0.0.0"
Set secret_key_base manually
To use your own
secret_key_base value instead of letting App Service generate one for you, set the
SECRET_KEY_BASE app setting with the value you want. For example:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings SECRET_KEY_BASE="<key-base-value>"
Access diagnostic logs
To access the console logs generated from inside your application code in App Service, turn on diagnostics logging by running the following command in the Cloud Shell:
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Possible values for
Verbose. Each subsequent level includes the previous level. For example:
Error includes only error messages, and
Verbose includes all messages.
Once diagnostic logging is turned on, run the following command to see the log stream:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
If you don't see console logs immediately, check again in 30 seconds.
You can also inspect the log files from the browser at
To stop log streaming at any time, type
Open SSH session in browser
To make open a direct SSH session with your container, your app should be running.
Paste the following URL into your browser and replace
<app-name> with your app name:
If you're not yet authenticated, you're required to authenticate with your Azure subscription to connect. Once authenticated, you see an in-browser shell, where you can run commands inside your container.
Any changes you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.
To open a remote SSH session from your local machine, see Open SSH session from remote shell.
robots933456 in logs
You may see the following message in the container logs:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
You can safely ignore this message.
/robots933456.txt is a dummy URL path that App Service uses to check if the container is capable of serving requests. A 404 response simply indicates that the path doesn't exist, but it lets App Service know that the container is healthy and ready to respond to requests.