Product details
The list, the wizard, and what each one is asking for
The mockup above is the saved address book — every row a database server that's been authenticated and probed. The cards below walk through the columns, the three-step wizard for adding a new entry, and why the whole list exists in the first place.
The list at the top
The page leads with the saved address book. Each row packs the user, the host:port, the engine and version, and a copy-able ID chip into one tidy block on the left — that's what someone in Slack will paste when they need to know exactly which server you mean. Role (SOURCE / HUB / TARGET) is the dial that tells the rest of Cupcake what to do with this entry, and Engine drives which driver and which schema-introspection queries Cupcake will use, because MySQL, MariaDB, and Percona genuinely diverge in how they expose system tables.
What 'healthy' actually means
The Status column is the result of the most recent read-only probe — a check that the host answers on the port, the credentials still work, and schema metadata can be read. The green ✓ and the 'last validated' timestamp are the two numbers worth a glance every morning. The pill at the top of the page rolls the count up: '2 HEALTHY' means both saved servers responded the last time the probe ran. When something flips, the count flips with it.
Step 1 — Connection
Click New connection and the wizard opens on the form that asks where the database lives and who Cupcake should be when it knocks. Role is three big tiles (Source / Hub / Target). Database engine is a six-tile grid — MySQL 5.7, MySQL 8, MariaDB 10, MariaDB 11, Percona 5.7, Percona 8 — because the driver and the introspection queries are different enough to matter. Host, port, user, password, and an optional Notes field round out the screen, with a quiet reminder underneath that credentials are encrypted at rest and never shown in plaintext again after save.
Step 2 — Validate
Cupcake runs a read-only visibility probe against the server you just entered. The card on this screen names the user@host being tested and ends with a single big 'Click to validate credentials' button. The wording on this screen matters: nothing is moved yet, no data leaves your database. The probe answers three questions — can we reach you, can we authenticate, and can we read your schema? — and stores a snapshot of the result so later steps don't have to ask again.
Step 3 — Confirm
Last screen is the save. Cupcake stores the encrypted credentials, the role, the engine, and the schema snapshot it just collected, then drops you back on the list. The new row joins the table with a fresh '0d ago' timestamp and a green ✓, ready for a plan or a job to grab. The whole loop from URL to ready usually takes about a minute.
Why save them at all
Every other page in Cupcake — Plans, Snapshots, Runs, Compare, Reconcile, CDC, Schedule — needs to know where the databases live. Without saved connections, every plan would re-type the host, every run would re-paste the password, and every operator would have a slightly different idea of what 'production' meant. The Connections list is the single source of truth: one row per server, validated, encrypted, role-stamped, and shared across the whole project.
Save once, point everywhere
A connection is the host, port, engine, user, and role you'd otherwise re-type into every plan. Save it once, and the rest of Cupcake — plans, snapshots, runs, comparisons, CDC streams — just references it by name.
Three steps from address to ready
Pick a role, pick an engine, fill in the host and credentials, watch a read-only probe knock on the door, confirm. The probe never moves data — it just answers 'are you reachable, will you let us read your schema?'
Healthy or not, at a glance
The list answers the morning question — which servers are still answering? — with a green ✓ and a 'last validated' timestamp. When something flips to unhealthy, the green pill in the header turns into a count of trouble worth chasing.
