Traffic Proxy | On-Premise | Urbi Documentation

On-Premise Traffic Proxy service

The Proxy service allows fetching the real-time traffic data for other On-Premise services that demand this data. See the Overview document for details.

On-premise Traffic Proxy service architecture

This On-Premise service comprises the single NGINX reverse proxy service.

The NGINX reverse proxy service:

  1. Fetches the real-time traffic data from public 2GIS Traffic Update servers.

    Traffic Proxy can be deployed in different configurations, which depends on the 2GIS Traffic Update servers used:

    • If the proxy uses the Traffic Update servers, then the data is provided in vector format.
    • If the proxy uses the Traffic Update servers, then the data is provided in raster format.
    • If the proxy uses the Traffic Update servers, then the data is provided in format that is suitable for navigation services.
  2. Serves this data via HTTP.

    Important note:

    Different services require different Traffic Proxy deployments, configured with suitable Traffic Update servers (the setting). See the documentation of corresponding On-Premise services for details.

    Generally, the traffic proxy serves the data to end users and applications that are using On-Premise services. However, there are a few exceptions to this:

    • The traffic proxy serving raster traffic data may also be accessed by SPCore backend.
    • The traffic proxy serving traffic data for navigation services can only be accessed by Navi-Back service.

    Example for the Maps service with MapGL JS API and Tiles API:

    Example internet access diagram for On-Premise Maps service

Internet access must be granted to the NGINX reverse proxy service, so it can access the public 2GIS Traffic Update servers.

Detailed requirements for the NGINX reverse proxy service are listed in the Overview document. Additional information can be found in the Deployment considerations section of this document.

Do the following:

  1. Create the values-traffic-proxy.yaml configuration file:


    dgctlDockerRegistry: <Docker Registry hostname and port>/2gis-on-premise
    replicaCount: <number of the NGINX service replicas> <FQDN of a public 2GIS traffic update server>
            cpu: 10m
            memory: 32Mi
            cpu: 500m
            memory: 256Mi
            - host:


    1. dgctlDockerRegistry: your Docker Registry endpoint where On-Premise services' images reside.

    2. replicaCount: number of the NGINX service replicas.

    3. FQDN of a public 2GIS Traffic Update server. For the list of available servers see the Architecture section of the document.

    4. resources: computational resources settings for service. See the minimal requirements table for the actual information about recommended values.

    5. ingress: configuration of the Ingress resource. Adapt it to your Ingress installation. Note that the path for the host should point to the root: /.

  2. Deploy the service with Helm using created values-traffic-proxy.yaml configuration file:

    helm upgrade --install --atomic --wait-for-jobs --values ./values-traffic-proxy.yaml traffic-proxy 2gis-on-premise/traffic-proxy

To update the service, execute the following command:

helm upgrade --atomic --wait-for-jobs --values ./values-traffic-proxy.yaml traffic-proxy 2gis-on-premise/traffic-proxy

Configure an On-Premise service to use the address as the Traffic API endpoint. See the documentation of corresponding On-Premise services for details.

To test the operability of the service, open the address from a browser. The service should return a list of files containing traffic data.

Alternatively, test the deployment of an On-Premise service that uses the Traffic Proxy service.