Streaming · Automotive

TISAX-compliant livestreaming.
Inside your compliance zone.

Sub-1-second, up to UHD. On TISAX-assessed infrastructure in Frankfurt or on your own hardware.

ENX labelTISAX-assessed infrastructure

Two paths

Your cloud or your building.

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.
See Streaming Classic →

Path 2 · Maximum control

On-premises on your hardware

  • Server in your building, inside your TISAX scope.
  • Installed and managed by dfine.io.
  • The signal never leaves your network.
See On-Premises →

The pipeline

From set to sign-off in one pipeline.

02 · PRIVATE PROCESSING

Shared or dedicated

TISAX-assessed on Google, or on your hardware.

Security architecture

Before your security team asks.

How the shared TISAX instance is built. On-premises, most of this does not apply.

Does the streaming server store video data?

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 do customers share on the instance, and what not?

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.

How does each stream stay with its customer?

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.

And the path in between, is transport secured?

Encrypted end to end: RTMPS on ingest, WebRTC on playout. The infrastructure automatically detects repeated failed attempts against stream authentication and blocks the source.

The instance runs on Google Cloud, doesn't the US CLOUD Act apply?

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.

Which sub-processors are involved?

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.

Is the operation actively monitored?

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.

How are security updates applied?

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.

How long is metadata retained?

Session metadata (times, duration) is deleted automatically after 12 months by a monthly pruning job. Video content is never stored in the first place.

Can the instance's memory be encrypted?

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.

Let's talk about your setup.

We reply personally and tell you honestly whether we can help.