VisitSDK runs beside the account your app already uses. visitsdk-install.sh is the first install. visitsdk-upgrade.sh is every release after that. Neither script deploys your application, and neither accepts a BAA.
Where it runs
Your app account
Web, iOS, or Android
Your backend
The webhook that receives recording events
PrivateLinkSigned webhookRead recordings
VisitSDK account
visitsdk on ECS, behind an internal load balancer
Visit table and the two signing secrets
Recording bucket and your KMS key
The devices talk to Amazon Chime. The VisitSDK server never sees the audio or video. Recordings and transcripts land in the bucket in the VisitSDK account.
You bring
Two AWS accounts. VisitSDK in one, your backend in the other. PrivateLink is the only way in.
A VPC in the backend account, with private subnets in two Availability Zones.
A hostname your backend will call. A public DNS zone validates a new certificate, or you pass a certificate already in the VisitSDK account.
An HTTPS URL on your backend for recording and transcript webhooks, and the IAM role that will read the bucket.
Terraform 1.11 or newer, the AWS CLI, jq, and shasum or sha256sum.
The module creates the VisitSDK VPC, the tasks, the recording bucket, and the KMS key. It does not create your backend's VPC, CloudTrail, or GuardDuty. The image repository is visitsdk. The module names the service, table, bucket, secrets, and queues with the prefix visitsdk- and the environment, for example visitsdk-prod.
First install
<dist-account> is the distribution account from onboarding. Releases are published in us-east-2. Your install can run in another Region. The script copies the visitsdk image into a registry in the VisitSDK account, writes a Terraform root, shows the plan, and waits for you to confirm it. There is no license key, and a running install does not call home.
Pass --certificate-arn instead of --public-zone-id when the VisitSDK account already has a certificate for that hostname. After apply, the script copies the two signing secrets into the backend account. Your tasks read them there. The values are not stored in Terraform state.
Recording and transcript webhooks
VisitSDK sends signed webhooks to your backend in the app account when recordings and transcripts are available. Set --webhook-url to the HTTPS endpoint that receives these notifications.
The payload includes the visit reference, status, and S3 keys. The files stay in the recording bucket in the VisitSDK account; your backend uses the IAM role passed to --recording-role to read them.
Verify each webhook signature with the signing secret copied into the app account after installation, and deduplicate retries. The PHP helper can verify webhook signatures.
A later release
From the same directory, visitsdk-upgrade.sh checks the release, copies the new image, and changes only the version in the module source. --dry-run stops before it changes anything. Without it, the script shows the plan and waits.
A subscription lets the accounts you name copy new server images and the Terraform module. The web, iOS, and Android SDKs, and the PHP helper, stay MIT either way. When a subscription ends, the image you already copied keeps running.