> ## 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.

# Security

> Security policies and controls for Jinba Flow

## 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
* ID/password authentication temporarily locks an account after repeated failed attempts, mitigating brute-force and credential-stuffing attacks (locks are released automatically over time)
* Logs are retained for at least six months
* Vulnerability assessments are performed at least once per year
* The SOC 2 Type 2 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:

<img src="https://mintcdn.com/jinba/B0KuFPdq9oF6s05P/en/images/system-architecture.png?fit=max&auto=format&n=B0KuFPdq9oF6s05P&q=85&s=a76f4eaf8b534536f296f93e1217724e" alt="System architecture diagram" width="1291" height="570" data-path="en/images/system-architecture.png" />

> **Note**: This diagram shows the AWS configuration as a representative example; equivalent GCP and Azure deployments follow the same pattern. Updated August 2025.