Deployment Instructions

testgrinder service will be discontinued on January 31, 2025

testgrinder SMPC was discontinued as of February 1, 2024

These pages will guide you through the deployment of testgrinder to your private Amazon Web Services (AWS) Cloud. This guide assumes that you are familiar with AWS and Ubuntu linux.

How to Get Assistance

If you need assistance with testgrinder deployment, let us know by emailing support@testgrinder.com . Alternatively, you can start a conversation with us via Intercom from the testgrinder Contact page

Deployment Scenarios

The simplest deployment of testgrinder will have the following limitations:

  • Limitation: a tg-app server allows insecure communication on HTTP, and for requests on HTTPS it gives a security warning

    • the security warning is due to tg-app servers using a preinstalled self signed SSL certificate

    • to remove the security warning you will need to provide and install a valid SSL certificate as described in Install SSL Certificate

    • once the SSL certificate is installed, it is advisable to force the tg-app server to redirect all HTTP requests to HTTPS by changing the FORCE_SSL parameter in .env Conifguration File to true.

    • follow Install SSL Certificate and Force HTTP to HTTPS to resolve this limitation

  • Limitation: tg-app server hosts the database

    • tg-app servers come with preinstalled MongoDB database, which is good for evaluating testgrinder, but not advisable for production use

    • to host the database externally, see External Database

    • if you are planning to manage tg-app servers with an Auto Scaling Group (advisable for production) you will have to switch to an external database

    • follow External Database to resolve this limitation

  • Limitation: sole tg-app server offers low fault tolerance and may not keep up with large runs (200+ parallel scenario execution sessions)

    • to automate management of tg-app servers based on load, to automatically refresh them on failures, and to simplify tg-app upgrade process, it is advisable to manage tg-app servers with help of an Auto Scaling Group, which is described in Configure Auto Scaling Group

    • managing tg-app servers with an Auto Scaling Group requires that you have already switched to an External Database

    • follow Configure Auto Scaling Group to resolve this limitation

Deploying testgrinder with the above limitations in place is a good start if you want to get to evaluating testgrinder quickly. For production use, we recommend eliminating all limitations listed above.

Until you install SSL certificate and force HTTP to HTTPS, testgrinder will allow HTTP requests, which are insecure. Using testgrinder with HTTP is inadvisable if it is exposed to the internet and not recommended on private networks.

Until you switch to an external database, the database will be located on the tg-app server. Make sure not to terminate the tg-app instance (for example when upgrading) prior to taking a backup of the database (see Backup and Restore Database) and moving the backup to a safe location.

Until you switch to an Auto Scaling Group for managing tg-app server, you will need to periodically monitor the health of the tg-app server manually. With the Auto Scaling Group deployed, it will automatically refresh failed tg-app servers.

Last updated