Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Original Host header needed (needs fixed for Nginx)

...

Table of Content Zone
locationtop
stylesquare

UNIX-like OS or Microsoft Windows

  • UNIX-like operating system (Linux, HP/UX, Mac OSX, etc.) : Many distributions of Linux/Unix come with some of the dependencies below pre-installed or easily installed via updates.  You should consult your particular distribution's documentation or local system administrators to determine what is already available.
  • Microsoft Windows:  While DSpace can be run on Windows servers, most institutions tend to run it on a UNIX-like operating system.


Java JDK 11 or 17 (OpenJDK or Oracle JDK)

Info

JDK17 support was first available in DSpace 7.2.  DSpace 7.1 or 7.0 only supported JDK 11.

Info
titleMake sure to install the JDK and not just the JRE

DSpace requires the full JDK (Java Development Kit) be installed, rather than just the JRE (Java Runtime Environment).  So, please be sure that you are installing the full JDK and not just the JRE.


Note
titleOnly JDK11 and JDK 17 are fully supported

Older versions of Java are unsupported. This includes JDK v7-10.

Newer versions of Java may work (e.g. JDK v12-16), but we do not recommend running them in Production.  We highly recommend running only Java LTS (Long Term Support) releases in Production, as non-LTS releases may not receive ongoing security fixes. As of this DSpace release, JDK11 and JDK 17 are the two most recent Java LTS releases.  As soon as the next Java LTS release is available, we will analyze it for compatibility with this release of DSpace.  For more information on Java releases, see the Java roadmaps for Oracle and/or OpenJDK.


Apache Maven 3.3.x or above (Java build tool)

Info

We recommend using the most recent version of Maven that you can, as newer releases may include performance improvements and security updates.  Maven 3.8.x and 3.6.x are known to work well.

Maven is necessary in the first stage of the build process to assemble the installation package for your DSpace instance. It gives you the flexibility to customize DSpace using the existing Maven projects found in the [dspace-source]/dspace/modules directory or by adding in your own Maven project to build the installation package for DSpace, and apply any custom interface "overlay" changes.

Maven can be downloaded from http://maven.apache.org/download.html   It is also provided via many operating system package managers.

Configuring a Maven Proxy

You can configure a proxy to use for some or all of your HTTP requests in Maven. The username and password are only required if your proxy requires basic authentication (note that later releases may support storing your passwords in a secured keystore‚ in the meantime, please ensure your settings.xml file (usually ${user.home}/.m2/settings.xml) is secured with permissions appropriate for your operating system).

Example:

Code Block
<settings>
  .
  .
  <proxies>
   <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.somewhere.com</host>
      <port>8080</port>
      <username>proxyuser</username>
      <password>somepassword</password>
      <nonProxyHosts>www.google.com|*.somewhere.com</nonProxyHosts>
    </proxy>
  </proxies>
  .
  .
</settings>


Apache Ant 1.10.x or later (Java build tool)

Info

While Apache Ant recommends using v1.10.x for Java 11, we've also had some success with recent versions of 1.9.x (specifically v1.9.15 seems to work fine with Java 11). That said, earlier versions of v1.9.x are not compatible with Java 11.

Apache Ant is required for the second stage of the build process (deploying/installing the application). First, Maven is used to construct the installer ([dspace-source]/dspace/target/dspace-installer), after which Ant is used to install/deploy DSpace to the installation directory.

Ant can be downloaded from the following location: http://ant.apache.org   It is also provided via many operating system package managers.

Relational Database (PostgreSQL)

PostgreSQL 11.x, 12.x, 13.x, 14.x or 15.x (with pgcrypto installed)
  • PostgreSQL can be downloaded from http://www.postgresql.org/.  It is also provided via many operating system package managers.
  • Install the pgcrypto extension.  It will also need to be enabled on your DSpace Database (see Installation instructions below for more info). The pgcrypto extension allows DSpace to create UUIDs (universally unique identifiers) for all objects in DSpace, which means that (internal) object identifiers are now globally unique and no longer tied to database sequences.
    • On most Linux operating systems (Ubuntu, Debian, RedHat), this extension is provided in the "postgresql-contrib" package in your package manager. So, ensure you've installed "postgresql-contrib".
    • On Windows, this extension should be provided automatically by the installer (check your "[PostgreSQL]/share/extension" folder for files starting with "pgcrypto")
  • Unicode (specifically UTF-8) support must be enabled (but this is enabled by default).
  • Once installed, you need to enable TCP/IP connections (DSpace uses JDBC):
    • In postgresql.conf: uncomment the line starting: listen_addresses = 'localhost'.  This is the default, in recent PostgreSQL releases, but you should at least check it.
    • Then tighten up security a bit by editing pg_hba.conf and adding this line:

      Code Block
      host dspace dspace 127.0.0.1 255.255.255.255 md5

      This should appear before any lines matching all databases, because the first matching rule governs.

    • Then restart PostgreSQL.
Oracle (UNSUPPORTED AS OF 7.6)
Warning
titleAs of the 7.6 release, Oracle databases are no longer supported

Oracle support has been removed as was previously announced in March 2022 on our mailing lists.  See https://github.com/DSpace/DSpace/issues/8214

All DSpace sites should now use PostrgreSQL (see above)

  • Details on acquiring Oracle can be downloaded from the following location: http://www.oracle.com/database/. You will need to create a database for DSpace. Make sure that the character set is one of the Unicode character sets. DSpace uses UTF-8 natively, and it is suggested that the Oracle database use the same character set. You will also need to create a user account for DSpace (e.g. dspace) and ensure that it has permissions to add and remove tables in the database. Refer to the Quick Installation for more details.
    • NOTE: If the database server is not on the same machine as DSpace, you must install the Oracle client to the DSpace server and point tnsnames.ora and listener.ora files to the database the Oracle server.

Apache Solr 8.x (full-text index/search service)

Warning

Solr 8.11.1 or above is recommended as all prior 8.x releases are vulnerable to CVE-2021-44228 (log4j critical vulnerability). If you must use a prior version of 8.x, make sure to add "-Dlog4j2.formatMsgNoLookups=true" to your SOLR_OPTS environment variable, see https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228


Note

Solr 9 is not yet fully supported, but can be used provided that you make minor modification to the out-of-the-box "search/conf/solrconfig.xml" that comes with DSpace 7.  See this below comment for details.


Note

Make sure to install Solr with Authentication disabled (which is the default).  DSpace does not yet support authentication to Solr (see https://github.com/DSpace/DSpace/issues/3169).  Instead, we recommend placing Solr behind a firewall and/or ensuring port 8983 (which Solr runs on) is not available for public/anonymous access on the web. Solr only needs to be accessible to requests from the DSpace backend.

Solr can be obtained at the Apache Software Foundation site for Lucene and Solr.  You may wish to read portions of the quick-start tutorial to make yourself familiar with Solr's layout and operation.  Unpack a Solr .tgz or .zip archive in a place where you keep software that is not handled by your operating system's package management tools, and arrange to have it running whenever DSpace is running.  You should ensure that Solr's index directories will have plenty of room to grow.  You should also ensure that port 8983 is not in use by something else, or configure Solr to use a different port.

If you are looking for a good place to put Solr, consider /opt or /usr/local.  You can simply unpack Solr in one place and use it.  Or you can configure Solr to keep its indexes elsewhere, if you need to – see the Solr documentation for how to do this.

It is not necessary to dedicate a Solr instance to DSpace, if you already have one and want to use it.  Simply copy DSpace's cores to a place where they will be discovered by Solr.  See below.

Servlet Engine (Apache Tomcat 9, Jetty, Caucho Resin or equivalent)

Note

Only Tomcat 9 is supported at this time. Tomcat 10 is incompatible with Tomcat 9 and will not be supported until DSpace 8.0 at the earliest.  See https://github.com/DSpace/DSpace/issues/8713 for more details

  • Apache Tomcat 9. Tomcat can be downloaded from the following location: http://tomcat.apache.org.    It is also provided via many operating system package managers.
    • The Tomcat owner (i.e. the user that Tomcat runs as) must have read/write access to the DSpace installation directory (i.e. [dspace])There are a few common ways this may be achieved:
      • One option is to specifically give the Tomcat user (often named "tomcat") ownership of the [dspace] directories, for example:

        Code Block
        # Change [dspace] and all subfolders to be owned by "tomcat"
        chown -R tomcat:tomcat [dspace]


      • Another option is to have Tomcat itself run as a new user named "dspace" (see installation instructions below).  Some operating systems make modifying the Tomcat "run as" user easily modifiable via an environment variable named TOMCAT_USER.  This option may be more desirable if you have multiple Tomcat instances running, and you do not want all of them to run under the same Tomcat owner.
    • On Debian systems, you may also need to modify or override the "tomcat.service" file to specify the DSpace installation directory in the list of ReadWritePaths.  For example:

      Code Block
      # Replace [dspace] with the full path of your DSpace install
      ReadWritePaths=[dspace]


    • You need to ensure that Tomcat a) has enough memory to run DSpace, and b) uses UTF-8 as its default file encoding for international character support. So ensure in your startup scripts (etc) that the following environment variable is set: JAVA_OPTS="-Xmx512M -Xms64M -Dfile.encoding=UTF-8"
    • Modifications in [tomcat]/conf/server.xml : You also need to alter Tomcat's default configuration to support searching and browsing of multi-byte UTF-8 correctly. You need to add a configuration option to the <Connector> element in [tomcat]/config/server.xml: URIEncoding="UTF-8" e.g. if you're using the default Tomcat config, it should read:

      Code Block
      languagehtml/xml
      <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
      <Connector port="8080"
                    minSpareThreads="25"
                    enableLookups="false"
                    redirectPort="8443"
                    connectionTimeout="20000"
                    disableUploadTimeout="true"
                    URIEncoding="UTF-8"/>
      

      You may change the port from 8080 by editing it in the file above, and by setting the variable CONNECTOR_PORT in server.xml.  You should set the URIEncoding even if you are running Tomcat behind a reverse proxy (Apache HTTPD, Nginx, etc.) via AJP.

  • Jetty or Caucho Resin 
    • DSpace 7 has not been tested with Jetty or Caucho Resin, after the switch to Java 11
    • Older versions of DSpace were able to run on a Tomcat-equivalent servlet Engine, such as Jetty (https://www.eclipse.org/jetty/) or Caucho Resin (http://www.caucho.com/). If you choose to use a different servlet container, please ensure that it supports Servlet Spec 3.1 (or above).
    • Jetty and Resin are configured for correct handling of UTF-8 by default.

(Optional) IP to City Database for Location-based Statistics

Optionally, if you wish to record the geographic locations of clients in DSpace usage statistics records, you will need to install (and regularly update) one of the following:

  • Either, a copy of MaxMind's GeoLite City database (in MMDB format)
    • NOTE: Installing MaxMind GeoLite2 is free.  However, you must sign up for a (free) MaxMind account in order to obtain a license key to use the GeoLite2 database.
    • You may download GeoLite2 directly from MaxMind, or many Linux distributions provide the geoipupdate tool directly via their package manager.  You will still need to configure your license key prior to usage.
    • Once the "GeoLite2-City.mmdb" database file is installed on your system,  you will need to configure its location as the value of usage-statistics.dbfile in your local.cfg configuration file
    • See the "Managing the City Database File" section of SOLR Statistics for more information about using a City Database with DSpace.
  • Or, you can alternatively use/install DB-IP's City Lite database (in MMDB format)
    • This database is also free to use, but does not require an account to download.
    • Once the "dbip-city-lite.mmdb" database file is installed on your system,  you will need to configure its location as the value of usage-statistics.dbfile in your local.cfg configuration file
    • See the "Managing the City Database File" section of SOLR Statistics for more information about using a City Database with DSpace.

Git (code version control)

Currently, there is a known bug in DSpace where a third-party Maven Module expects git to be available (in order to support the ./dspace version commandline tool).  We are working on a solution within this ticket: https://github.com/DSpace/DSpace/issues/6772

For the time being, you can work around this problem by installing Git locally: https://git-scm.com/downloads

...

  1. Download Code (to [dspace-angular]): Download the latest dspace-angular release from the DSpace GitHub repository. You can choose to either download the zip or tar.gz file provided by GitHub, or you can use "git" to checkout the appropriate tag (e.g. dspace-7.2) or branch.
    1. NOTE: For the rest of these instructions, we'll refer to the source code location as [dspace-angular].
  2. Install Dependencies: Install all required local dependencies by running the following from within the unzipped [dspace-angular] directory

    Code Block
    # change directory to our repo
    cd [dspace-angular]
    
    # install the local dependencies
    yarn install
    
    # NOTE: Some dependencies occasionally get overly strict over exact versions of Node & Yarn.
    # If you are running a supported version of Node & Yarn, but see a message like 
    # `The engine "node" is incompatible with this module.`, you can disregard it using this flag:
    # yarn install --ignore-engines


  3. Build/Compile: Build the User Interface for Production. This builds source code (under [dspace-angular]/src/) to create a compiled version of the User Interface in the [dspace-angular]/dist folder.  This /dist folder is what we will deploy & run to start the UI.

    Code Block
    yarn build:prod


    1. You only need to rebuild the UI application if you change source code (under [dspace-angular]/src/).  Simply changing the configurations (e.g. config.prod.yml, see below) do not require a rebuild, but only require restarting the UI.
  4. Deployment (to [dspace-ui-deploy]): (Only recommended for Production setups) Choose/Create a directory on your server where you wish to run the compiled User Interface. We'll call this [dspace-ui-deploy].

    Info
    title[dspace-ui-deploy] vs [dspace-angular]

    [dspace-angular] is the directory where you've downloaded and built the UI source code (per the instructions above).  For deployment/running the UI, we recommend creating an entirely separate [dspace-ui-deploy] directory. This keeps your running, production User Interface separate from your source code directory and also minimizes downtime when rebuilding your UI.  You may even choose to deploy to a [dspace-ui-deploy] directory on a different server (and copy the /dist directory over via FTP or similar).

    If you are installing the UI for the first time, or just want a simple setup, you can choose to have [dspace-ui-deploy] and [dspace-angular] be the same directory. This would mean you don't have to copy your /dist folder to another location. However, the downside is that your running site will become unresponsive whenever you do a re-build/re-compile (i.e. rerun "yarn build:prod") as this build process will first delete the [dspace-angular]/dist directory before rebuilding it.

    1. Copy the entire [dspace-angular]/dist/ folder to this location. For example:

      Code Block
      cp -r [dspace-angular]/dist [dspace-ui-deploy]

       

    2. WARNING: At this time, you MUST copy the entire "dist" folder and make sure NOT to rename it.  Therefore, the directory structure should look like this: 

      Code Block
      titleContents of \[dspace-ui-deploy\] folder
      [dspace-ui-deploy]
          /dist
             /browser (compiled client-side code)
             /server  (compiled server-side code, including "main.js")
          /config     (Optionally created in the "Configuration" step below)
             /config.prod.yml (Optionally created in the "Configuration" step below)


    3. NOTE: the OS account which runs the UI via Node.js (see below) MUST have write privileges to the [dspace-ui-deploy] directory (because on startup, the runtime configuration is written to [dspace-ui-deploy]/dist/browser/assets/config.json)
  5. Configuration: You have two options for User Interface Configuration, Environment Variables or YAML-based configuration (config.prod.yml).  Choose one!

    1. YAML configuration: Create a "config.prod.yml" at [dspace-ui-deploy]/config/config.prod.yml.  You may wish to use the [dspace-angular]/config/config.example.yml as a starting point. This config.prod.yml file can be used to override any of the default configurations listed in the config.example.yml (in that same directory). At a minimum this file MUST include a "rest" section (and may also include a "ui" section),  similar to the following (keep in mind, you only need to include settings that you need to modify).  

      Code Block
      languageyml
      titleExample config.prod.yml
      # The "ui" section defines where you want Node.js to run/respond. It often is a *localhost* (non-public) URL, especially if you are using a Proxy.
      # In this example, we are setting up our UI to just use localhost, port 4000. 
      # This is a common setup for when you want to use Apache or Nginx to handle HTTPS and proxy requests to Node on port 4000
      ui:
        ssl: false
        host: localhost
        port: 4000
        nameSpace: /
      
      # This example is valid if your Backend is publicly available at https://api.mydspace.edu/server/
      # The REST settings MUST correspond to the primary/public URL of the backend. Usually, this means they must be kept in sync
      # with the value of "dspace.server.url" in the backend's local.cfg
      rest:
        ssl: true
        host: api.mydspace.edu
        port: 443
        nameSpace: /server


    2. Environment variables: Every configuration in the UI may be specified via an Environment Variable. See Configuration Override in the User Interface Configuration documentation for more details. For example, the below environment variables provide the same setup as the config.prod.yml example above.

      Code Block
      titleExample Environment Variables
      # All environment variables MUST 
      # (1) be prefixed with "DSPACE_"
      # (2) use underscores as separators (no dots allowed), and 
      # (3) use all uppercase
      
      # "ui" section
      DSPACE_UI_SSL = false
      DSPACE_UI_HOST = localhost
      DSPACE_UI_PORT = 4000
      DSPACE_UI_NAMESPACE = /
      
      # "rest" section
      DSPACE_REST_SSL = true
      DSPACE_REST_HOST = api.mydspace.edu
      DSPACE_REST_PORT = 443
      DSPACE_REST_NAMESPACE = /server


      1. NOTE: When using PM2, some may find it easier to use Environment variables, as it allows you to specify DSpace UI configs within your PM2 configuration. See PM2 instructions below.

    3. Configuration Hints:
      1. See the User Interface Configuration documentation for a list of all available configurations.
      2. In the "ui" section above, you may wish to start with "ssl: false" and "port: 4000" just to be certain that everything else is working properly before  adding HTTPS support. KEEP IN MIND, we highly recommend always using HTTPS for Production. (See section on HTTPS below)
      3. (Optionally) Test the connection to your REST API from the UI from the command-line.  This is not required, but it can sometimes help you discover immediate configuration issues if the test fails.
        1. If you are using YAML configs, copy your config.prod.yml back into your source code folder at [dspace-angular]/config/config.prod.yml 
        2. From [dspace-angular], run yarn test:rest This script will attempt a basic Node.js connection to the REST API that is configured in your "config.prod.yml" file and validate the response.
        3. A successful connection should return a 200 Response and all JSON validation checks should return "true"
        4. If you receive a connection error or different response code, you MUST fix your REST API before the UI will be able to work.  See also the "Common Installation Issues" below.  If you receive an SSL error, see "Using a Self-Signed SSL Certificate causes the Frontend to not be able to access the Backend"
  6. Start up the User Interface:  The compiled User Interface only requires Node.js to run.  However, most users may want to use PM2 (or a similar Node.js process manager) in Production to provide easier logging and restart tools.
    1. Quick Start: To quickly startup / test the User Interface, you can just use Node.js.  This is only recommended for quickly testing the UI is working, as no logs are available.

      Code Block
      # You MUST start the UI from within the deployment directory
      cd [dspace-ui-deploy]
      
      # Run the "server/main.js" file to startup the User Interface
      node ./dist/server/main.js
      
      # Stop the UI by killing it via Ctrl+C


    2. Run via PM2: Using PM2 (or a different Node.js process manager) is highly recommended for Production scenarios. Here's an example of a Production setup of PM2.
      1. First you need to create a PM2 JSON configuration file which will run the User Interface.  This file can be named anything & placed where ever you like, but you may want to save it to your deployment directory (e.g. [dspace-ui-deploy]/dspace-ui.json). 

        Code Block
        titledspace-ui.json
        {
            "apps": [
                {
                   "name": "dspace-ui",
                   "cwd": "/full/path/to/dspace-ui-deploy",
                   "script": "dist/server/main.js",
                   "instances": "max",
                   "exec_mode": "cluster",
                   "env": {
                      "NODE_ENV": "production"
                   }
                }
            ]
        }


        1. NOTE: The "cwd" setting MUST correspond to your [dspace-ui-deploy] folder path.
        2. NOTE #2: The "exec_mode" and "instances" settings are optional but highly recommended.  Setting "exec_mode" to "cluster" enable's PM2's cluster mode. This will provide better performance in production as it allows PM2 to scale your site across multiple CPUs. The "instances" setting tells PM2 how many CPUs to scale across ("max" means all CPUs, but you can also specify a number.)
        3. NOTE #3: If you wanted to configure your UI using Environment Variables, specify those Environment Variables under the "env" section.  For example:  

          Code Block
          titleConfiguration via Environment Variables
          "env": {
             "NODE_ENV": "production",
             "DSPACE_REST_SSL": "true",
             "DSPACE_REST_HOST": "api7.dspace.org",
             "DSPACE_REST_PORT": "443",
             "DSPACE_REST_NAMESPACE": "/server"
          }


        4. NOTE #4: If you are using Windows, there are two other rules to keep in mind in this JSON configuration. First, all paths must include double backslashes (e.g. "C:\\dspace-ui-deploy").  Second, "cluster" mode is required.  Here's an example configuration for Windows:

          Code Block
          titledspace-ui.json (for Windows)
          {
              "apps": [
                  {
                     "name": "dspace-ui",
                     "cwd": "C:\\full\\path\\to\\dspace-ui-deploy",
                     "script": "dist\\server\\main.js",
                     "instances": "max",
                     "exec_mode": "cluster",
                     "env": {
                        "NODE_ENV": "production"
                     }
                  }
              ]
          }


      2. Now, start the application using PM2 using the configuration file you created in the previous step

        Code Block
        # In this example, we are assuming the config is named "dspace-ui.json"
        pm2 start dspace-ui.json
        
        # To see the logs, you'd run
        # pm2 logs
        
        # To stop it, you'd run
        # pm2 stop dspace-ui.json
        
        # If you need to change your PM2 configs, delete the old config and restart
        # pm2 delete dspace-ui.json


      3. For more PM2 commands see https://pm2.keymetrics.io/docs/usage/quick-start/
      4. HINT: You may also want to install/configure pm2-logrotate to ensure that PM2's log folder doesn't fill up over time.
      5. Did PM2 not work or throw an immediate error? It's likely that something in your UI installation or configuration is incorrect.  Check the PM2 logs ("pm2 logs") first for errors. If the problem is not obvious, try to see if you can run the UI using the "Quick Start" method (using just Node.js) instead. Once "Quick Start" is working, try PM2 again.
      6. If neither PM2 nor the "Quick Start" method works for you: then see the "User Interface never appears (no content appears)" section in the Commons Installation Issues below
  7. Test it out: At this point, the User Interface should be available at the URL you configured!
    1. For an example of what the default frontend looks like, visit the Demo Frontend: https://demo7.dspace.org/ 
    2. If the UI fails to start or throws errors, it's likely a configuration issue.  See Commons Installation Issues below for common error messages you may see and how to resolve them.
    3. If you have an especially difficult issue to debug, you may wish to stop PM2. Instead, try running the UI via the "Quick Start" method (using just Node.js).  This command might provide a more specific error message to you, if PM2 is not giving enough information back.
  8. Add HTTPS support: For HTTPS (port 443) support, you have two options
    1. (Recommended) Install either Apache HTTPD or Nginx to act as a "reverse proxy" for the frontend (and backend).  This allows you to manage HTTPS (SSL certificates) in either Apache HTTPD or Nginx, and proxy all requests to the frontend (running on port 4000) and backend (running on port 8080). This is our current recommended approach.  These instructions are specific to Apache, but a similar setup can be achieved with Nginx.
      1. If you already have Apache / Nginx installed for the backend, you can use the same Apache / Nginx.  You can also choose to install a separate one (either approach is fine).
        1. Install Apache HTTPD, e.g. sudo apt install apache2
        2. Install the mod_proxy and mod_proxy_http modules, e.g. sudo a2enmod proxy; sudo a2enmod proxy_http
        3. Restart Apache to enable
        4. Obtain an SSL certificate for HTTPS support. If you don't have one yet, you can use Let's Encrypt (for free) using the "certbot" tool: https://certbot.eff.org/
      2. Apache HTTPD sample configuration:

        1. Now, setup (or update) the new VirtualHost for your UI site (preferably using HTTPS / port 443) which proxies all requests to PM2 running on port 4000.

          Code Block
          <VirtualHost _default_:443>
              # Add your domain here. We've added "my.dspace.edu" as an example
              ServerName my.dspace.edu
              .. setup your host how you want, including log settings...
          
              # Required to make correct sitemap links in /robots.txt
              ProxyPreserveHost On
          
              # These SSL settings are identical to those for the backend installation (see above)
              # If you already have the backend running HTTPS, just add the new Proxy settings below.
              SSLEngine on
              SSLCertificateFile [full-path-to-PEM-cert]
              SSLCertificateKeyFile [full-path-to-cert-KEY]
              # LetsEncrypt certificates (and possibly others) may require a chain file be specified
              # in order for the UI / Node.js to validate the HTTPS connection.
              #SSLCertificateChainFile [full-path-to-chain-file]
          
              # These Proxy settings are for the backend. They are described in the backend installation (see above)
              # If you already have the backend running HTTPS, just append the new Proxy settings below.
              # Proxy all HTTPS requests to "/server" from Apache to Tomcat via AJP connector
              # (In this example: https://my.dspace.edu/server/ will display the REST API)
              ProxyPass /server ajp://localhost:8009/server
              ProxyPassReverse /server ajp://localhost:8009/server
          
              # [NEW FOR UI:] Proxy all HTTPS requests from Apache to PM2 on localhost, port 4000
              # NOTE that this proxy URL must match the "ui" settings in your config.prod.yml
              # (In this example: https://my.dspace.edu/ will display the User Interface)
              ProxyPass / http://localhost:4000/
              ProxyPassReverse / http://localhost:4000/
          </VirtualHost>


      3. NGinx sample configuration
        1. Sample NGinx "server block" configuration. Keep in mind we are only providing basic example settings.

          Code Block
          # Setup HTTPS access
          server {
            listen 443 ssl;
            # Add your domain here. We've added "my.dspace.edu" as an example
            server_name my.dspace.edu;
          
            # Add your SSL certificate/key path here
            # NOTE: For LetsEncrypt, the certificate should be the full certificate chain file
            # These SSL settings are identical to those for the backend installation (see above)
            # If you already have the backend running HTTPS, just add the new Proxy settings below.
            ssl_certificate my.dspace.edu.crt (or PEM);
            ssl_certificate_key my.dspace.edu.key;
          
            # Proxy all HTTPS requests to "/server" from NGinx to Tomcat on port 8080
            # These Proxy settings are for the backend. They are described in the backend installation (see above)
            location /server {
              proxy_set_header X-Forwarded-Proto https;
              proxy_set_header X-Forwarded-Host $host;
              proxy_pass http://localhost:8080/server;
            }
          
            # [NEW FOR UI:] Proxy all HTTPS requests from NGinx to PM2 on localhost, port 4000
            # NOTE that this proxy URL must match the "ui" settings in your config.prod.yml
            # (In this example: https://my.dspace.edu/ will display the User Interface)
            location / {
              proxy_pass http://localhost:4000/;
            }
          }


      4. HINT#1: Because you are using a proxy for HTTPS support, in your User Interface Configuration, your "ui" settings will still have "ssl: false" and "port: 4000".  This is perfectly OK!
      5. HINT#2: to force the UI to connect to the backend using HTTPS, you should verify your "rest" settings in your User Interface Configuration match the "dspace.server.url" in your backend's "local.cfg" and both use the HTTPS URL.  So, if your backend (REST API) is proxied to https://my.dspace.edu/server/, both those settings should specify that HTTPS URL.
      6. HINT#3: to force the backend to recognize the HTTPS UI, make sure to update your "dspace.ui.url" in your backend's "local.cfg" is updated to use the new HTTPS UI URL (e.g. https://my.dspace.edu).
    2. (Alternatively) You can use the basic HTTPS support built into our UI and Node server.  (This may currently be better for non-Production environments as it has not been well tested) 
      1. Create a [dspace-ui-deploy]/config/ssl/ folder and add a key.pem and cert.pem to that folder (they must have those exact names)
      2. In your User Interface Configuration, go back and update the following:
        1. Set "ui > ssl" to true
        2. Update "ui > port" to be 443
          1. In order to run Node/PM2 on port 443, you also will likely need to provide node with special permissions, like in this example.
      3. Restart the UI
      4. Keep in mind, while this setup is simple, you may not have the same level of detailed, Production logs as you would with Apache HTTPD or Nginx

...