Skip to content

Deployment for Production

The following instructions are needed to set up FMTM for production on your own cloud server.

Set up the FMTM on a cloud server

Set up a server and domain name

  • Get a cloud server (tested with Ubuntu 22.04).
  • Set up a domain name, and point the DNS to your cloud server.
  • SSH into your server. Set up a user with sudo called svcfmtm. this is a good guide for basic server setup including creation of a user.

Run the install script

curl -L -o

# Then follow the prompts

Additional Environment Variables

Variables are set in .env. Some can be updated manually, as required.


If extra cors origins are required for testing, the variable EXTRA_CORS_ORIGINS is a set of comma separated strings, e.g.: http://fmtm.localhost:7050,http://some.other.domain


It is also possible to use the API_PREFIX variable if the api is served under, e.g. /api on the domain. However, this isn't the recommended approach, and testing is minimal.


In most circumstances these variables should be provided to authenticate with your S3 provider. However, some providers (such as AWS), allow for instance profiles to be attached to your server, with required permissions preconfigured. By default connections made from the EC2 instance with attached instance profile will be automatically authenticated. S3_ACCESS_KEY and S3_SECRET_KEY should be set to blank strings in this case ="".

ODK_ Variables

These can point to an externally hosted instance of ODK Central.

Or ODK Central can be started as part of the FMTM docker compose stack, and variables should be set accordingly.

Other Domains

If you run FMTM with ODK and Minio (S3) included, then the domains will default to:

${FMTM_DOMAIN} --> Frontend
api.${FMTM_DOMAIN} --> Backend
odk.${FMTM_DOMAIN} --> ODK Central
s3.${FMTM_DOMAIN} --> S3 / Minio

These defaults can be overridden with respective environment variables:


Connecting to a remote database

  • A database may be located on a headless Linux server in the cloud.
  • To access the database via GUI tool such as PGAdmin, it is possible using port tunneling.
ssh username@server.domain -N -f -L {local_port}:localhost:{remote_port}

# Example
ssh -N -f -L 5430:localhost:5433

This will map port 5432 on the remote machine to port 5430 on your local machine.

Backup Process

  • Backup FMTM database:

    backup_filename="fmtm-db-${GIT_BRANCH}-$(date +'%Y-%m-%d').sql.gz"
    echo $backup_filename
    docker exec -i -e PGPASSWORD=PASSWORD_HERE \
    fmtm-${GIT_BRANCH}-fmtm-db-1 \
    pg_dump --verbose --encoding utf8 --format c -U fmtm fmtm \
    | gzip -9 > "$backup_filename"

Note: if you are dumping to import into a pre-existing database, you should also include the --clean flag.

This will drop the existing tables prior to import, and should prevent conflicts.

  • Backup ODK Central database:

    backup_filename="fmtm-odk-db-${GIT_BRANCH}-$(date +'%Y-%m-%d').sql.gz"
    echo $backup_filename
    docker exec -i -e PGPASSWORD=PASSWORD_HERE \
    fmtm-${GIT_BRANCH}-central-db-1 \
    pg_dump --verbose --encoding utf8 --format c -U odk odk | \
    gzip -9 > "$backup_filename"
  • Backup the S3 data:
backup_filename="fmtm-s3-${GIT_BRANCH}-$(date +'%Y-%m-%d').tar.gz"
echo $backup_filename

docker run --rm -i --entrypoint=tar \
-u 0:0 \
-v $PWD:/backups -v \
fmtm-s3-data-${GIT_BRANCH}:/mnt/data \${GIT_BRANCH} \
-cvzf "/backups/$backup_filename" /mnt/data/

Manual Database Restores

The restore should be as easy as:

# On a different machine (else change the container name)

cat "$backup_filename" | gunzip | \
fmtm-${GIT_BRANCH}-fmtm-db-1 \
pg_restore --verbose -U fmtm -d fmtm

# For ODK
cat "$backup_filename" | gunzip | \
fmtm-${GIT_BRANCH}-central-db-1 \
pg_restore --verbose -U odk -d odk

# For S3 (with the backup file in current dir)
docker run --rm -i --entrypoint=tar \
-u 0:0 --working-dir=/ \
-v $backup_filename:/$backup_filename -v \${GIT_BRANCH} \
-xvzf "$backup_filename"

However, in some cases you may have existing data in the database (i.e. if you started the docker compose stack & the API ran the migrations!).

In this case you can import into a fresh db, before attaching to the FMTM containers:

export GIT_BRANCH=development

# Shut down the running database & delete the data
docker compose -f docker-compose.$GIT_BRANCH.yml down -v

# First, ensure you have a suitable .env with database vars
# Start the databases only
docker compose -f docker-compose.$GIT_BRANCH.yml up -d fmtm-db central-db

# (Optional) restore odk central from the backup

cat "$backup_filename" | gunzip | \
docker exec -i \
fmtm-${GIT_BRANCH}-central-db-1 \
pg_restore --verbose -U odk -d odk

# Restore fmtm from the backup

cat "$backup_filename" | gunzip | \
docker exec -i \
fmtm-${GIT_BRANCH}-fmtm-db-1 \
pg_restore --verbose -U fmtm -d fmtm

# Run the entire docker compose stack
docker compose -f docker-compose.$GIT_BRANCH.yml up -d

Last update: July 21, 2024