Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.jinba.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

  • Physical and operational security of our data centers follows AWS/GCP standards
  • Network communications use TLS encryption with IDS/IPS, firewalls, and traffic distribution to mitigate DoS attacks
  • Virtualization is used to isolate data between users
  • Service access is protected with ID/password authentication
  • Logs are retained for at least six months
  • Vulnerability assessments are performed at least once per year
  • The SOC 2 Type 1 audit has been completed

​
System Architecture

Jinba Flow and Jinba App are deployed on a public cloud (AWS in the example below; GCP and Azure are also supported) as separate, but structurally similar, environments. Both products follow the same security pattern:
  • Public traffic terminates at an Application Load Balancer (ALB) with TLS, behind which application containers run on ECS. For Jinba Flow the API and Web tier run as separate containers; Jinba App ships them as a single combined container.
  • Container images are pulled from a private ECR registry. Application secrets (API keys, OAuth tokens, signing keys) are not baked into images — they are fetched at runtime from AWS Secrets Manager.
  • Persistent state is stored in Amazon RDS (relational data) and Amazon S3 (file storage). Both are private to the VPC and accessed only by the application tier.
  • Asynchronous and scheduled work (flow runs triggered by webhooks, crons, etc.) is dispatched via a Qstash background-job queue that calls back into the ALB.
  • Audit and operational logs from every container are written to CloudWatch for retention, alerting, and incident review.
The AWS topology shown here is one example. The same architecture pattern is supported on Google Cloud (GCP) and Microsoft Azure using equivalent managed services — for example, Cloud Run / GKE or Container Apps / AKS in place of ECS, Artifact Registry or Azure Container Registry in place of ECR, Cloud SQL or Azure Database for PostgreSQL in place of RDS, Google Cloud Storage or Azure Blob Storage in place of S3, Secret Manager or Azure Key Vault in place of AWS Secrets Manager, and Cloud Logging or Azure Monitor in place of CloudWatch. Security boundaries (private network, runtime-only secrets, application-tier-only data access) are preserved across all three clouds. The diagram below shows both topologies side by side: System architecture diagram
Note: This diagram shows the AWS configuration as a representative example; equivalent GCP and Azure deployments follow the same pattern. Updated August 2025.