Infrastructure & Dependency Management Policy

Purpose

This policy describes how Close-Rate manages its cloud infrastructure, application dependencies, deployments, and operational monitoring. We use fully managed AWS services to reduce operational overhead and rely on established open-source libraries with active maintenance.

Infrastructure Overview

All Close-Rate services run on Amazon Web Services (AWS) in the US-East-1 (Virginia) region:

• Compute: AWS ECS on Fargate — fully managed container hosting with automatic scaling, health checks, and zero-downtime deployments behind an Application Load Balancer

• Frontend Hosting: AWS Amplify — managed static hosting with CloudFront CDN, automatic SSL, and continuous deployment from Git

• Database: Amazon RDS Aurora PostgreSQL — managed relational database with automated backups, encryption at rest, and Multi-AZ failover capability. VPC-only and not publicly accessible; inbound restricted to the ECS task security groups

• Search: Transcript search indexes (text chunks and embeddings) are stored in the Amazon RDS Aurora PostgreSQL database above, using the pgvector extension — not a separate search service. They share the database's encryption at rest and private, VPC-only network access

• Object Storage: Amazon S3 — for call transcripts, embedding objects, and static assets, with server-side encryption (SSE-S3, AES-256). Raw audio is never persisted to S3 (it is streamed to an ephemeral temp file for transcription only and deleted immediately after); PDFs are generated on demand and not persisted. Customer data is private with no public access — a single dedicated public/ prefix hosts one non-sensitive marketing video used on the website

• DNS: Domain managed via Network Solutions with CNAME records pointing to AWS CloudFront

Dependency Management

Backend (Python)

• Python 3.11 LTS runtime

• Dependencies pinned in requirements.txt with specific versions

• Key dependencies: FastAPI, SQLAlchemy 2.0, httpx, PyJWT, boto3, pydantic, cryptography, reportlab

• GitHub Actions CI runs on every push: ruff (lint), pytest (unit + integration), and pip-audit (dependency advisories). Audit results are reviewed each build and fixable high/critical advisories are remediated

• Dependency updates reviewed monthly; security patches applied immediately

Frontend (JavaScript/TypeScript)

• React 19 with TypeScript 4.9 (react-scripts 5.0.1 / Create React App)

• Dependencies managed via npm with package-lock.json for deterministic builds

• Key dependencies: Material-UI (MUI v5), Clerk React SDK, Axios, PostHog

• GitHub Actions CI runs on every push: tsc --noEmit, Jest tests, npm audit, and a production build with ESLint warnings treated as errors. Audit results are reviewed each build and fixable high/critical advisories are remediated; the build is not failed on every high/critical advisory (the remaining frontend high/critical advisories are build-time-only transitives of Create React App that are not in the shipped bundle, tracked for a CRA→Vite migration)

Third-Party Services

• Anthropic (Claude Opus): Primary analysis/reasoning model for coaching-report generation and AI Insights chat; receives conversation transcript text. Anthropic's commercial terms say it may not train models on customer content sent through its services

• OpenAI: Text embeddings (text-embedding-3-large), participant extraction, fallback evidence ranking and auxiliary text processing; receives transcript text. OpenAI says data sent to its API is not used to train its models unless the customer opts in to share it (SOC 2 Type II)

• AssemblyAI: Audio transcription only; receives call audio and returns the transcript (SOC 2 Type 2). Since October 15, 2026, our account has been opted out of AssemblyAI's model improvement program, which AssemblyAI says means it does not use the call audio we send it to train its models or for benchmarking. The account is set so that AssemblyAI begins deleting each call's audio and transcript one day after the request; it keeps certain metadata for logging and billing, and its terms let it keep de-identified data made from the audio for purposes other than training its models

• TypeSafe: Ranks authorized transcript excerpts against coaching questions; receives question text and bounded excerpts. TypeSafe's privacy policy says it does not train or fine-tune models on the input customers send it

• Clerk.dev: Authentication and user management (SOC 2 Type II)

• Zoom: Read-only OAuth integration for cloud meeting recording and Zoom Phone call recording import (SOC 2, ISO 27001)

• PostHog: Product analytics and session replay: page views, clicks and scrolls. On signed-in screens, text and typed input are masked, so conversation content, report text and rep or customer names are not captured. Signed-in activity is linked to the user's account

Change Management

• All code changes are tracked in version control (Git)

• Infrastructure changes are deployed through managed service consoles (AWS Amplify, ECS) with automatic rollback on health check failure

• Database schema changes are managed through Alembic migrations, which auto-run as a one-shot in-VPC ECS task before the new tasks serve traffic

• Environment variables (secrets, API keys) are managed through AWS Secrets Manager and ECS task definitions, separate from source code

• Frontend deployments are built and released through AWS Amplify

• Backend deployments are triggered via GitHub Actions, which builds a Docker image, pushes to Amazon ECR, and rolls the ECS service with zero-downtime rolling updates gated by ALB health checks and a deployment circuit breaker that auto-rolls-back to the previous task definition on failure

Build & Deployment Pipeline

• Frontend: Git push → AWS Amplify build → npm install → TypeScript compile → static asset deployment to CloudFront CDN

• Backend: Git push → GitHub Actions workflow (ruff, pytest, pip-audit) → Docker build → push to Amazon ECR → Alembic migration (one-shot in-VPC ECS task) → ECS task definition update → ALB health check → traffic shift, with a deployment circuit breaker that auto-rolls-back on failure

• Build failures prevent deployment — no broken code reaches production

• Health checks run continuously; unhealthy instances are automatically replaced

Monitoring & Alerting

• Application Logs: Structured Python logging output to AWS CloudWatch Logs with 90-day retention; no secrets or PII in logs

• Error Tracking: Application errors logged with full context (request path, user context, stack trace) — no sensitive data included

• Health Checks: The ECS service and its Application Load Balancer perform automatic health checks; failing tasks are replaced automatically

• Database Monitoring: RDS CloudWatch metrics for CPU, memory, connections, and storage

• Uptime: CloudFront, the Application Load Balancer, and ECS provide built-in availability monitoring

Scaling & Availability

• AWS ECS service auto-scaling adjusts task count based on request volume (1-25 tasks)

• CloudFront CDN provides global edge caching for frontend assets

• RDS Aurora supports read replicas and Multi-AZ deployment for high availability

• S3 provides 99.99% availability and 99.999999999% durability