Security: what FlatQL stores and where credentials live
FlatQL is a client. It holds your account, the connection records and a log of what was run. It does not keep your data, and it installs nothing on the cluster.
Nothing on the cluster#
FlatQL talks to Elasticsearch and OpenSearch over their HTTP API with the credentials you give a connection: an API key, a username and password, or an Elastic Cloud ID with a key. There is no plugin to install, no agent, and no cluster users or roles created for team members. Per-person access is enforced by FlatQL before a request reaches the cluster, as described under teams. Rotating the credentials on a connection is the only cluster-side change you ever make.
What FlatQL stores#
| Data | What exactly | Why |
|---|---|---|
| Account | Name, email, salted password hash, team membership, role | Sign-in, invitations, password reset, receipts |
| Connection records | Name, environment, URL or Cloud ID, auth type, TLS settings, safety flags, which secret fields are set | Show and test connections without decrypting anything |
| Connection secrets | Password, API key, token, secret header values, encrypted | Talk to the cluster on your behalf |
| Query history | Statement text (up to 4,000 characters), user, connection, index, duration, row count, error, the plan with the Query DSL sent | History, grouping and usage views |
| Audit log | Who did what, when, on which connection, with a short detail | Team accountability |
| Ask FlatQL | The question (up to 500 characters) and the statement it produced, as an audit entry; usage counts for the daily limit | Usage view and limits |
| Worksheets and saved queries | The SQL text you keep | Your workspace |
| Billing | Plan, status, seat count, payment and invoice references from Dodo Payments | Licensing |
Payment card details are entered on and stored by Dodo Payments; FlatQL never sees them. Transactional email goes through Amazon SES. The privacy policy is the formal version of this table.
What FlatQL does not keep#
Result rows. Rows pass through FlatQL's servers for the duration of a request or an export and are not written anywhere. The query history records how many rows came back, not which.
Uploaded files. A file loaded through Load data is streamed to the cluster in batches. On the hosted service the upload is written to encrypted object storage while it is parsed and deleted when the load finishes, unless you choose to keep it.
Credentials in clear text. Once saved, a secret is never returned by the API. The connection page shows only whether a secret is set. Team members never see credentials; they see the indices they were granted.
Credentials at rest on the web#
Secrets for a connection are serialised as a small JSON document and encrypted with Fernet (AES-128-CBC with an HMAC-SHA256 tag, in the cryptography library's construction). The encryption key is not stored alongside the data: it lives in a separate key file on the server, outside the database, and can instead be derived from a passphrase and held only in memory while the vault is open. A database backup on its own does not contain enough to decrypt a single connection.
The connection record keeps a non-secret index of which keys exist (password, api_key, …) so the UI can show presence flags without touching the vault.
Credentials in the desktop app#
In the desktop app the same encrypted store lives on your machine, and the key that encrypts it is held in the operating system's keychain under FlatQL Desktop. For a connection marked This Mac only, the credentials, the requests to the cluster and every result row stay on the machine. FlatQL's servers receive the account checks, the statement text and metrics for the shared history, and the schema context when you use Ask FlatQL. A connection reaches FlatQL's servers only if you choose to sync it to the web, and that choice can be reversed.
The app's local backend accepts requests only from the app window, identified by a key generated at each launch; other processes and browser tabs on the same machine are refused. A 4-digit PIN locks the window, and five wrong attempts fall back to your FlatQL password, verified by the server.
Transport#
Connections to clusters use TLS when the URL is https. Certificate verification is on by default; you can paste a CA certificate for a private authority, or switch verification off for a self-signed development cluster, in which case the connection test marks the TLS step with a warning. A production connection over plain http is flagged in the connection test. Sessions on flatql.com use signed, time-limited cookies that stop working when the account's password changes.
Safety rails#
Beyond access control, every connection has guard-rails: read-only mode (rejecting any request that is not a recognised read API), confirmation before destructive requests such as deleting an index, _delete_by_query, reindex or cluster settings changes, and a block on wildcard deletes like DELETE /logs-*. They are described with the roles under teams, and the index-level access page shows them in use.
Deletion#
Ask from the Account page or through the contact form. Accounts, teams, connections and history are deleted within 30 days.
Reporting a problem#
Use the contact page. Include the connection type and the exact error text; do not include credentials.