One screen for every customer domain on your Fly.io apps

Build me an internal app called the customer domain desk. We onboard customers onto white-label custom domains on Fly.io, and today the only way to check whether a customer's domain is live is to run flyctl against each app, which means nobody in support can answer the question without pulling in an engineer. The people using this app are customer support and onboarding staff, not engineers, so the interface should read in plain language and avoid DNS jargon wherever it reasonably can.

The main view is a single table of every customer hostname we have across all of our Fly.io apps. Build it by calling List Apps for the organization and then List certificates for app for each app, then flattening the results into one list. Each row shows the customer hostname, which Fly app serves it, whether the certificate has been issued or is still waiting on the customer to finish their DNS setup, and how long it has been waiting, calculated from when the certificate was first requested. Sort so everything still waiting is pinned to the top, longest wait first, because those are the customers who are stuck right now. Issued and healthy domains sit below in a quieter section. Walking every app to build this list is a lot of calls and Fly rate limits per action at roughly one request per second, so load the list into app state once with a visible Refresh button and a last-updated timestamp rather than re-walking every app on each render.

Clicking any hostname opens a detail panel for that domain, fed by Get certificate details. The panel translates the certificate's validation state into a short plain-English answer to the question "what is this customer waiting on", and then shows exactly which DNS records the customer still needs to create, presented as a labelled record type, name and value with a copy button on each value so support can read them out or paste them into an email. Include a "Check DNS now" button wired to Check DNS and re-validate certificate so support can re-run validation live while on the phone with the customer, showing the result inline. Throttle that button: certificate authorities rate limit validation attempts, so allow at most one check per hostname per minute, disable the button with a short countdown after each attempt, and never let it be spammed.

Add an "Add a domain" form that takes the customer hostname and the Fly app that should serve it and calls Request ACME certificate. Add a Remove action on each row and in the detail panel that calls Remove certificate, for churned customers. Both sit behind a confirmation dialog that names the hostname being changed, and because removal is destructive the confirmation should make the user re-state the hostname before it proceeds. Fly bills roughly ten cents per hostname per month, so surface the waste angle too: show a count of certificates that have been sitting unissued for a long time, so the team has a concrete reason to clean up domains for customers who are long gone.

Add a "Draft customer instructions" button on the detail panel that kicks off a background agent for that hostname. The agent reads the certificate details and validation state for the domain, works out what is actually blocking issuance (the customer has not added the records at all, added them under the wrong name, pointed them at something else, or the records look correct and simply have not propagated yet), and writes plain-English setup steps aimed at that customer's DNS provider, using that provider's own wording where it can, for example Cloudflare, GoDaddy, Namecheap or Route 53. The output should be a short email-ready message the customer can follow without knowing what a certificate is. The agent writes its draft back into the app, stored against that hostname with a timestamp, and the panel shows the latest draft, whether the agent is currently running, and the previous draft while a new one is being written.

Support can edit the draft in the panel and then send it straight from the app using the Gmail Send a Message action, to a recipient address they type or one stored on the domain record. After sending, record who sent it and when against that hostname, and show that on the row in the main list so the next person can see the customer has already been told.

Keep the copy human throughout. Statuses should read like "Live" and "Waiting on customer" rather than raw certificate states, the stuck duration should read like "waiting 6 days", and any error coming back from Fly should be shown as a short explanation of what went wrong and what to try next, not a raw API error.