Talk to the Team

Tell us about your stack and the privacy problems you're trying to solve. We typically respond within one business day.

Prefer email? support@philterd.ai

Prefer to skip the form? Pick a time on our calendar →
or send a message

Please do not enter PII or PHI in this form. If you need to share an example, use a sanitized one.

This guide describes how Philter’s configuration can be managed when Philter is deployed in an auto-scaling environment.

Updating Philter configuration values

Philter reads its settings from the philter.properties file when Philter starts. This file must reside alongside Philter wherever Philter is deployed. When Philter is deployed in an auto-scaling environment, updating a configuration requires updating the configuration value on all instances of Philter. There are a few approaches that can be taken.

Deployment via a custom machine image

One way to update the configuration values is to use a custom (“pre-baked”) machine image of Philter. When a configuration needs to change, change the configuration value in the machine image and update the auto-scaling environment with the latest machine image. Then begin substituting the currently running Philter instances with new instances from the updated machine image.

Updating configuration using an external file

In this method, a copy of Philter’s philter.properties file is stored on a remote file system, such as Amazon S3. A cron job runs on each deployed Philter instance to periodically download the file, copy it to the appropriate location, and restart the Philter service. This method lets you modify the configuration on all instances with fewer moving parts than the previous option.

The following is an example bash script that uses the AWS CLI to copy the philter.properties file and restart Philter:

#!/bin/bash
aws s3 cp s3://your-bucket/application.properties /opt/philter/application.properties
sudo systemctl restart philter.service
sudo systemctl restart philter-ner.service