Skip to main content

MySQL

What it is​

A MySQL connection lets SQL nodes run queries and statements against one schema. Nodes reference the connection by name; the password itself is written to Honeybase's secret store at setup and is never returned by the API afterwards.

MySQL and MariaDB both work through this integration.

Before you start​

  • The server must accept connections from Honeybase's egress addresses. If it sits in a private network, use the SSH tunnel described below.
  • MySQL users are scoped by host pattern, so the user you create has to be allowed to connect from Honeybase, not just to exist.

Setup fields​

These are the fields the guided setup collects — both the Add integration form and the setup card Barry raises in chat. Additional settings live on the connection's settings page once it exists.

Connection settings​

FieldTypeRequiredSecretNotes
nameTextYesNoDisplay name for this connection. This is what you pick from in a workflow node.
hostTextYesNoHostname or IP address of the server, reachable from Honeybase.
portNumberYesNoTCP port. MySQL listens on 3306 by default.
databaseTextYesNoThe single schema this connection targets. In MySQL a "database" is a schema.
usernameTextYesNoThe MySQL user Honeybase authenticates as.
sslToggleNoNoRequire TLS for the connection. Leave this on unless the server genuinely has no TLS.

Credentials​

FieldTypeRequiredSecretNotes
passwordPasswordYesYesThe password for that user. Create a dedicated user for Honeybase rather than reusing an application account.
Configured after the connection exists

The guided setup does not ask for SSH tunnel, read-only mode, connection pool size, connection lifetime or query timeout. Open the connection on the Integrations page to change them.

Creating a user for Honeybase​

CREATE USER 'honeybase'@'%' IDENTIFIED BY 'a-strong-generated-password';
GRANT SELECT ON analytics.* TO 'honeybase'@'%';
FLUSH PRIVILEGES;

Narrow '%' to the address range Honeybase connects from if you can, and grant INSERT, UPDATE or DELETE only on the specific tables a workflow writes to.

Using this connection in dashboards​

Dashboards can chart this database. Their queries are always read-only — a single SELECT in a read-only transaction that is rolled back, whatever the Read-only mode setting says — but a function already in your database can write outside that transaction. So for a connection dashboards use, give Honeybase a user that can only read, as above, and keep a separate connection with a writing user for the workflows that need one. Read-only queries explains both layers and the gap.

Read-only mode and the SSH tunnel​

Read-only mode wraps every statement in a read-only transaction, so a node that tries to write against a read-only connection fails at the database rather than silently doing nothing.

SSH tunnel connects through a bastion host instead of directly. Turning it on reveals the public key to install on the bastion and the Honeybase IP ranges to allow through.