> For the complete documentation index, see [llms.txt](https://guide.cryosparc.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.cryosparc.com/setup-configuration-and-management/how-to-download-install-and-configure/optional-hosting-cryosparc-through-a-reverse-proxy.md).

# (Optional) Hosting CryoSPARC Through a Reverse Proxy

As discussed in [Accessing the CryoSPARC User Interface](/setup-configuration-and-management/how-to-download-install-and-configure/accessing-cryosparc.md), there are various ways in which users can access the CryoSPARC web interface such as through a VPN connection or SSH tunnel. If you would like to host the CryoSPARC interface in a secure manner at a predictable URL, this can be done through a reverse proxy server.

Reverse proxy servers allow for more control over how a user accesses a web application interface over other methods. By controlling incoming network traffic it is able to host the application at a static URL (for example `https://cryosparc.institution.edu`) and ensure all correspondence is secured via HTTPS.

The method in which you host CryoSPARC through a reverse proxy is similar to hosting any other web application. However, the following serve as our recommended minimum requirements:

* All incoming traffic should be served through HTTPS (via a SSL certificate)
* HTTPS traffic requires a valid SSL certificate provided by a certificate authority (CA) for the domain in which you are hosting the interface.
* If the server listens for incoming HTTP traffic, forward all connections to a more secure protocol (HTTPS)
* Ensure traffic is also mediated by an organization-level authentication barrier (for example single sign-on). CryoSPARC should *not* be served via the public internet without any additional authentication checks.

There are many ways to generate a SSL certificate for your domain, however, this will most likely be specific to your institution or organization. If you're unsure of how to generate a SSL certificate for your private network, please consult with your system or network administrator for guidance.

Each institution or private network can have a specific setup requiring custom rules and/or proxy configuration considerations. Generally the example configurations below should be compatible with common reverse proxy installations. Please consult with your system or network administrator for guidance regarding institution-specific protocols for reverse proxy hosting.

The following section will provide example configuration files for common reverse proxy servers given CryoSPARC is running on base port `61000`.

## NGINX

This [NGINX](https://nginx.org/en/) configuration takes advantage of [authenticated origin pulls](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/explanation/) for an added layer of security between the reverse-proxy and a downstream proxy/load balancer.

```
server {
  listen 80;
  listen [::]:80;
  server_name private.domain.dev;
  return 302 https://$server_name$request_uri;
}

server {
  # SSL configuration
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  ssl        on;
  ssl_certificate         /etc/certs/domain.dev/origin-cert.pem;
  ssl_certificate_key     /etc/certs/domain.dev/private-key.pem;
  ssl_client_certificate  /etc/certs/domain.dev/origin-pull-ca.pem;
  ssl_verify_client on;

  server_name   private.domain.dev;
  access_log    /var/log/nginx/private.domain.dev.access.log;
  error_log     /var/log/nginx/private.domain.dev.error.log;

  location / {
    proxy_pass http://127.0.0.1:61000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_request_buffering  off;
    proxy_buffering          off;
    client_max_body_size     0;
  }
}
```

An alternative configuration from our [Discussion Forum](https://discuss.cryosparc.com/t/how-to-run-cryosparc-on-an-https-url-using-an-ssl-certificate/2614/7) that serves the application over HTTPS and redirects incoming HTTP requests.

```
server {
  listen                80;
  server_name           <YOUR_URL>;

  access_log            /var/log/nginx/<YOUR_URL>.http.access.log;
  error_log             /var/log/nginx/<YOUR_URL>.http.error.log;

  location / {
    return 301 https://$server_name$request_uri;
  }
}


server {
  listen                443 ssl;

  server_name           <YOUR_URL>;

  access_log            /var/log/nginx/<YOUR_URL>.access.log;
  error_log             /var/log/nginx/<YOUR_URL>.error.log;

  location / {
    proxy_pass http://127.0.0.1:61000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_request_buffering  off;
    proxy_buffering          off;
    client_max_body_size     0;
  }
  ssl_certificate /etc/letsencrypt/live/<YOUR_URL>/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/<YOUR_URL>/privkey.pem; # managed by Certbot
}
```

## Apache

The following is a simplified [Apache HTTP Server](https://httpd.apache.org/) configuration that illustrates the `RewriteRule`. For production use, we recommend HTTPS instead of HTTP. Additional configuration, not shown here, is required to enable HTTPS.

```
<VirtualHost *:80>
	ProxyRequests Off
	RewriteEngine on
	ProxyPass / http://localhost:61000/
	ProxyPassReverse / http://localhost:61000/
	RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
	RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
	RewriteRule .* ws://localhost:61000%{REQUEST_URI} [P]
</VirtualHost>
```