Security

Your browser can't speak to MySQL directly, so Redbrix runs a connection service between the two. When you open a table or run a query, the request goes from your browser to that service over HTTPS, and from the service to your database over port 3306. Results come back the same way and are rendered in your browser.

That means Redbrix does handle your data in transit. We think it's better to say so plainly than to imply otherwise — so the rest of this page is about what happens to it.

The connection from Redbrix to your database is encrypted with TLS by default. If your server doesn't support TLS, Redbrix refuses the connection and tells you — it never downgrades silently. You can then choose to connect without encryption, and Redbrix shows you throughout your session whenever a connection is unencrypted.

At this stage we encrypt the connection but do not yet verify your server's TLS certificate. In practical terms, this protects your data against passive interception on the network, but not against an active attacker able to impersonate your database server on the connection path. Full certificate verification is on our roadmap. If you want protection against that stronger class of attack today, we recommend connecting Redbrix over an SSH tunnel, or restricting the Redbrix database user to a VPN or IP-allowlisted network.

By default, your database password is held in your server-side session for the length of that session and nothing else. It is never logged and never included in error reports. When your session ends — logout, or one hour of inactivity — it is gone, and you'll be asked for it again next time.

You can optionally save non-secret connection details (host, port, username, database name) so you don't retype them. Those are stored encrypted at rest.

There is one exception, and it is deliberate. On the Team plan an administrator may choose to save a connection's password so their colleagues can use that connection without being given the credentials themselves. It is off unless an administrator turns it on, only administrators can set it, and the password is encrypted at rest under a separate key from the rest of the connection details.

We don't copy it. Query results pass through our connection service to your browser and are not written to disk or retained after the request completes.

We don't analyse it. Your data is never used to build features, train anything, generate statistics, or inform product decisions.

We don't share it. No third-party analytics, no advertising, no data brokers, no tracking of any kind inside the application.

We don't read it. No member of the Redbrix team accesses your database or its contents. If you raise a support issue that requires it, we'll ask for your explicit permission first and tell you exactly what we need to look at.

To run the service and keep it secure, we retain: your account email, your saved connection settings — including a connection password only where a Team administrator has chosen to save one, encrypted at rest — and operational logs containing timestamps, IP addresses, and error messages. Logs do not contain query text or result data. They're kept for 30 days and then deleted.

We also store any custom display settings you make in the app, such as custom column labels, title fields and filters. This is important for your experience, but it contains no data from your database.

We'd rather you didn't give us a privileged account. Create a dedicated MySQL user scoped to what you actually need:

CREATE USER 'redbrix'@'%' IDENTIFIED BY 'a-strong-password';
GRANT SELECT, INSERT, UPDATE ON your_database.* TO 'redbrix'@'%';
FLUSH PRIVILEGES;

Drop INSERT and UPDATE for read-only access, or name individual tables instead of your_database.*. Revoke it at any time with DROP USER 'redbrix'@'%'; and access stops immediately.

Add DELETE if the user needs to delete data from within the application, although you should proceed with caution.

Redbrix connects from these fixed addresses, so you can restrict that user to them at your firewall: 13.134.60.54.

Please email security@redbrix.io with enough detail to reproduce the issue. We acknowledge every report within seven working days, and we will not take legal action against anyone doing good-faith security research.

We do not operate a paid bug bounty programme and do not offer rewards for reports. We are a very small team, and we would rather be straightforward about that up front than leave anyone expecting otherwise. We are glad to credit researchers who would like to be named.

Reports produced solely by automated scanners — missing headers on pages with no authenticated actions, and similar — are welcome, but are usually already known to us and are treated as low priority.