Privacy Policy

Last updated: 3 August 2026. Versión en español.

Fluyo is two different things with two different data behaviours, and this policy treats them separately because conflating them would be misleading:

Who is responsible

Fluyo is an open-source project maintained by itsnect (Claudio Jiménez Flores), based in Chile. It is not an incorporated company, sells nothing, has no customers and processes no payments.

Contact for any privacy matter: nectdnb@gmail.com. Further channels on the support page.

A. The editor at fluyo.space

The editor is a static file site. There is no application server, no database and no API of our own for the browser to call. Everything — drawing, animating, computing layout and encoding the GIF — happens on your machine, using your machine's processor.

Your diagrams

They are not sent anywhere. There is no backend for them to go to. When you click Save, the browser downloads a .fluyo.json file to your disk; when you click Open, it reads one from your disk. Neither involves a network request.

Autosave

The current session is saved to your browser's localStorage, under the key fluyo.autosave.v1. That is local storage on your own machine, not a server: nobody else can read it, and it is erased when you clear site data in your browser.

Product analytics

The public site includes aggregate usage analytics, served by Umami Cloud. No cookies and no fingerprinting, and no user identification.

What is recorded is pageviews plus this closed list of events:

The content of your diagrams is never sent, neither whole nor in fragments: events carry only values from a closed vocabulary plus one number. There is no free-text field anywhere that one of your labels could slip into.

The analytics script loads only when the domain is fluyo.space or www.fluyo.space. If you clone the repository, open it locally or self-host it, that code never runs and no network call is made. Preview domains are deliberately excluded. The condition lives in js/analytics.js, in a single block, so you can verify it yourself.

If you want zero analytics: run the project locally or self-hosted, or block the cloud.umami.is domain. Fluyo works the same — the analytics code is written to fail silently.

The only external request

The editor loads gif.js from the cdnjs (Cloudflare) CDN; that is the library that encodes the GIF. It is a code download: nothing of yours is sent to it. As with any HTTP request, Cloudflare sees your IP address and user agent while serving the file. It is precached on first visit, so on later visits it is usually not even requested.

B. The MCP server at mcp.fluyo.space

Here is the part that needs saying plainly: the MCP server does receive the content of your diagrams over the network. This is unavoidable — it cannot edit or export a diagram it has not received — and it is the substantive difference from the editor.

This applies only if you have added https://mcp.fluyo.space/mcp as a remote connector in your AI assistant. If you run the server locally over stdio (npx fluyo-mcp), nothing leaves your machine and this section does not apply either.

What is received

• The diagram document your assistant sends: nodes, labels, colours, coordinates and, where present, images you embedded as data URIs.
• The arguments of the invoked tool — for example the label text when creating a diagram.
• Network metadata inherent to any HTTP request: your IP address (that of the calling client, which is normally your assistant's server rather than your own machine), request headers and the path.

How it is used and for how long

It is processed in memory and discarded. Each HTTP request builds a fresh server, handles the message and throws it away. There is no database, no disk, no cache and no sessions: the server is stateless by design, not by configuration. The document exists in the process's memory for as long as the request takes — milliseconds — and disappears with it.

Nothing is persisted. Nothing is shared. Nothing is used to train anything.

What is logged

One line per request, in exactly this shape and nothing more:

{"ts":"2026-08-03T16:20:11.437Z","route":"/mcp","method":"POST",
 "status":200,"outcome":"ok","durationMs":7,
 "requestBytes":220,"responseBytes":472,"tools":["create_diagram"]}

No user data — document, labels, tool arguments, error messages, IP address — is written to the log. The name of the invoked tool is recorded, never its arguments; and if something fails, the log records that it failed and what class of error it was, never the value that caused it.

This does not rest on the discipline of whoever edits the code: the type describing a log line is a closed structure with no field that free text could occupy, and automated tests plant unrepeatable markers in a diagram's labels and fail if those markers appear in any log line. There is no debug mode that lifts these restrictions.

IP addresses and rate limiting

The server limits requests per IP address so that an open endpoint does not become an abuse or billing problem. For that purpose, and only that purpose, it keeps in RAM a record of the IP address and the timestamps of its recent requests.

• It is kept for the 60-second window of the limit, and expires on its own.
• There is a cap of 20,000 addresses held in memory at once; beyond that, the oldest are dropped.
• It is never written to disk. It is never written to the log. It dies when the instance is recycled.
• The IP address is read from the x-forwarded-for header, which the hosting platform rewrites.
• It is used for nothing else: it does not identify, does not profile and does not decide permissions.

Authentication

The server asks for no credentials, creates no accounts and issues no tokens. There is nothing of yours on file because there is no sign-up.

Dependencies involved

No dependency was added for the HTTP transport: it uses Node's standard library. The dependency tree is the one already pulled in by the official Model Context Protocol SDK.

Of that whole tree, six packages actually load at runtime: @modelcontextprotocol/sdk, zod, @hono/node-server, ajv, ajv-formats and zod-to-json-schema. None of them persists anything and none of them makes outbound network requests. Their role is limited to routing the message, validating its shape and converting between request representations.

One honest detail: @hono/node-server, the component that adapts the HTTP request, may write connection errors to the console — ECONNRESET and similar, typical of a client that disconnects mid-response. Those messages are socket errors and contain no user data: they carry no document, no labels and no tool arguments.

Hosting platform logs

Both domains — fluyo.space and mcp.fluyo.space — are hosted on Google Cloud, as separate services under the same account. The MCP server specifically runs on Cloud Run.

Like any hosting provider, Google Cloud keeps its own platform logs in Cloud Logging, separate from the MCP server's and outside the control of this project's code. In the case of Cloud Run, the platform writes one log entry per request automatically, before the request reaches our code. Those logs include:

• The client IP address.
• The requested path and HTTP method.
• The response status code and its latency.
• The user agent and other request headers.

Retention: 7 days. This is not the default — Google Cloud Logging retains 30 days out of the box — but a value set explicitly on the _Default bucket. The exact command that sets it is published in the server's README, so this figure is verifiable rather than a promise.

They do not contain request bodies, so the content of your diagrams does not appear in them.

These logs should not be confused with the application log described above: they are two different things. The application log writes no user data at all, not even the IP address, and that stays true regardless of what happens to platform retention. Platform logs do contain the IP address, which is why they expire after 7 days.

For how Google handles that data as an infrastructure provider, see the Google Cloud privacy notice.

Who the data is shared with

Nobody. It is not sold, not transferred, not used for advertising and not used to train models. There is no profiling and no automated decision-making about people.

The only third parties involved are infrastructure providers, each with a narrow role:

None of the three receives the content of your diagrams.

Children

Fluyo is not directed at children under 13 and does not knowingly collect data from them. Since there are no accounts and no sign-up, there is also no profile that could belong to a child.

Your rights

The practical situation is unusual and worth stating as it is: there is no account, no profile and no record of yours to access, rectify or erase, because nothing identifying you is stored.

• Your diagrams are on your machine. To delete them, delete the files and clear site data in your browser.
• The data that does exist outside your machine — the platform logs — expires on its own under the retention stated above.
• Even so, if you wish to exercise any right of access, rectification, erasure, objection or portability, write to nectdnb@gmail.com and it will be handled.

Verify it yourself

All of the above is checkable: the source of both parts is public and MIT-licensed.

• github.com/itsnect/fluyo — the editor. Analytics is isolated in js/analytics.js.
• github.com/itsnect/fluyo-mcp — the MCP server. What is and is not logged lives in src/http-logging.ts; the per-IP limit, in src/http-security.ts.

Changes to this policy

If it changes, the date in the header is updated and the change is recorded in the repository's public history, commit by commit. A change that materially affects what data is received will additionally be announced in the repository.

In case of discrepancy between translations, the Spanish version prevails.