Install API server and Controller

  1. Introduction
  2. Install dependencies
  3. Set up database
  4. Update config.yml
  5. Update nginx configuration
  6. Install arvados-api-server and arvados-controller
  7. Confirm working installation


The Arvados core API server consists of four services: PostgreSQL, Arvados Rails API, Arvados Controller, and Nginx.

Here is a simplified diagram showing the relationship between the core services. Client requests arrive at the public-facing Nginx reverse proxy. The request is forwarded to Arvados controller. The controller is able handle some requests itself, the rest are forwarded to the Arvados Rails API. The Rails API server implements the majority of business logic, communicating with the PostgreSQL database to fetch data and make transactional updates. All services are stateless, except the PostgreSQL database. This guide assumes all of these services will be installed on the same node, but it is possible to install these services across multiple nodes.

Install dependencies

  1. Install PostgreSQL
  2. Install Ruby and Bundler
  3. Install nginx
  4. Install Phusion Passenger

Set up database

  1. Start a shell for the postgres user:
    # su postgres
  2. Generate a new database password:
    postgres$ tr -dc 0-9a-zA-Z </dev/urandom | head -c25; echo
    Record this. You’ll need it when you set up the Rails server later.
  3. Create a database user with the password you generated:
    postgres$ createuser --encrypted --no-createrole --no-superuser --pwprompt arvados
      Enter password for new role: yourgeneratedpassword
      Enter it again: yourgeneratedpassword
  4. Create a database owned by the new user:
    postgres$ createdb arvados_production -T template0 -E UTF8 -O arvados
  5. Enable the pg_trgm extension
    postgres$ psql arvados_production -c "CREATE EXTENSION IF NOT EXISTS pg_trgm"
  6. Exit the postgres user shell:
    postgres$ exit

Update config.yml

Starting from an empty config.yml file, add the following configuration keys.


    SystemRootToken: "$system_root_token"
    ManagementToken: "$management_token"
      BlobSigningKey: "$blob_signing_key"

These secret tokens are used to authenticate messages between Arvados components.

  • SystemRootToken is used by Arvados system services to authenticate as the system (root) user when communicating with the API server.
  • ManagementToken is used to authenticate access to system metrics.
  • Collections.BlobSigningKey is used to control access to Keep blocks.

Each token should be a string of at least 50 alphanumeric characters. You can generate a suitable token with the following command:

~$ tr -dc 0-9a-zA-Z </dev/urandom | head -c50 ; echo


        host: localhost
        user: arvados
        password: $postgres_password
        dbname: arvados_production

Replace the $postgres_password placeholder with the password you generated during database setup .


        ExternalURL: ""
          "http://localhost:8003": {}
        # Does not have an ExternalURL
          "http://localhost:8004": {}

Replace with the hostname that you previously selected for the API server.

The Services section of the configuration helps Arvados components contact one another (service discovery). Each service has one or more InternalURLs and an ExternalURL. The InternalURLs describe where the service runs, and how the Nginx reverse proxy will connect to it. The ExternalURL is how external clients contact the service.

Update nginx configuration

Use a text editor to create a new file /etc/nginx/conf.d/arvados-api-and-controller.conf with the following configuration. Options that need attention are marked in red.

proxy_http_version 1.1;

# When Keep clients request a list of Keep services from the API
# server, use the origin IP address to determine if the request came
# from the internal subnet or it is an external client.  This sets the
# $external_client variable which in turn is used to set the
# X-External-Client header.
# The API server uses this header to choose whether to respond to a
# "available keep services" request with either a list of internal keep
# servers (0) or with the keepproxy (1).
# Following the example here, update the netmask
# to match your private subnet.
# Update and add lines as necessary with the public IP
# address of all servers that can also access the private network to
# ensure they are not considered 'external'.

geo $external_client {
  default        1;   0;  0;     0;

# This is the port where nginx expects to contact arvados-controller.
upstream controller {
  server     localhost:8003  fail_timeout=10s;

server {
  # This configures the public https port that clients will actually connect to,
  # the request is reverse proxied to the upstream 'controller'

  listen       443 ssl;

  ssl_certificate     /YOUR/PATH/TO/cert.pem;
  ssl_certificate_key /YOUR/PATH/TO/cert.key;

  # Refer to the comment about this setting in the passenger (arvados
  # api server) section of your Nginx configuration.
  client_max_body_size 128m;

  location / {
    proxy_pass               http://controller;
    proxy_redirect           off;
    proxy_connect_timeout    90s;
    proxy_read_timeout       300s;
    proxy_max_temp_file_size 0;
    proxy_request_buffering  off;
    proxy_buffering          off;
    proxy_http_version       1.1;

    proxy_set_header      Host              $http_host;
    proxy_set_header      Upgrade           $http_upgrade;
    proxy_set_header      Connection        "upgrade";
    proxy_set_header      X-External-Client $external_client;
    proxy_set_header      X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header      X-Forwarded-Proto https;
    proxy_set_header      X-Real-IP         $remote_addr;

server {
  # This configures the Arvados API server.  It is written using Ruby
  # on Rails and uses the Passenger application server.

  listen localhost:8004;
  server_name localhost-api;

  root /var/www/arvados-api/current/public;
  index  index.html index.htm index.php;

  passenger_enabled on;
  passenger_preload_bundler on;

  # This value effectively limits the size of API objects users can
  # create, especially collections.  If you change this, you should
  # also ensure the following settings match it:
  # * `client_max_body_size` in the previous server section
  # * `API.MaxRequestSize` in config.yml
  client_max_body_size 128m;

Install arvados-api-server and arvados-controller

Red Hat, AlmaLinux, and Rocky Linux

# dnf install arvados-api-server arvados-controller

Debian and Ubuntu

# apt install arvados-api-server arvados-controller

Start the service

# systemctl enable --now arvados-controller
# systemctl status arvados-controller

If systemctl status indicates it is not running, use journalctl to check logs for errors:

# journalctl -n12 --unit arvados-controller

Confirm working installation

We recommend using the Cluster diagnostics tool. The first few tests (10, 20, 30) will succeed if you have a working API server and controller. Of course, tests for services that you have not yet installed and configured will fail.

Here are some other checks you can perform manually.

Confirm working controller

$ curl

Confirm working Rails API server

$ curl

Confirm that you can use the system root token to act as the system root user

$ curl -H "Authorization: Bearer $system_root_token"


If you are getting TLS errors, make sure the ssl_certificate directive in your nginx configuration has the full certificate chain

Logs can be found in /var/www/arvados-api/current/log/production.log and using journalctl -u arvados-controller.

See also the admin page on Logging .

Previous: Maintenance and upgrading Next: Cluster diagnostics tool

The content of this documentation is licensed under the Creative Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.