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. Redbrix requires this encrypted connection and will not fall back to an unencrypted one — if TLS can't be established, the connection fails rather than sending your credentials or data in the clear.

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.

Your database password is held in your server-side session for the length of that session and nothing else. It is never written to our database, 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. Passwords are not among them.

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 (excluding passwords), 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.