Hosted gate: what is no longer end-to-end encrypted
The trust model of the hosted gate, plainly: what is no longer end-to-end encrypted, what protects and how far, how to check it, and the text of the agreement.
On this page
Help sections
With a gate on your side, your databases stay end-to-end encrypted: encryption guarantees it. With the hosted gate, the databases you entrust to it no longer are while they stay entrusted, and this article says exactly what changes.
What is no longer end-to-end encrypted
For the entrusted databases only, and while they stay entrusted:
| what | decrypted by | why |
|---|---|---|
| every row and every column, shown by a view or not | the hosted service | it manages the key of the entrusted databases and serves the API from its copy |
| what is written to them meanwhile (by you, the members, the API) | the hosted service | the current key is sealed for it while the database stays entrusted |
| your software's requests and the answers | the hosted service | it serves the API |
| the same requests and answers, in transit | Filarr's Cloudflare account that manages filarr.com and also serves Filarr's API | the gate's address is a filarr.com name: that account ends the encrypted connection |
| the key of an external database connected to the gate, and its rows | the hosted service | the scheduled sync runs with that key |
| the files received by the gate, in passing | the hosted service | it encrypts them for your drop box after receiving them |
What is not affected:
- your other databases, your notes, your files, your vaults;
- your vault's key: a database's key is derived from it one way, there is no going back from it;
- what is written after you take the key back: the database moves to a new key generation, never sealed for the service, and is end-to-end encrypted again;
- the folder where received files are filed: only your device files them.
What protects, and how far
| strength | protection | its limit |
|---|---|---|
| encryption | a single database is entrusted, not the account | the entrusted key opens one database, at one generation |
| encryption | taking the key back cuts off the future | what the service processed before stays covered by the commitments alone |
| encryption | the token is never in clear in the API's database | your device seals it for a service key built into the apps; this does not cover traffic in transit, nor the service itself, which holds its private key |
| none | a hosted gate's traffic, in transit | it is not end-to-end encrypted: the account that manages filarr.com decrypts it; the agreement says so |
| verifiable | the code the service announces is the published version's | what is checked is what the service announces; the platform offers no remote attestation that would prove the running code is that one |
| verifiable | everything is traced | agreements, service versions, sleep, takeover and erasure receipts in the access's journal |
| verifiable | it shows | the mark on every surface, for everyone who sees the database |
| commitment | isolation, no logging of content, European Union, no other use | these are commitments, not protection by encryption: Cloudflare hosts the service's machines; a request enters through the point of presence closest to the caller, which can be outside the European Union (only the copies stay there); the code and the configuration are deployed from Filarr's Cloudflare account, within the framework described below |
| commitment | erasure | the receipt proves the service carried out the order, not that no copy exists elsewhere |
Isolation, as it is
The service runs in the same Cloudflare account as Filarr's API, as a separate program, with its own secrets and its own storage. The API's code has no access to them: a flaw in the API gives neither the service's keys, nor the copies, nor the tokens.
This isolation separates the service from the API; it does not apply to deployment itself, which is done from that account. That the running code is the published one therefore rests on a framework, not on a technical barrier:
- deployment only through the integration pipeline, from a signed version of the public
filarr-gaterepository; - a public log of deployments: version, code fingerprint, publication date, deployment date;
- seven days between a version's publication and its deployment, so anyone can review it and rebuild its fingerprint;
- a single exception, the security fix: a flaw that puts at stake the confidentiality of entrusted databases, of their keys, of the tokens or of the isolation, described in a security advisory of the public repository. The log publishes it at that very moment, with the advisory, and the flaw's details follow within 30 days;
- an internal security review, done; an external security review, planned; and Filarr's commitment.
The public log is the journal.jsonl file on the release-journal branch of the filarr-work/filarr-gate repository, and the trust page describes it. As of October 27, 2026, the version in service is Filarr Gate 0.3.1; 0.3.2 is published, and its deployment is planned from November 3, once its seven days have passed.
Where the copies are, and what is logged
- Each gate's copies and execution are in the European Union. The connection itself is received by the point of presence closest to the caller.
- No logging of content: no request, no answer, no row, no file name, no webhook address. Only the number of calls per hour, error codes and durations are measured. The network's automatic protections that could keep a request address are turned off for those addresses, and a daily check verifies it.
- For entrusted databases, Filarr acts as a processor of your data: the hosted box DPA annex frames it, with the offer's terms (Terms, § 3a).
Check the service's version
Settings → API access shows, for each hosted gate, the Filarr Gate version in service and its code fingerprint. Compare them with that version's line in the public deployment log. Each new deployment is also written in the access's journal.
The text of the agreement
Here is the text you accept when entrusting databases (version hebergement-v1). Its version and its fingerprint are shown under the agreement. If it changes, it takes a new version; an entrusted database that stays without an agreement on the current text is withdrawn from the gate 30 days later, with a receipt.
Entrust these databases to the black box hosted by Filarr?
Today, these databases are end-to-end encrypted: only your devices have their key.
If you entrust them to the black box "[name of the box]", hosted by Filarr:
the key of each checked database will be managed by an isolated Filarr service, which decrypts it to answer your software;
while they remain entrusted, these databases are therefore no longer end-to-end encrypted: their rows and columns, including those no view shows, and everything written to them, are decrypted by our servers;
your software's calls and the responses are not end-to-end encrypted either: they go through a filarr.com address, managed by the same account as Filarr's API;
if you connect an external database to it, its key will also be managed by our servers; files the box receives also pass through our servers without end-to-end encryption;
your other databases, your notes, your files and your vaults are not affected.
Filarr commits to not logging this content, to using it only to serve your API, to keeping its copies in the European Union and to erasing the key and the copy when you take it back. These are Filarr's commitments, not protection by end-to-end encryption.
You can take the key back at any time. The keys of these databases then change, and anything written afterwards is end-to-end encrypted again. What the box processed before remains covered by the commitments above.
I understand that the checked databases will no longer be end-to-end encrypted while they are entrusted to Filarr.
Learn more
- The gate hosted by Filarr
- How Filarr protects your data
- The trust page and the hosted box DPA annex, on the website.
- Filarr Gate's security and trust page: github.com/filarr-work/filarr-gate.