Prompt: put a local app on the internet at your own domain

Have an agent expose something running on your machine (a dev server, a demo, a webhook receiver, a home service) at https://<hostname> through an ird HTTPS tunnel — DNS and TLS handled — with a proper offline page and a clean teardown so you don't keep paying for a demo you finished.

Needs: the ird CLI logged in on the machine that runs the app (the MCP server can create the tunnel, but the forwarding process runs where the app is); a hostname on a zone hosted on ird DNS Costs: hourly while the tunnel exists (credits_prices → recurring.tunnel-hourly), plus per MB stored for a custom offline page Group: hosting

Paste everything below the line into a fresh conversation. Fill in the FILL IN block first.

Task

Make the local port below reachable at https://HOST, keep it connected while I need it, show a decent page when it isn't, and tear it down when I say so.

FILL IN

HOST:          demo.example.ro     # hostname on a zone hosted on ird DNS
PORT:          3000                # local port the app listens on
OFFLINE_PAGE:  ./offline           # folder with an index.html shown while offline, or "standard"
AUTH:          the app has its own login   # what protects it once public (be honest)

Non-negotiable rules

1. Public means public. Before creating the tunnel, restate AUTH. If PORT serves an admin panel, a database UI, or anything without authentication, say so plainly and wait for my explicit go.
2. Hourly billing until deleted. Stopping the forwarding (ird tunnels stop) does not stop billing; only delete does. Tell me the hourly and monthly figure from credits_prices before creating.
3. One tunnel per hostname. list_tunnels first; if HOST already has one, reuse it — don't create a duplicate.
4. Never expose a port that isn't listening. Check curl -sI http://127.0.0.1:PORT (or lsof -i :PORT) first.

Steps

A. Preflight. dns_list_zones must include HOST's zone (otherwise stop: register-domain / bring-domain-dns prompts). list_tunnels for an existing tunnel on HOST. Local port check as in rule 4.

B. Create + connect. On the machine running the app:

ird tunnel HOST PORT

It creates the tunnel, writes the DNS record on the ird-hosted zone, and starts forwarding; the certificate is issued on first request. Keep the process running (or use ird agent — the background helper that keeps tunnels connected across restarts; ird agent --help). From an MCP-only session, create_tunnel(hostname=HOST, ssh_public_key=<key of the device>) returns the ssh_command that device must run instead — relay it to me verbatim.

C. Verify. list_tunnels → HOST status active (pending-dns means the record isn't visible yet: wait a minute; degraded means the forwarder dropped). Then from outside: curl -sI https://HOST returns the app's headers. If the zone is not on ird DNS, the create result's DNS target must be set manually and re-checked with ird tunnels verify HOST.

D. Offline page. If OFFLINE_PAGE is a folder: tunnel_set_offline(tunnel=HOST, path=<absolute folder>) (CLI: ird tunnel offline HOST ./offline). It is packed, pinned and served automatically whenever the forwarder is not connected; re-run after editing (the old copy stops billing). Test it: stop forwarding for a moment, curl https://HOST shows the page, start again. standard: skip.

E. Teardown (when I say "done"). delete_tunnel(tunnel_id) from list_tunnels (CLI: ird tunnels delete HOST). Billing stops immediately and the DNS record goes with it. If an offline page was set, its pin is removed with the tunnel — confirm with ipfs_pins.

Deliverable

https://HOST, the tunnel id, its status, the command that keeps it connected, hourly/monthly cost, the offline page CID if any, and the one-line teardown command.