Security

In Short: In a BYOC deployment your data stays in your own cloud account. We secure the control plane, the sign-in system, and the software. You secure your cloud account, your users' credentials, and the sources you connect.

OptimaFlo runs as bring-your-own-cloud (BYOC). The data plane, meaning storage, compute, and pipeline orchestration, runs inside your own Google Cloud or AWS account. The control plane, our hosted web app and API, stores only the metadata needed to run the Services: table and column names and types, pipeline definitions, run status and logs, and workspace settings.

What we are responsible for: the control plane's availability and security, the encryption and access controls described below, and how we handle Customer Data on your instructions. What you are responsible for: your cloud account's configuration and access policies, the users you invite and the roles you give them, and the sources you choose to connect. Full detail is in the DPA.

In a BYOC deployment, Customer Data at rest stays in your own Google Cloud or AWS account for the life of the deployment. Our control plane is hosted in the United States on Fly.io and Supabase and stores only the metadata listed above, not your source tables. Where you do not use BYOC, Customer Data is stored by us and our hosting providers in the United States.

Each workspace has its own catalog and namespace. Access to a workspace's data is scoped to the organization and workspace it belongs to.

Data in transit between your browser and the Services, and between our services and the sub-processors listed at optimaflo.io/subprocessors, is encrypted with TLS. Control-plane data is encrypted at rest by our hosting providers.

Workspace secrets, such as connection credentials for sources that need them, and per-organization AI provider keys, are encrypted at rest with Fernet symmetric encryption and decrypted only server-side when a request needs them. They are masked wherever we log.

Retention and deletion follow the schedule in the DPA: you can export or delete Customer Data at any time, and after the Agreement ends you have 30 days to export before we delete it from our systems.

Users sign in with email and password or with Google. Two-factor authentication (TOTP) is available and any user can turn it on in their account security settings.

Access inside an organization is role-based: owner, admin, member, and viewer. A user's role controls what they can see and change in a workspace. Database-level row-level security policies scope every tenant's records to that tenant, so one workspace's data is not reachable from another workspace's queries.

Sessions are bound to a secure, HTTP-only cookie and expire after a period of inactivity. Session validity is checked against a short-lived cache so access can be revoked quickly if a session is compromised.

Where your cloud provider supports it, we access your BYOC account through identity federation, meaning Google Cloud workload identity or an AWS cross-account role, instead of a long-lived key you would have to rotate yourself.

OAuth tokens used during deployment (for example, to trigger a cloud build) are used once for that action and are not stored by us afterward. Where a key or secret is unavoidable, such as an HMAC key some engines need for storage access, it is managed with automatic rotation and is masked wherever we log it.

When you or your users use an AI feature, we send the model provider only what it needs to answer: your request, the names and types of the relevant tables and columns, and, where the feature needs it, query results or samples. We do not use Customer Data to train AI models, ours or a third party's. Full detail, including which providers receive requests and what happens if you configure your own provider key, is in DPA Section 11.

We record traces of AI-feature requests for debugging and quality, and keep them only as long as needed for that purpose.

Every code change goes through version control and review before it ships. Automated tests, type checks, and lint checks run in continuous integration and must pass before deployment. Development, staging, and production environments are kept separate. Application secrets live in environment and secret managers, never in source code. Our API includes rate limiting to protect the control plane from abusive traffic.

We monitor errors with default personal identifiers turned off, and we keep pipeline run logs so problems can be diagnosed. If a security incident affects Personal Data in your Customer Data, we notify you without undue delay and within 72 hours, as set out in the DPA.

Our hosting providers take routine backups of the control-plane metadata we hold. You are responsible for backing up the data you connect to or process through the Services, including in your BYOC cloud account. Uptime commitments for eligible plans are in our Service Level Agreement.

In Short: Found a security problem? Email us. Good-faith reports are welcome and we will not take legal action against you for them.

Email evan.rosa@optimaflo.io with the subject "Security report." Include the steps to reproduce, the impact you believe it has, and any proof-of-concept material. We aim to acknowledge reports within 3 business days.

In scope: the OptimaFlo web app and API. Out of scope: testing against another customer's workspace or data without their written permission, denial-of-service testing, and social engineering of our staff or customers. Please give us a reasonable time to fix an issue before disclosing it publicly. We do not currently run a paid bug bounty program.

OptimaFlo is not currently certified under SOC 2 or ISO 27001. If a certification is a hard requirement for your team, tell us before you commit and we will confirm whether we can meet it.

We will complete a reasonable security questionnaire on request. Our data processing terms, including the EU Standard Contractual Clauses, the UK Addendum, and CCPA service-provider terms, are in the DPA. Our sub-processors are listed at optimaflo.io/subprocessors. See our Privacy Policy for how we handle personal information generally.

The Services are not designed for HIPAA-regulated health data or payment card data, and we do not support those workloads unless a separate signed agreement says otherwise.

Questions about this page, a security questionnaire, or a vulnerability report: email evan.rosa@optimaflo.io or write to OptimaFlo, LLC, 18310 Montgomery Village Ave, Gaithersburg, MD 20879, United States.