Security & Compliance

Talkr is self-hosted: you run the full stack (API, UI, Postgres, Redis, MinIO) on your own infrastructure. That's the foundation of the security model — your call recordings, transcripts, and credentials live in a deployment you control, not in a shared multi-tenant SaaS database. Everything below describes what Talkr's code does on top of that foundation.

Encryption

In transit. All external traffic is served over HTTPS, with plain HTTP requests redirected (301) to HTTPS. TLS 1.2/1.3 only. Strict-Transport-Security, X-Content-Type-Options, and X-Frame-Options headers are set at the nginx layer.

Credentials, at the application layer. Sensitive columns are encrypted before they reach the database, not just access-controlled:

• BYOK LLM/STT/TTS provider keys, and other org configuration values, are encrypted with Fernet (symmetric AES) before storage.
• Connector credentials (API keys, OAuth tokens, bearer tokens) are encrypted the same way.
• Telephony provider credentials (Twilio/Vonage/Plivo/Telnyx/etc.) are field-level encrypted — only the non-secret account identifier used for inbound-call routing lookups is stored in plaintext.
• Passwords are hashed with bcrypt (not reversible). Talkr API keys are stored as SHA-256 hashes only — the plaintext key is shown once, at creation, and never again.

At rest, below the application layer. Talkr's code does not configure disk-level or volume-level encryption for Postgres, Redis, or MinIO — that depends entirely on your infrastructure provider's defaults (e.g. your cloud provider's block-storage encryption). We don't make a blanket "data is encrypted at rest" claim beyond the application-layer credential encryption described above; verify your own disk-level encryption settings if that matters for your compliance requirements.

Access control

Role-based permissions (owner / admin / member, plus a separate platform-superuser tier) are enforced server-side on every request, not just hidden in the UI — permission checks happen in a shared FastAPI dependency, backed by a real permissions table, and are covered by tests. Suspended users and deactivated or deleted organizations are rejected at the same auth boundary, on every request path (including WebSocket connections).

Organizations can optionally restrict access to an IP allowlist, enforced the same way, across every authentication method (API key, session, SSO).

Audit logging

Administrative actions are written to a durable, queryable audit log: credential and OAuth changes, connector connections, organization updates (including suspensions and deletions), invites, superuser-status changes, impersonation, feature-flag changes, IP-allowlist changes, and SSO approvals, among others. It's viewable in the SuperAdmin portal, filterable by organization, actor, action, and date range.

This is a standard database table, not a cryptographically tamper-evident or write-once log — someone with direct database access could alter it. There's currently no automatic retention/purge policy, which in practice means audit history accumulates rather than silently expiring.

Data residency and third-party processing

Because Talkr is self-hosted, your Postgres database and MinIO-stored recordings never leave your deployment's infrastructure — there's no multi-region replication or Talkr-operated control plane in the loop. Two things do leave your infrastructure if you enable them:

• LLM/STT/TTS providers you configure (BYOK) process call audio/text by design — that's inherent to using a third-party model provider, not specific to Talkr.
• Langfuse tracing, if you set it up for LLM observability, sends prompts and completions to Langfuse's cloud. It's off by default and opt-in.

If data residency is a hard requirement, keep both of the above in mind when choosing providers and deciding whether to enable tracing.

Data deletion and export

There is no self-service "delete my account" or "export my data" flow today. A platform superuser can soft-delete an organization (it drops out of the default listing), but this deliberately does not purge underlying records — call history, billing, and audit data are preserved rather than cascaded away, since every table's foreign key would otherwise destroy that history on a real delete.

If you need specific data deleted or exported, contact us and we'll process the request manually. This matches what our privacy policy already states — we're not going to promise self-service tooling that doesn't exist yet.

Network isolation

In Talkr's own production deployment, Postgres, Redis, and MinIO are bound to the internal Docker network only — nothing but the reverse proxy and the WebRTC media relay (which can't be proxied) is reachable from the public internet.

The generic self-host docker-compose.yaml documented for customer deployments follows the same pattern: Postgres and Redis bind to 127.0.0.1 only, not the public interface. The API and UI ports are intentionally published (they need to be reachable, whether directly or via your own reverse proxy) — harden or firewall them at the host level to match your network's threat model.

Backups

Nightly backups (Postgres dump + MinIO recordings) are pushed off-box to Backblaze B2, independent of the VPS itself. Local copies are retained for 3 days as a fast-restore cache; the B2 copy is the durable one. A failed backup run triggers an email alert.

We periodically verify the restore path is real, not just documented: restoring a live nightly backup into a scratch database and confirming the data matches. We recommend re-running that check after any schema migration, and we do the same before recommending it to you.

Summary

Questions about any of this, or a specific compliance requirement you need to evaluate against? Reach out to your Talkr contact directly.