Flow Enterprise uses the Replicated Administration Console for configuration of many of its settings. The console is located on port 8800 of the server that you installed Replicated on. For example, if you set your hostname to "flow.mycompany.com" during that process, the console is available at https://flow.mycompany.com:8800.
Inside this console, there is a section called Settings that is available from the main menu.
Following that link will lead you to the settings screen that controls Flow Enterprise.
You will see several section of configuration options. This document illustrates how to configure each.
Flow Host Settings
There are several very important settings in this area:
- Flow URL: This is the URL that you want the site to be available on for your users. This should be a full URL in the form of https://flow.mycompany.com/. It is required that this URL be an https:// URL.
- Administrator E-mail Address: This setting should be an administrator e-mail address that can be used in the case of severe system error. It must be a valid e-mail address.
- Use Flow Web Proxy: This setting, when checked, means that we will run a web proxy to provide HTTPS for you. In the past, we did not provide this service, so this setting is turned off by default.
Using the Flow Web Proxy
Note: This setting is recommended. If you have already setup a web proxy and are happy with the performance, then you may disregard this setting. Otherwise, we highly recommend that you turn this setting on.
If you enable the Flow web proxy, then you will be provided with the option to upload new certificates. These certificates should match the hostname configured in the Flow URL setting above. If the certificates you uploaded previously for the administration console already match this hostname, you can leave this setting unchecked. If you enable it, you must provide a combined certificate file and a private key.
This section controls how Flow Enterprise sends e-mail to your end users. To enter the e-mail server settings, you must enable the Use E-mail Server button.
- E-mail Server Hostname: This is the hostname or IP address of your e-mail server.
- E-mail Server Port: This is the port used for your SMTP server. It is usually 25, 465, or 587.
- E-mail Server Login Method: This is the login method that should be used. The default of "Plain" is best for 99% of cases.
- E-mail Server Username: This is the username used to authenticate with your e-mail server. This is highly recommended.
- E-mail Server Password: This is the password that is used to authenticate the user.
- From E-mail Address: This is the address that all e-mails will come from. For example, if you set it to email@example.com, all the e-mails will have that in the "From" field.
- Use TLS For E-mail Server Button: This button, if selected, enables Start TLS for communication with the SMTP server.
You will also notice that you have the ability to test the e-mail settings you've entered by clicking Test Email Settings. This will simply test that authentication is available and will succeed. It will not send an e-mail.
Note: If your email server is an "open relay" and does not require authentication, you must input a single space character " " as your username and password values. A single space will server as a "none" entry, but the field can not be left empty otherwise an invalid null type value will be passed instead of the expected empty un/pw.
Important: You can choose not to enable an e-mail server. When you do, the system will be very limited in its user management functionality. It is HIGHLY recommended that you enable and configure an e-mail server for production.
This section controls your integration with BitBucket's cloud offering. If you use BitBucket Server or Stash internally, this section does not apply to you. If you wish to integrate with BitBucket cloud, please click the Enabled button to enable this integration, and enter the fields requested.
Note: These settings have no bearing on using BitBucket Server or Stash. The settings for these can be found in the document titled Connecting BitBucket Server. You may leave this disabled for now and configure after the installation is complete.
The fields for BitBucket integration are basically an Oauth key/secret pair that can be configured inside BitBucket. For more information on how to configure this integration, please see Connecting to BitBucket Cloud.
This section controls your integration with GitHub's cloud offering. If you use GitHub Enterprise internally, this section does not apply. If you wish to integrate with GitHub cloud, please click Enabled to enable this integration, and enter the fields requested.
Note: These settings have no bearing on using GitHub Enterprise. The settings for these can be found in the document titled Connecting to GitHub Enterprise. You may leave this disabled for now and configure after the installation is complete.
The fields for GitHub integration are basically an Oauth key/secret pair that can be configured inside GitHub. For more information on how to configure this integration, please see Connecting to GitHub Cloud.
This section controls your integration with GitLab's cloud offering. If you use GitLab Enterprise or GitLab Community internally, this section has no bearing. If you wish to integrate with GitLab cloud, please click the "Enabled" button to enable this integration, and enter the fields requested.
The fields for GitLab integration are basically an Oauth key/secret pair that can be configured inside GitLab. For more information on how to configure this integration, please see Connecting to GitLab Cloud.
This section is where you define the location of temporary storage for your repository data. In the field Repository Path, simply enter the path on the server that you prepared.
Note: Make sure that the permissions mode for this directory is 0755 or rwxr-xr-x
This section controls how GitPrime communicates with the required PostgreSQL database. As mentioned in previous documents, Flow Enterprise requires a PostgreSQL database of version 12.1. You will notice on this screen that you are able to choose two options: External or Embedded. We offer an embedded version of PostgreSQL that can be used for evaluation purposes. If you choose this option, your performance and the number of repositories you can analyze will be severely limited.It is highly recommended that you use an external database.
External Database Settings
You should choose External and fill in the fields that are enabled.
The fields available to you are as follows:
- PostgreSQL Server Hostname: This is the hostname or IP address of the database server.
- PostgreSQL Server Port: This is the port of that server. It usually defaults to 5432.
- Flow PostgreSQL Database Name: The name of the database you created on the server.
- Flow PostgreSQL User: The user that has ownership rights to the database.
- Flow PostgresQL User Password: The password for that user.
Embedded Database Settings
If you choose to use the embedded database method, you will be prompted to enter a directory on the server where PostgreSQL can store data. This allows us to persist your data between system restarts.
You should enter a data that exists on the server. It must be set to file permissions mode 0725 or rwx-w-r-x. It must be owned by root:root.
The directory must be empty when you start the installation. PostgreSQL will place its database files in this directory.
This section allows you to upload up to five trusted certificates. This is useful for customers that use self-signed certificates on their internal Git repository servers.
Important: This can be a very dangerous thing. Trusting data from a website can cause significant security holes in your environment. Be 100% sure that the certificates you add here are really meant to be trusted.
To configure the certificates, simply upload the certificate files you want to trust, in PEM format, using the boxes shown below:
This section offers some options that help you tune and size your Flow Enterprise system to your environment.
To show the available settings, click Show Advanced Settings:
Once you have displayed the settings, you can change the following options:
- Enable Cluster Mode: This allows Flow services to be spread across multiple servers (nodes). (version >= 2018.3.2)
- Log Override: This lets you change the level of logging in the application for debugging purposes.
- Number of Commit Processors: This setting determines the number of workers that are started to handle processing your Git repositories. The recommended setting is 2 less than the number of CPUs present on the system. Note: This process is very resource intensive, so changing the number of processors can be very dangerous.
- Number of Project Discovery Processors: This sets the number of workers used to discover new projects for auto-import functionality.
- Number of Project Processors: This controls the number of project processors used to process ticket and pull request data.
- Number of Project Cache Workers: This controls the number of workers used to refresh project listing in the UI.
- Worker Memory Soft Limit: This sets the memory level a git repository processor must reach before we force garbage collection.
- Worker Memory Hard Limit: If a git repository processor hits this amount of memory usage, we will stop it completely to save resources.
- Worker Memory Heap Size: This is the maximum amount of memory that a worker can use before the entire processor is killed and restarted.
- Worker Maximum File Size: This is the maximum size of a file that will be processed for commit data. Any files larger than this setting will be ignored.
If you need help, please email firstname.lastname@example.org for 24/7 assistance.