Privacy notice

NanoFlags is a product of Intinovate (Alibtekarat Althkiya Company for Trading & Marketing). NanoFlags is operated by Alibtekarat Althkiya Company for Trading & Marketing (شركة الإبتكارات الذكية للتجارة والتسويق), a limited liability company registered in Building 2607, Zainab Bint Omar Street, Al Fakhiriyah District, Secondary No. 6957, Riyadh 12737, Kingdom of Saudi Arabia (commercial registration no. 7016629938, VAT no. 314143963600003) ("we"). For privacy questions, contact support@nanoflags.io or use the contact form.

We are the controller of account data, subscription data and website data described below. For workspace content and diagnostics your organization puts into NanoFlags, your organization decides what is stored and why, and we process it on its behalf to provide the service. Organizations that need a data processing agreement can contact us.

• Account data: your e-mail address, the name you enter, language and timezone preferences, your password (stored only as a hash by the authentication provider) and, if you set one up, your two-step verification factor.
• Organization data: organization and project names, memberships and roles, pending invitations (the invited e-mail address and role).
• Workspace content: flags, segments, environments, draft configuration, published revisions, changes, approvals and comments, scenarios and their results, webhook endpoints and notification preferences.
• Audit log: a record of who changed what and when in the workspace, written automatically and not editable.
• GitHub data (only when your organization connects the NanoFlags GitHub App): the GitHub account or organization name and type, the installation id and the names of the repositories it was given access to; for each place a flag key is read in a linked repository, the repository name, file path, line number, the text of that line (at most 240 characters) and the commit. NanoFlags reads source files through the GitHub API to find flag keys but does not store whole files. Webhook delivery ids are kept for 7 days to ignore duplicates; webhook payloads are not stored. Comments and check runs the app posts are stored by GitHub.
• Subscription data: plan, status, billing period and the Paddle customer and subscription identifiers. Card and bank details, billing address and tax details are entered with Paddle and are not stored by NanoFlags.
• Technical data: session cookies needed to keep you signed in and to remember the selected project and environment, and error reports when something fails (see Sentry below).

• To provide the service (account, organization and workspace data, diagnostics) — necessary to perform our contract with you or your organization.
• To bill subscriptions (subscription data) — necessary for the contract, and to meet tax and accounting obligations together with Paddle.
• To keep the service secure (audit log, sign-in and technical data) — our legitimate interest in preventing abuse and investigating incidents.
• To send service e-mails such as verification, invitations, approval requests and publication notices — necessary for the contract; you choose which notification e-mails you receive.
• To answer your messages sent through the contact form or by e-mail — our legitimate interest in responding, or steps you asked for before a contract.

Flags are evaluated locally inside your applications by the NanoFlags SDKs. Evaluation contexts (for example user attributes) are not sent to NanoFlags to make a decision.

SDKs connected with a key send two kinds of reports:

• Service reports: the service name, SDK name and version, and the configuration revision it runs, with the time it was last seen.
• Sampled evaluation events: a bounded sample of evaluations (by default 10%) with the flag key, the returned value, the reason, the revision and a request identifier. By default the SDK redacts the context: only the names of the attributes the flag's rules use are sent, mapped to their type (for example { region: "string" }), never their values. If your developers configure a custom redaction function, whatever it returns is stored; review personal data before doing so.

Each environment has a daily cap on stored sampled events. Configuration downloads by SDKs are authenticated with SDK keys; the keys themselves are stored only as hashes.

• Sampled evaluation events: kept for the diagnostics retention of your organization's plan (Explore 3 days, Team 14 days, Scale 30 days), then deleted. The deletion runs every hour.
• Workspace content, revisions and audit log: kept while the project or organization exists. An owner can delete a project from the dashboard; this removes its flags, segments, revisions, keys and history immediately and cannot be undone, so export what you need first (Settings → Data & export). SDK keys of a deleted project stop working within about a minute.
• GitHub data: code references are replaced on each scan of a linked repository and deleted when the repository is unlinked or removed from the installation, when an admin unlinks the installation, or when the app is uninstalled on GitHub (which also deletes the installation and repository names).
• Pending invitations: kept until the invitation is accepted or cancelled.
• Account and organization deletion: on request. To delete your account or organization, or to exercise another data right, contact support@nanoflags.io or use the contact form. We reply within one month. Deleted data can remain in our database provider's backups for a limited period until they are overwritten in the normal backup cycle.

We do not sell personal data. We use these service providers to run NanoFlags:

• Supabase — database and authentication (stores account data, workspace content, audit log and diagnostics).
• Cloudflare — hosting of the website and dashboard, and the edge network that serves configuration to SDKs.
• Resend — delivery of e-mails such as sign-in links, invitations, approval requests and publication notices.
• Sentry (Functional Software, Inc.) — error monitoring for the website, dashboard and edge services, hosted in the EU (Germany). Error reports contain technical details such as the error message, stack trace, page path and browser type. We configure it not to collect cookies, request bodies, query strings, IP addresses, names or e-mail addresses, and to remove keys and tokens from reports.
• GitHub (GitHub, Inc.) — only when your organization installs the NanoFlags GitHub App: GitHub sends repository events to NanoFlags, and NanoFlags reads the linked repositories and posts pull request comments and check runs there. GitHub handles your GitHub account under its own privacy statement.
• Paddle (Paddle.com Market Ltd and its affiliates) — our online reseller and Merchant of Record for all orders. When you subscribe, Paddle collects your name, e-mail, billing address, payment and tax details to process the payment, calculate tax, prevent fraud and issue invoices, and tells us the resulting plan and status. Paddle handles this data as a controller under the Paddle privacy notice.

We may also share data with professional advisers (such as lawyers and accountants) where needed, and with authorities when the law requires it.

Hosting regions: database and authentication in Mumbai, India (AWS ap-south-1, via Supabase); application and configuration delivery on Cloudflare's global network; transactional e-mail via Resend (Tokyo, Japan). Our providers may process data outside the country where you live; where the law requires it, transfers rely on the providers' standard contractual clauses or an equivalent safeguard.

We use only cookies needed for the service: the sign-in session, the selected project and environment, and — if you choose a plan on the pricing page before signing up — a short-lived cookie that remembers that choice until you reach billing. We do not use advertising or analytics cookies.

Paddle's checkout, which opens only when an admin starts a subscription, sets its own cookies under the Paddle privacy notice.

• All traffic uses HTTPS. Access to workspace data is enforced by row-level security in the database according to your role.
• Passwords are handled by the authentication provider and never stored in plain text; two-step verification with an authenticator app is available, and an organization can require it for owners and admins.
• SDK keys and webhook signing secrets are shown once and stored as hashes or in columns the dashboard cannot read back. Published configuration is signed with Ed25519, and the SDKs verify the signature by default when they read from the NanoFlags edge (from SDK 0.4.0).
• Changes are recorded in an audit log that members cannot edit.

You can update your name and preferences under Profile & security, choose which notification e-mails you receive, and control what your SDKs send through their redaction settings.

Depending on where you live you may have rights to access, correct, delete or port your data and to complain to a supervisory authority. Where the GDPR or UK GDPR applies, these include the rights of access, rectification, erasure, restriction, portability and objection, and to withdraw consent where processing relies on it. Contact: support@nanoflags.io; we respond within one month.