Security at SnoutData
SnoutData is two products with two different security models, and this page keeps them apart. SnoutData Studio is local-first: your database credentials stay on your machine, and so does your data, except what you choose to send the AI assistant. SnoutData Cloud is a managed service: you ask us to run a database, so we hold what is in it. Both are described below, in the same words we would use to a security reviewer.
Two products, two models
SnoutData Studio runs on your computer and connects straight to the databases you point it at. Nothing on that path needs us. Your credentials are held by your operating system keychain, your queries go from your machine to your database, and the results come back to your machine.
SnoutData Cloud is the opposite arrangement, deliberately. You ask us to run a database for you, so we hold it: the data, the backups, and the project password we issue you. That is what every managed host does, and we would rather describe it than imply otherwise. If what you want is credentials that never leave your machine, that is SnoutData Studio.
Cloud: we run it, so we hold it
A hosted project is built around a Postgres database in an isolated container on a machine we operate, with its contents copied continuously to object storage we operate. If you switch on the services around it, the authentication service, the data API, file storage, realtime, and the functions you deploy run there too. So your hosted data, the files you upload, the accounts your own users create, and the code you deploy are all held by us.
We also generate your project's database password and store it, encrypted, so any client you are signed in to can fetch your connection details without you copying a secret around. You can reveal it and rotate it yourself whenever you want. We do not tell you we are unable to read your hosted data, because that would not be true. What binds us is our terms of service, the controls below, and an audit log that records every action taken against a project.
Cloud: how a hosted project is protected
- Each project is its own container, its own database, its own credentials and its own storage prefix. Projects do not share a database, and no project is reachable from another. A project is handed storage credentials for its own prefix only, minted an hour at a time, and the network it runs on refuses the cloud provider's metadata service and the private ranges around it.
- The project password is stored as AES-256-GCM ciphertext. The key that unwraps it is held separately from the database holding the ciphertext, and the plaintext exists only inside the single server function that mints it or serves it to you.
- Backups and files live in versioned object storage under an object lock retention, continuously replicated to a second region, so an accidental delete and the loss of a whole region are both recoverable rather than final.
- Disks are encrypted at rest, and everything is encrypted in transit: TLS on the database door and on the HTTP door, with certificates renewed automatically.
- Who can see a project is decided by row level security on every read, not by application code that could be asked nicely to skip it. There is no impersonation path around it.
- Every action that changes a project (create, pause, resume, rotate a password, fetch connection details, restore, delete) is written to an audit log you can read in your dashboard.
Cloud: where it runs
Hosted projects run on Amazon Web Services in the United States (Oregon), on machines we manage ourselves rather than through a managed database service. Backups and uploaded files are stored in Amazon S3 in the same region and replicated to a second United States region. Emails a project's authentication service sends to your own users, such as sign-up confirmations, go through our transactional email provider. Nobody else receives your hosted data.
Cloud: what is not done yet
SnoutData Cloud is young, and an honest security page says what is still on the list. Encryption keys are held as platform secrets rather than in a dedicated key management service. The audit log records who asked the platform to do something, not which person ran a particular statement inside a shared database session. And no plan carries a signed uptime commitment. Our full security overview walks through each of these with the control that is in place today, and we will send it on request.
Studio: your database credentials never leave your machine
When you save a connection, its password, SSH key, and passphrase are encrypted with your operating system keychain (Windows Credential Manager, the macOS Keychain, or libsecret on Linux) and stored only on your device. SnoutData resolves them locally to open the connection. They are never transmitted to us, and we have no way to read them.
Studio: your query results stay local
Queries run from your machine directly to the database you connect to. Results come back to your machine and stay there. For a database of your own, SnoutData does not proxy, copy, or warehouse its contents, and there is no server-side path for our staff to reach it. The one exception is a question you ask the AI assistant, which is described below. A database you ask us to host is the other case, and it is covered above.
Everything in transit is encrypted
Traffic between the app and SnoutData services (sign-in, billing, the AI assistant, updates, and the doors to a hosted project) uses TLS. For your database connections, every driver supports TLS and SSH tunnels are always encrypted, so you can require an encrypted link to your own database.
AI privacy, with an option to bypass us
When you use the assistant, your prompt is sent to the SnoutData AI gateway to reach a model, and the reply streams back. The prompt carries the context the answer needs: parts of your database schema, and query results when you ask about them. The gateway records which model answered, the token counts and the time, so your plan can be metered, and keeps no copy of the prompt, your schema, your data or the reply. Your chat history is kept locally on your device, and nothing you send is used to train models. Editor features like completion and hover run fully on your machine and never call a model.
On Plus, Pro and Business you can also bring your own provider key, which routes the assistant's chat and edits straight from your machine to OpenAI, OpenRouter, or Anthropic. On that path your key and those prompts never touch our servers. AI completion in the editor needs a fill-in-the-middle model, so if you switch it on it still uses SnoutData's completion model through our gateway. Read how bring your own key works.
How your payment details are handled
Payments run entirely on Stripe, a PCI DSS Level 1 certified provider, and never pass through SnoutData's own infrastructure. You enter your card on Stripe's hosted checkout page, and you change your plan or card in Stripe's customer portal. Stripe stores the card and charges it. What comes back to us is a customer reference and the state of your subscription (plan, status and renewal date), which is how your plan is applied to your account.
Infrastructure and subprocessors
SnoutData runs on established providers, each encrypting data at rest by default:
- Amazon Web Services: authentication, account data, and the machines, backups and file storage behind hosted SnoutData Cloud projects
- Stripe: payments and subscriptions
- Cloudflare: website hosting and installer downloads
- GitHub: source code and release distribution
- Sentry: anonymized crash reporting, scrubbed before it is sent
- Resend: transactional email, including what a hosted project's authentication service sends to your users
- AI model providers: the models behind the AI assistant, reached through our AI gateway. They process a prompt only to answer it and do not train on it
Vulnerability management
Dependencies are watched by automated scanning, and the code is scanned for vulnerabilities and leaked secrets on a schedule. Security fixes ship through the app auto-updater, so users move to a patched version on next launch.
Reporting a vulnerability
If you find a security issue, email security@snoutdata.com. We aim to acknowledge within three business days. Please give us a reasonable window to fix it before public disclosure, and do not access data that is not yours.
Compliance
SnoutData is not yet SOC 2 certified. For SnoutData Studio, the architecture keeps most of what a review would cover out of reach: your credentials never arrive here, and your database contents arrive only as the context of an AI request you make, which our gateway does not keep. SnoutData Cloud does hold customer data, so it is covered the ordinary way instead: an internal security program spanning access control, encryption, incident response and vendor review, and a security overview mapped to the SOC 2 Trust Services Criteria that we will send you. We are happy to complete security questionnaires. If your organization requires a formal report, get in touch and we will scope it.
Questions?
For anything security or privacy related, reach us at security@snoutdata.com.