File Storage (BYO) - TATER Help

By default, every file attachment in TATER — on Ops tickets, emailed-in messages, RFI (Request for Information) responses, and audit evidence — is stored in TATER's managed Azure Blob storage. With Bring Your Own (BYO) storage you can instead point those attachments at a storage account your organization owns and pays for. TATER's size and file-type limits still apply; the data simply lives in your account, under your retention, encryption, and access policies.

Where: TATER Manage → Connections → File Storage (OrgAdmin). The setting is per-organization.

Why use it

Data residency & ownership — attachments stay in your tenant's storage account, in the region you choose.
Your retention & lifecycle — apply your own immutability, soft-delete, lifecycle-tiering, and legal-hold policies.
Your encryption — use customer-managed keys (CMK) on the storage account if you require it.
Your audit trail — storage-account diagnostic logs capture every read/write/delete.

How it works

You enable BYO storage and paste an Azure Storage connection string (plus an optional container name) in Manage.
TATER validates it, encrypts it at rest, and never shows it to the browser again (it is redacted to [REDACTED] on every read).
From that point on, new attachment uploads land in your container. TATER records, per attachment, which account it lives in.
Download links are short-lived (≈1 hour), read-only SAS URLs generated from your account key — TATER never proxies the file bytes.
Existing attachments stay exactly where they were uploaded (TATER managed storage). Only new uploads move. Both keep working.

TATER limits still apply

BYO storage changes where files are stored, never whether TATER's guardrails apply. Regardless of backend:

Per-file cap: 25 MB.
Per-ticket aggregate cap: 100 MB.
Per-email cap: 50 MB.
Executable / script / installer extensions (.exe .ps1 .bat .msi .js …) are blocked.
Video files are blocked by default.

Prerequisites

An Azure Storage account (StorageV2 / general-purpose v2 recommended) in your subscription.
An account-key connection string. The account key is required so TATER can mint secure, time-limited download links (SAS). SAS-token-only or managed-identity connections are not supported in this release.
A user with OrgAdmin role in TATER.

Step 1 — Get the connection string

In the Azure portal: Storage account → Security + networking → Access keys → Show keys → key1 → Connection string → Copy. It looks like:

DefaultEndpointsProtocol=https;AccountName=mycompanystorage;AccountKey=base64key==;EndpointSuffix=core.windows.net

Or with the Azure CLI:

az storage account show-connection-string \
  --name mycompanystorage \
  --resource-group my-rg \
  --query connectionString -o tsv

Sovereign clouds are supported via their endpoint suffix: core.usgovcloudapi.net (US Gov), core.chinacloudapi.cn (China). Any other suffix is rejected.

Step 2 — Configure in Manage

Open TATER Manage → Connections → File Storage.
Paste the connection string into Connection string.
(Optional) Set a Container name — defaults to tater-attachments. Use 3–63 lowercase letters, numbers, and single hyphens. TATER creates the container if it does not exist.
Click ⚿ Test connection — TATER ensures the container, writes + reads + deletes a tiny probe blob, and reports the account + container on success.
Tick Use my storage account and click Save.

To temporarily fall back to TATER managed storage without losing your config, untick Use my storage account and Save. The connection string stays stored (and redacted); new uploads go to TATER managed storage until you re-enable.

Rotating or removing the connection

Rotate the key: paste a fresh connection string and Save. Leaving the field blank keeps the stored value (it shows as [REDACTED]).
Remove BYO: untick Use my storage account. New uploads revert to TATER managed storage.

Heads-up: files already uploaded to your account are owned by you. If you remove the connection string entirely, TATER can no longer generate download links for those files — they remain in your storage account, fully under your control, and become reachable again if you restore the connection. For the same reason, don't rename the container while it holds attachments.

Security

The connection string is encrypted at rest (AES-256-GCM) and never returned to the browser — admins see [REDACTED], not the value.
Connection strings are validated before saving: a valid Azure account name, an account key, an allowlisted Azure endpoint suffix, and HTTPS — which prevents pointing the storage client at an arbitrary host.
Download URLs are read-only, single-blob, ~1-hour SAS links. TATER never lists your container and never exposes the account key.
Only an OrgAdmin can view or change the setting, and every change is written to the TATER activity log.

FAQ

Do I have to migrate existing attachments? No. Existing files keep working from wherever they were stored. Only new uploads use the new account.

Can I use a managed identity or SAS-only connection? Not in this release — an account-key connection string is required so TATER can mint download links.

What containers/paths does TATER use? One container (default tater-attachments); blobs are laid out as {organizationId}/{ticketOrItemId}/{id}-{filename}.

Does this affect audit evidence? Yes — audit-evidence files follow the same setting, so engagement evidence also lands in your storage when BYO is enabled.