Path 1 · No hardware of your own
Private cloud on Google
- TISAX-assessed, Frankfurt, shared or dedicated.
- Protected viewer links, optional IP-bound login.
- Ready in days, billed in euros.
Streaming · Automotive
Sub-1-second, up to UHD. On TISAX-assessed infrastructure in Frankfurt or on your own hardware.
Two paths
Path 1 · No hardware of your own
Path 2 · Maximum control
The pipeline
RTMPS-encrypted from set or suite.
Guide: streaming workflows →TISAX-assessed on Google, or on your hardware.
Protected links in the browser, color-accurate via SDI.
Guide: SDI monitoring →Security architecture
How the shared TISAX instance is built. On-premises, most of this does not apply.
No. Streaming here is pure real-time passthrough from ingest to playout. Recording and cloud storage upload are disabled server-side; no video files and no buckets exist on the instance. What remains is metadata such as times and duration, and that lives not on the streaming instance but containerized in our central database on Hetzner in Nuremberg, not publicly reachable and protected by application-level access controls.
What is shared is the compute of a dedicated, TISAX-compliant instance on Google Cloud (europe-west3, Frankfurt), strictly separated from our regular infrastructure on Hetzner in Nuremberg. What is not shared is storage, because video data is never persisted. If you need exclusive compute as well, you get a dedicated-focus engine or run the server on-premises.
Through unique per-customer access tokens that the server re-validates on every connection attempt (round-trip authentication). Playout is protected per stream as well: viewers only get in via access code or confidential login. Metadata is tied to organization-bound records with application-level access controls, and the database port is not publicly reachable. Since no video storage exists, there is structurally no shared storage through which content could travel from one customer to another.
Encrypted end to end: RTMPS on ingest, WebRTC on playout. The infrastructure automatically detects repeated failed attempts against stream authentication and blocks the source.
Yes, Google is a US provider, and we don't hide that. The server itself, however, verifiably sits in Germany: the instance runs in Google Cloud region europe-west3 in Frankfurt, and that location is documented and provable. What matters beyond that is what resides there: no video data, because the instance only passes the signal through in real time and stores nothing. Metadata lives with Hetzner, a German provider, with dfine.io GmbH as your contract partner. If you want to rule out even the passthrough residual risk, run the server on-premises, then the signal never leaves your infrastructure in the first place. The optional conferencing runs on Cloudflare's global network and is not part of the TISAX scope; it stays off until you turn it on per stream.
All processors are publicly documented, with linked data processing agreements (DPA per Art. 28 GDPR), in our Trust & Compliance overview. No hidden chains: what's listed there is the complete list.
Yes, at the operational level, not the content level: what's monitored are technical metrics such as bitrate, runtime and connection status, which is how plan limits are enforced server-side. Nobody looks into the stream itself, the signal is passed through, not watched. Error and audit logs are aggregated EU-side. And if something jams, you reach us directly instead of a ticket loop.
CVE-driven rather than on a fixed calendar: as soon as new vulnerabilities become known for the components in use, we apply the updates. Maintenance windows are always at night so running productions are not disturbed. Certificates renew automatically.
Session metadata (times, duration) is deleted automatically after 12 months by a monthly pruning job. Video content is never stored in the first place.
On dedicated-focus engines, yes: confidential computing encrypts the VM's RAM with a hardware-generated key (AMD SEV/SEV-SNP or Intel TDX) that neither the cloud provider nor the hypervisor nor neighboring VMs can access. It protects against compromised hypervisors and insider access. The overhead is small for compute-bound workloads and noticeably higher for network-heavy streaming workloads, which is why it is not active on the shared variant by default.
We reply personally and tell you honestly whether we can help.