Editing the ".env" file and running the application

Edit the ".env" file on each machine that you are setting up according to the articles in Configuring Hyperscience.

On initial install, when updating to a new version, and every time the “.env” file is edited, you must run the following command on one application machine:

sudo bash run.sh init

Running it on additional application machines is not necessary but will not harm your configuration.

Also, on each machine in the cluster, after running the above init command (whether for an initial install or a configuration change), you must start/update the running application containers:

sudo bash run.sh

This will automatically start up the required application roles based on the configuration you have set. As long as Docker or Podman is configured to start at boot, then the application will also start at boot.

One of the roles is the frontend role, which will run on all machines. We recommend putting an application load balancer in front of the cluster for redundancy instead of just hitting the frontend on a single machine in the cluster.

Note that the .env file may contain sensitive data such as database passwords and S3 secret keys. To restrict access to this file, you can add the following permissions:

# This command restricts the file to be owned by root and the Docker group
chown root:docker 

# This command restricts the file to read-only access to the owner and Docker group
chmod 440

Once the above permissions are set, users will only be able to read the “.env” file if they are part of the Docker group or directly by root. Modifying the “.env” file will be possible via sudo or directly by root. These permissions will limit the number of users with access to the “.env” file and minimize the risk of unauthorized access. 

In v32 and later, to keep your system-level credentials secure, you can integrate with a Secrets Manager. To learn more about our integration with Secrets Managers, see Secrets Management.

Downtime and reduced capacity

Note that your system will have downtime each time you edit the “.env” file. Downtime begins when the last “docker rm -f $(docker ps -q)” command completes and ends when “bash run.sh” is finished running on one machine.

To minimize downtime, run:

No additional downtime will occur if you run “bash run.sh init” on more than one machine.

After the downtime, your system will have reduced capacity until “bash run.sh” has finished running on all of the machines in your cluster.

Because of this downtime and reduced capacity, we suggest that you plan your “.env” updates to be completed either during your system’s scheduled maintenance window or another time when you anticipate reduced usage. In particular, if you choose to pre-upload the “.env” file to your machines before updating your application, ensure that you do so shortly before your scheduled update time to prevent accidental changes and unanticipated downtime.