Your own bucket

By default Verity keeps redacted session transcripts in its own storage. On the Team plan, an organization can keep them in its own S3-compatible bucket instead: AWS S3, Cloudflare R2, Tigris, MinIO, or any other store that speaks the S3 API.

What changes, and what doesn't

  • Changes: where transcripts are kept. Verity writes and reads them with an access key you create and can revoke at any time, and your bucket's lifecycle rule decides how long they stay.
  • Doesn't change: uploads still go through Verity, which redacts each session a second time before storing it. Analysis still runs on Verity's servers, and reports, which quote short redacted excerpts, stay with Verity under the org's report retention.

Switching applies to new sessions. Transcripts already stored stay where they were written, and a session in progress keeps its store until it ends. Verity never copies transcripts between stores.

Set it up

  1. Create a bucket in your provider. Block public access. Keep versioning off, or expire old versions after a day, so a deleted transcript is really gone.
  2. Add a lifecycle rule that deletes objects after the number of days you want to keep transcripts. We suggest 180. Verity never deletes from your bucket, even when the App is uninstalled.
  3. Create an access key limited to that bucket, and to a prefix (a folder) if you want one, as shown for your provider below. Verity needs to read, write, list and delete objects there, nothing else.
  4. Enter the details in your organization's Settings, under Session storage: the endpoint, region, bucket, prefix and the key. Only the org's GitHub owners can see this section. The secret is stored encrypted and never shown again.
  5. Verify. Verity writes a small test object under the prefix, reads it back, lists it and deletes it, and shows the result of each step.
  6. Use this bucket. New sessions go to your bucket from then on.

The endpoint must use https and be reachable from the internet. Verity refuses an endpoint that resolves to a private or internal address.

AWS S3

  • Endpoint: https://s3.<region>.amazonaws.com, for example https://s3.us-east-1.amazonaws.com. Region: the bucket's region.
  • Key: an IAM user with only this policy, then an access key for it. Replace BUCKET and PREFIX (use verity/, or leave PREFIX out for the whole bucket):
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"], "Resource": "arn:aws:s3:::BUCKET/PREFIX*" },
    { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::BUCKET", "Condition": { "StringLike": { "s3:prefix": "PREFIX*" } } }
  ]
}

If the bucket uses a KMS key for default encryption, also allow kms:Encrypt, kms:Decrypt and kms:GenerateDataKey on that key.

Cloudflare R2

  • Endpoint: https://<account id>.r2.cloudflarestorage.com. Region: auto.
  • Key: an R2 API token with Object Read & Write permission, applied to this bucket only. R2 tokens cover a whole bucket, so give Verity a bucket of its own.

Tigris

  • Endpoint: https://t3.storage.dev. Region: auto.
  • Key: an access key with the Editor role on this bucket only.

MinIO and other S3-compatible stores

  • Endpoint: your server's public https URL. Region: the one your server is configured with, often us-east-1.
  • Key: a user or service account with a policy like the AWS one above, limited to the bucket and prefix.

Revoke access

Delete or disable the key in your provider. Verity can no longer read or write the bucket from that moment. To stop using the bucket without revoking, choose Back to Verity's storage in Settings: new sessions go to Verity's storage again.

Uninstalling the Verity App deletes the stored key at once. Nothing in your bucket is deleted.

When the bucket can't be reached

If the key is revoked, the bucket is deleted, or the endpoint is down:

  • Uploads wait. Capture keeps each session on the developer's machine and retries it. It logs one line per session in its log file.
  • Pull requests are reviewed without their sessions. The report says Session storage unavailable. Org rules still run: rules about files apply as usual, and a rule that needs the session is reported as a warning, so it doesn't block the merge on a storage problem.
  • Settings and Home show the error by its name, such as AccessDenied or NoSuchBucket, and when it started.

Fix the key or bucket, then Verify in Settings. A passing Verify reviews the affected open pull requests again, and waiting uploads go through on their next retry.

Delete what Verity already holds

After switching, the transcripts already in Verity's storage expire under the org's transcript retention. An owner can delete them at once with Delete hosted transcripts now in Settings. Their pull requests can't be re-analysed afterwards. Their reports stay until they expire.