How to run and monitor MySQL in Docker with FrontierStack

Published 2026-09-02

MySQL is the database most likely to be quietly holding up everything else you run. It rarely fails loudly; it gets slow, accumulates connections, locks a table, and the first you hear about it is a customer saying the site hangs. This guide covers installing it, and then the part that matters more: seeing inside it while it is running.

Two ways to install it

You can run MySQL natively, or in a container. Native means a Homebrew formula and a brew services entry from Services ▸ MySQL; it starts at login, and the pane can start, stop and reload it. That is the right choice when MySQL is the machine's job.

A container is the better choice when you want a specific version, a disposable copy for testing, or several databases side by side without them fighting over one config file and one data directory. FrontierStack can build that container for you.

Creating the container

Open the Docker pane and press Create Container…. Choose MySQL from the Start from presets and you get a working configuration to edit rather than a blank form:

• Image mysql:8; change the tag if you need to match a production version.
• Port 3306, bound to 127.0.0.1 only. That default matters: it means the database is reachable from this machine and nothing else. Untick it only if another host genuinely needs to connect, and expect to firewall it if you do.
• Volume mysqldata mounted at /var/lib/mysql; a named volume, so the data survives the container being removed and recreated. Without it, docker rm deletes your database.
• Environment MYSQL_ROOT_PASSWORD, marked secret. Type a real password here; the field is masked, and the value is replaced with •••• in the preview and the logs rather than being printed.

Under Advanced the useful control is the restart policy. The preset uses Unless stopped, which brings the database back after a reboot but respects a deliberate stop. Always will restart it even after you stop it by hand, which is rarely what you want on a workstation.

Read the command before you run it

The sheet shows the exact docker run line it is about to execute, with secrets masked. This is worth actually reading; it is the difference between "the app did something" and knowing precisely what was created. Copy it if you want the same container in a script later.

Press Create and the image is pulled, the container is created and started, and the result comes back in the sheet. It then appears in the Docker pane's container list with start, stop, restart, logs and shell.

Or on a linked server

The same sheet works against any server in your Fleet. Pick the host as the target and the container is created there over SSH; same presets, same preview, same result. This is the part the native service panes cannot do: they only ever install on this Mac.

Watching connections

The Database Health pane lists every live connection individually; user, host, database, command, how long it has been in its current state, and the query it is running. That list is where most real problems become visible: a connection stuck in Locked for four minutes, or fifty idle connections from an app that never closes them.

Any single connection can be ended from the pane. That is a real action against a real server, so it asks first.

"Why is it slow or stuck?"

This is the button worth knowing about. Rather than reading a slow-query log after the fact, it inspects the running server; what is executing right now, what is waiting on what, how full the connection pool is, and which queries have been sitting long enough to be the cause rather than a symptom. It returns findings ranked by severity, with the specific process behind each one.

Table trouble gets its own path: check tables and repair tables run the engine's own operations and report per-table results, so a corrupted table after an unclean shutdown is a two-click fix instead of a session in the shell.

Ask the AI Administrator

If the findings are unfamiliar, hand the whole thing to the assistant: "the database on the office server is slow, find out why." It reads the process list, the settings and the logs, and explains what it found. Read-only by default; it proposes changes and waits for you to approve them.

Where this lives in the app

Databases ▸ Database Health is the pane doing the work. Pick a target, and it lists every live connection, flags the ones worth worrying about, and; for MySQL and PostgreSQL; answers "why is this slow or stuck?" against the running server rather than guessing from a log.

Nothing here needs an agent installed on the database host. FrontierStack reaches a linked server over SSH using the key you already use, and reads through the database's own admin interfaces.

Set the alert before you need it

The useful moment for monitoring is the one before something breaks. Add the host in Fleet, point Database Health at it, and let the checks run on a schedule; a dead database reads as "no data", not "no problem", so an explicit alert is what turns a silent failure into a notification you actually receive.