Security and data

This page covers data ownership, the security measures behind the platform, who can see what, and — because your app is built by an AI assistant you bring yourself — what leaves Floot while you build.

Data ownership

You own 100% of your app:

Code

Complete code ownership.

Data

All app data belongs to you.

IP

Full intellectual property rights.

You can download a full SQL dump of your database at any time on any plan, unless your hosting is taken down for an unpaid balance: open your project on floot.com, go to the Services tab → Data, open a table, then use the cog icon in the table header → Database Settings → Export → Download Database. Code download is included on every paid plan, from the project-name dropdown in your project's top bar → Get Code.

Both are browser actions. Your assistant can read any file in the project and query the database for you through the connector, but the downloadable archive is built in your browser. Follow the preview link your assistant gives you, or find the project on floot.com, then use the menus above. See Code, data, and exports, or Self-hosting if you want to run the app yourself.

Security measures

Encrypted in transit

All traffic is served over HTTPS/TLS.

Encrypted at rest

Your database, your project source, and your files are stored on managed AWS and Neon infrastructure with provider-level disk encryption.

Secret handling

API keys and secrets are never typed into chat. Floot collects them through a dedicated form: your assistant hands you a one-time link, and you paste the key into a Floot page in your own browser. They are stored server-side, injected into your backend at runtime, and never returned to any client. Before a key is stored, Floot also encrypts it with a separate key held in AWS Key Management Service, on top of the provider-level disk encryption, so a copy of the database alone does not reveal it. A stored key is never displayed again, to anyone: if you lose your own copy, create a new key at the provider and replace it.

Secrets are not visible to the AI

This is enforced by the shape of the data, not by instructions to the model: the integration list an assistant can see carries only a connection's name, type, description, and non-secret config values. The secret values are not part of that payload.

Your app's user passwords

The built-in email-and-password sign-in stores passwords as bcrypt hashes, never in plain text — see Sign-in for your app's users.

Security headers

Every published app is served with a Content Security Policy and a Referrer-Policy, and you can block other sites from embedding it or set your own policy — see Security headers and embedding.

Your visitors' IP address

Every request to your app's backend, published or in the preview, carries the visitor's IP address as Floot's edge received the connection, in the x-floot-client-ip header. Floot replaces any value a caller sends under that name, so it is the address to use for per-IP rate limits (login, signup) and blocks. Headers such as X-Forwarded-For or CF-Connecting-IP arrive as the caller sent them and anyone can fake them. Ask your assistant to key its limits on x-floot-client-ip.

Account protection

Optional two-factor authentication with an authenticator app and single-use recovery codes, and one click to sign out every other device and connected assistant — see Your account.

Internal access

Floot staff open a private project or its data only to handle a support request from you, to address a security or technical issue, or where the law requires it.

Who builds your app, and what it can see

The model writing your code is not Floot's. It is the assistant you connected — Claude, ChatGPT, Cursor, Codex or another MCP client — running under your own agreement with that provider. Floot's connector supplies the tools; the conversation, your prompts, and everything those tools return sit in that provider's context and are governed by their terms, not by Floot's. If you are reviewing Floot for procurement, this is the material point: your builder is a third party you chose and contract with directly.

What an assistant can read through the connector: your project's files, rows from your app's database (query_database, execute_sql, pull_database_schema), your app's backend logs (get_logs for the preview, and your published app's logs through run_code_in_vm), and screenshots of the running preview. If your database holds real user data, that data reaches your assistant's context whenever you ask a question that requires it.

What it cannot do: read your integration secrets, or spend your money. Plan changes and every purchase are browser pages a person clicks, deliberately never tools an agent can call.

Your conversation is not stored on the project. What Floot keeps is two things: the files your assistant writes, and a running activity record of what it did — which files changed, the start of each SQL statement that changed data, which images were generated — that the project's history and the Checkpoint panel are built from, and that stays for as long as the project does. Separately, a raw audit row per tool call — tool name, a capped summary of the arguments, the result — is kept for about three days and then deleted. The same capped argument summary also appears in the connector's server logs, which are kept for a month, and a usage record of each call — tool name, outcome, timing, and project, without the arguments or the result — is kept as usage history. The chat around those calls never reaches Floot; it stays with your AI provider.

Is my data used to train AI?

No. Data in the apps you build — your database, your users' accounts and content, uploaded files, and anything your app receives from connected services — is never used to train AI models, by Floot or by anyone Floot passes it to. When your app sends data to an AI provider to answer one of its users, that provider works under commercial terms that prohibit training on it. The conversation with the assistant you build with is covered by your own agreement with that provider.

How long Floot keeps things

What Floot logs

For a published app, Floot's own log lines record each request's method and path. They do not include request or response bodies, headers, cookies, or IP addresses. Whatever your app's own code writes to its logs is stored exactly as written, so keep passwords, tokens and personal data out of your log lines.

While you build, the preview also captures full request and response bodies and headers, for one hour, so your assistant can debug a failing request. Passwords, tokens, one-time codes, API keys, cookies and authorization headers are masked before they are stored. Logs are read through your assistant: get_logs for the preview, and the published app's logs on request.

Keep request and response bodies out of preview logs

If you test your preview with real personal data, you can stop it from recording what was sent and returned. In Project Settings, under AI instructions, turn on Keep request and response bodies out of preview logs. It is off by default, and anyone who can edit the project can change it.

• Preview logs, and what your assistant reads with get_logs, keep each request's method, address, status, timing and headers, and your backend's log lines. The request and response bodies are replaced with a note that they were not recorded.
• Backend requests are covered at once, including ones recorded in the hour before you turned it on. Requests made from the browser are covered from the next time the preview loads.
• What your app's own code writes to its logs is not covered, so keep personal data out of your log lines.
• Your published app is not affected: Floot never records its request or response bodies.

Where your data lives

Your projects, databases, database recovery history and uploaded files are stored in the United States, on AWS and Neon in the us-east-1 region, and your app's backend runs there too. Two things can happen elsewhere: the CDN serves cached copies of published pages and public files from locations around the world, and AI providers may process requests in other regions. If you connect a database you host yourself, its data lives wherever that provider keeps it — see Your database.

The companies that process data for Floot (hosting, database, email delivery, analytics, AI providers) are listed in the privacy policy under Third-party Service Providers.

Files your app stores

Each file your app stores is either public or private. A public file is served from your app's CDN address to anyone who has the link. A private file can't be opened by its address at all: your app's backend hands out a signed link after its own permission check, valid for 5 minutes unless your app asks for longer, and 24 hours at most. Signed links expire on their own.

Uploads work the same way. Your app's backend issues an upload link that is good for 15 minutes and tied to one file name, type and size, up to 100 MB. Tell your assistant which files must be private when you describe a feature. Stored files are separate from the database and are not part of its backups — see Your database.

When your app replaces a file

Public files are cached so they load fast: by the CDN for up to a day, and by visitors' browsers for up to a year. That suits files that never change. When your app saves a new version under the same name (a profile photo, a generated report, a JSON feed), people can keep seeing the old one. For files like that, ask your assistant to make them update right away, for example: "when a user changes their profile photo, show the new one right away." It sets a shorter cache time on each upload of that file, such as five minutes, and that time is used instead of the default.

• It applies from the next upload of each file. A copy already cached under the old setting stays until it expires, so a browser that has the old file can keep showing it.
• It needs a code change, so the live app gets it when you publish.
• To show a new version to everyone at once, save it under a new file name (for example with a version number or date in it) and point the app at the new name. Files that never change can keep the default caching.

Vulnerable packages your dependencies pull in

A security scan such as npm audit sometimes flags a package your app never installed itself: one of your packages depends on an old, vulnerable version of it. ExcelJS pulling in an old uuid is a common example. When the package you use has a fixed release, updating it is the fix. When it has none yet, you can ask your assistant to pin a safe version of the vulnerable package for that one parent, for example: "npm audit says exceljs pulls in a vulnerable uuid, pin a safe one."

• The pin applies to your preview, and to your published app from its next publish.
• It moves only the copy that one package depends on, and only while that package is one of your app's own dependencies.
• Floot refuses a pin that would change a package it manages itself, such as React, Vite or Capacitor, whether as the package pinned or the one that pulls it in; those stay on the versions Floot ships.
• A pin is an exact version or a ^/~ range on one, and a project can hold up to 20.

Privacy and visibility

Your projects

Preview links deserve their own line, because your AI assistant hands them out routinely. Every preview URL carries a token in its query string (?ptoken=…). That token is a view-scoped grant for exactly one project: it can read the project and interact with the running app, and it cannot write files, publish, or touch your account. It acts with the access of the person it was made for, so it stops working if that person loses access to the project. Otherwise it expires seven days after it was issued, and a single link cannot be revoked before then. To close every preview link of a project at once, turn on Only allow internal publish in Project Settings → Advanced Settings: within about a minute the links, and the access they gave to the preview's backend, work only for people signed in to Floot who have access to the project, and the preview's storage files move to a private address. Endpoints that export flootPreviewPublic (webhooks) still answer anyone and check their caller themselves — see Publish privately.

The no-login part is deliberate. These links are usually opened on a phone, inside a chat app's in-app browser, which carries no Floot cookies — a sign-in wall there would be a dead end. The trade-off is that anyone the link is forwarded to can open it until it expires, so treat a preview link the way you would treat a shared document link. Opening one while signed in as the owner still gives you your normal rights; the token never downgrades you. Someone signed in to a different Floot account with no access to the project is sent to the Floot home page instead, and gets in from a private browser window.

For a private project:

• Your code and prompts are not visible to other Floot users
• No one else can duplicate it
• Access is limited to you, your collaborators, anyone holding a live preview link, and Floot staff as described above
• Only you, the owner, can delete it
• An AI assistant you connect works with your Floot account's access, so it can open every project you can unless you limit it. Protect that ChatGPT or Claude account as carefully as your Floot sign-in. You can make an assistant read only, stop it from publishing, or limit it to one project, and disconnect one you no longer use, from your account page: see Limit what an assistant can do and Your account

Working through your AI assistant on a project that someone else owns and shared with you requires a paid plan on your own account — the connector runs on your assistant's tokens, so the seat is what the plan pays for. In the floot.com editor you can open a shared project on any plan, but editing its code by hand there needs a paid plan on both your account and the owner's. Reading a public project's code is never gated; writing to a project you do not own is.

Your app's user data

Data your app collects — accounts, form submissions, uploads — is:

• Stored in your app's own Postgres database and file storage, on managed infrastructure with provider-level disk encryption
• Readable by the AI assistant you build with whenever a prompt requires it, which means it reaches that provider's context
• Your responsibility to handle in line with applicable law

Handling sensitive data

If your app handles healthcare, financial, or otherwise regulated data:

1. Consult legal counsel about your compliance requirements
2. Decide whether your assistant may query that data at all — a query you ask for sends real rows to your AI provider
3. Contact Floot to discuss your specific needs before you launch