# How to access Teamscale via a Reverse Proxy

Instead of making Teamscale directly accessible from the web you can consider operating Teamscale behind a reverse proxy, such as NGINX or Apache. Reverse proxies allow you to fulfill certain requirements, such as different authentication mechanisms or HTTPS support. Moreover, you can seamlessly redirect traffic to different Teamscale instances, e.g., if you want to upgrade to a new version of Teamscale.

# General considerations

Before looking into the configuration that is specific to a reverse proxy solution, some general considerations should be taken into account.

# Public Teamscale URL

The most important one is the URL that Teamscale will be accessible. In practice there are two options:

  • Teamscale is accessible via the domain root, e.g., http://teamscale.mydomain.tld
  • Teamscale is accessible via a subpath, e.g., http://mydomain.tld/teamscale

Both scenarios can be achieved with or without a reverse proxy. Especially if you want to provide another service (e.g. http://mydomain.tld/other-service) you may want to use a reverse proxy.

Using subpaths

It is highly recommended to configure the subpath of the reverse proxy and Teamscale exactly the same way to avoid redirect and path encoding issues.

In practice this means:

  • If Teamscale is accessible via the domain root, do neither specify a subpath in the reverse proxy nor in Teamscale
  • If Teamscale should be accessible via a subpath, configure the reverse proxy and Teamscale using exactly the same subpath. Configuring a different or no subpath in Teamscale is error-prone and requires advanced knowledge of the used reverse proxy.

The subpath of Teamscale can be configured in teamscale.properties using the the following property (if the property is not set, no subpath is configured):

server.urlprefix=teamscale

# Restrict direct access to Teamscale

In the default configuration Teamscale is listening to port 8080 and is available from any browser that can access the server Teamscale is running on. You can restrict direct access to Teamscale in several ways, so access via the reverse proxy cannot be circumvented:

  • If Teamscale and the reverse proxy are running in Docker containers, please use common Docker networking techniques to prevent access, e.g. not exposing the Teamscale port to the host but only to a Docker-network.
  • If Teamscale and the reverse proxy are running on the same server without Docker, one can ensure that the instance is reachable only from the local machine by specifying the bind hostname in teamscale.properties:
    server.bind-hostname=localhost
    
  • If Teamscale and the reverse proxy are running on different servers, firewall rules may be used.

# NGINX

NGINX is a HTTP and reverse proxy server that runs under Windows and Linux. It supports different authentication mechanisms or HTTPS termination and is a lightweight alternative to Apache HTTP Server or Microsoft IIS.

# Basic configuration

# Serve from domain root

The following configuration may be used as a starting point as a starting point if Teamscale should be served at the domain root. It should be adopted to the specific use case according to the documentation.

events {
  worker_connections 1024;
}

http {
  # Do not display the server version
  server_tokens off;

  server {
    # This is the default server listening on port 80
    listen 80 default_server;

    location / {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Host $server_name;
      
      set $teamscaleHost localhost;
      proxy_pass http://$teamscaleHost:8080;
    }
  }
}

The proxy_pass argument to the Teamscale server is extracted as variable $teamscaleHost. This prevents issues with DNS caching that may yield to 502 Bad Gateway errors. You can specify the hostname directly, e.g., proxy_pass http://localhost:8080 if Teamscale is running on the same network or can be accessed via localhost.

WARNING

Ensure that the argument of proxy_pass is specified as protocol://hostname:port and does not include a subpath, even not a trailing slash, e.g. protocol://hostname:port/. Specifying a subpath (URI) will yield to normalization of the request URL before it is passed to Teamscale.

# Serve from subpath

If Teamscale should be served from a subpath, only the location in the nginx configuration needs to be changed. The following example shows the configuration for the subpath /teamscale:

 










    location /teamscale {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Host $server_name;
      
      set $teamscaleHost localhost;
      proxy_pass http://$teamscaleHost:8080;
    }

WARNING

Do not add the subpath to proxy_pass. Instead the subpath needs to be defined in teamscale.properties and set to, e.g., server.urlprefix=teamscale.

# Advanced configuration

# Redirecting the domain root

If you have multiple TS instances mounted on subdirectories (e.g. /teamscale, /staging etc.), you can redirect the root URL (the server name without any path) to one of these:

location = / {
    return 301 https://$host/teamscale;
}

# Apache httpd

Apache is a open-source HTTP server that supports different authentication mechanisms and HTTPS termination. With the mod_proxy Module other applications can be reverse-proxied.

TIP

Apache HTTP Server is mostly used to manage larger domains and sites. Especially for the simple scenario of serving Teamscale on the domain root, the use of NGINX is recommended.

The following configuration may serve as a starting point if Teamscale should be served at a subpath.

ProxyPass /teamscale
  http://localhost:8080/teamscale nocanon
ProxyPassReverse /teamscale
  http://localhost:8080/teamscale
ProxyRequests Off

# This is important, as otherwise some URLs are blocked by Apache
AllowEncodedSlashes NoDecode

Depending on your configuration and goals, slightly different and additional directives are required. Please refer to the Apache manual for more information.