Standard recommendations

We recommend certain best practices when it comes to running Tines in self hosted.

Instance Specifications 

AWS 

If you are running in AWS, please follow the below recommendations for instance specifications. You can adjust up or down as necessary by monitoring your usage in RDS performance insights or other tools.

AWS RDS/Aurora 

For AWS RDS we recommend that you use memory-optimized RDS instances (e.g., r8g.large).

AWS Elasticache 

For your Redis instance type, we recommend using a Graviton-powered instance (e.g., c7gn.large).

Docker Compose 

Recommended specifications are mentioned here.

Data backup 

See data backup recommendations for more information.

High availability 

We recommend that you always run Tines with additional replicas where applicable, distributed between at least two different Availability Zones.

AWS 

AWS Aurora Postgres 

We recommend that you run AWS Aurora Postgres with multi-az turned on. To do so with AWS Aurora, you just need to add an additional read. You can follow the instructions on your docs here and learn more from AWS here.

You can make use of the database reader endpoint to direct read-only traffic to the replicas of your cluster to distribute queries across the cluster.

AWS Elasticache Redis 

We recommend that you turn on multi-az for AWS Elasticache. You can follow the instructions on the same here.

Redis cluster mode is not supported.

AWS ECS Fargate 

We recommend that you run at least two tasks for each service (tines-app, and tines-sidekiq) in different availability zones (you will need to set up security groups across AZs as outlined here). These can be scaled up as necessary, to 5-8 for tines-app, and 10-12 for tines-sidekiq, depending on usage.

Non AWS setups 

For non AWS setups our recommendations are similar to AWS setups. For example:

  • We recommend that you always run at least two or more copies of containers per Tines services (tines-app and tines-sidekiq) in different availability zones.

  • Where possible please ensure that your data storage can be spread across at least two availability zones or similar setup. Backups should be performed at least daily with a retention period of 30 days.

Monitoring 

AWS 

If you are running on AWS we recommend setting up Cloudwatch alarms for the following metrics

  • AWS Aurora

    • Alert when CPUUtilization is above 80% utilization. Reference here.

    • Alert when FreeableMemory is below 80% utilization of the total memory. Reference here.

  • AWS Elasticache

    • Alert when DatabaseMemoryUsagePercentage is above 80%. Reference here.

    • Alert when EngineCPUUtilization is above 80%. Reference here.

  • AWS ALB

    • Alert when UnHealthyHostCount is above 50% of the desired host count for over 2 mins. For example: If you have set desired task count for tines-app to be 2, then your set the threshold for UnHealthyHostCount to be 1. Reference here.

    • Alert when HTTPCode_ELB_502_Count is above 5 requests. This metric indicates that your load balancer cannot successfully route requests to its backends and you traffic has been dropped. Reference here.

      • If you see frequent occurrences of this alert then increase your desired tasks count.

  • AWS ECS Fargate

    • Alert when CPUUtilization is consistently (5 minutes or more) above 80%. Note: this could also be a sign that you may need to increase the number of tasks on the service. In other words, scale horizontally. Reference here.

If you find that the alert is frequent and any of the metrics are consistently above the mentioned thresholds then its best to scale up the instance type. For example: If you are on db.r7g.large , you should upgrade the Aurora cluster to db.r7g.xlarge.

Non-AWS setup 

For now AWS setups our recommendations are similar to AWS setups. For example

  • You should setup monitoring for your storage system if it is occupying more than 80% of total storage.

  • You should setup monitoring if the CPU utilization of your compute systems is consistently above 80%.

Encryption 

We recommend that you turn on encryption at rest Record #144287679 and transit for your database through your setup and/or service provider as applicable. In addition, we also recommend that you take advantage of field level encryption which is an opt-in Tines feature. You can learn more more about that here.

Connectivity 

Tines does not require network connectivity to function. However, there are optional features that do perform outbound requests. These are:

  • Telemetry operations, which connects to hq.tines.io:443. Read more at Record #143675075.

  • Importing stories from the story library, which connects to story-library-data-2025-03.tines.com:443.

  • Using action templates, which connects to integrations.tines.com:443. Read more at Record #144287679.

Was this helpful?