Raw Server Domain Connector
Inspiration
I've hit this exact wall twice. Deploying to a raw VM — an AWS EC2 or Alibaba ECS instance, the kind of box that doesn't hand you HTTPS for free the way Google Cloud Run or AWS App Runner do — means logging into a registrar dashboard to point DNS at the box, then separately wiring up Let's Encrypt by hand for a free SSL certificate to get browser HTTPS and features like microphone/camera access.
Two dashboards, one manual DNS-01 dance, every time.
The name.com API is what makes that whole chain easy to automate in the first place — search, registration, and DNS management all live behind real endpoints instead of a dashboard you click through by hand. So instead of building another "search a domain" demo, I built the whole chain actually needed by a raw-server deployment: search → register → point an A record at the box → prove ownership to Let's Encrypt over DNS → walk away with a real certificate. The name is literal on purpose — this connects a raw server to a domain, full stop.
What it does
Raw Server Domain Connector is a Gradio app with three steps that chain into one pipeline:
- Search & Register — search name.com's sandbox across a keyword and a TLD list (or all TLDs), see live availability and pricing, and register a domain with one click. Sandbox by default, so this costs nothing and risks nothing to test. Not sure what to name your domain? An AI Suggest button uses an LLM to generate 15 creative domain name ideas from a plain English description of your app — just pick one from the dropdown and search it. Once you've chosen a domain, a Play Jingle button generates a custom 30-second promotional jingle for it using AI-written lyrics and MiniMax Music — a final confidence boost before committing to register, in case any last-minute doubts need resolving.
- Map to Server — take a domain (sandbox or a real one you own on name.com production) and create an A record pointing it at your server's IP, with the environment always explicit so a demo action can't accidentally touch the wrong zone.
- Secure with HTTPS — provision a real Let's Encrypt certificate via a genuine DNS-01
challenge: the app writes the
_acme-challenge(Automated Certificate Management Environment) TXT record through the name.com DNS API, polls the domain's real authoritative nameservers until it's visible, has Let's Encrypt validate it, and cleans up the TXT record afterward. The two resulting files —fullchain.pemandprivkey.pem— are downloadable directly from the UI, with a button to revoke them if necessary.
Every step shows live status, including the connection panel which verifies both sandbox and
production credentials against name.com's hello endpoint before the app touches anything else.
A collapsible Pipeline Log at the bottom of the page captures every name.com API request,
Let's Encrypt DNS-01 challenge step, and AI call in real time — including the exact nameservers
polled for TXT propagation and per-operation timings.
How I built it
Everything is grounded directly in name.com's own OpenAPI spec (namecom.api.yaml) as the source of truth.
The pipeline touches seven distinct name.com endpoints across two environments:
Hello, Search, CheckAvailability, CreateDomain, ListRecords, CreateRecord, and
DeleteRecord.
Architecture is 10 single-responsibility Python modules — name_client.py, acme_hooks.py, acme_client.py, pipeline.py, llm.py, jingle.py, config.py, time_it.py, util.py, app.py — with Gradio's callbacks doing nothing but calling into pipeline.py, llm.py, and jingle.py. No separate backend server: Gradio runs the UI and the backend in the same async process.
A few specific decisions that mattered:
- 429 handling reads the actual header. The name.com OpenAPI spec says a 429 response carries an
x-ratelimit-resettimestamp — the client reads it and backs off to that exact time instead of guessing a delay. - Certbot in manual-hook mode, not a hand-rolled ACME client. Certbot is the standard
open-source tool for requesting Let's Encrypt certificates; its
certonly --manual --preferred-challenges dnsmode runs auth/cleanup hooks that shell out to the name.com API — the same mechanism people use for any registrar without an official certbot plugin — and it meant relying on a well-tested implementation of the ACME protocol (order → authorize → respond → finalize) instead of writing one from scratch. - DNS-01 polls real authoritative nameservers, not a public resolver and not a fixed sleep.
acme_hooks.pyqueries name.com's own nameservers directly viadnspythonuntil the TXT record is actually visible before letting certbot proceed. - Two real environments, on purpose. Sandbox zones aren't publicly resolvable, so a DNS-01 challenge can never succeed against one — there's no way around registering a real production domain if the certificate at the end is going to be genuine instead of simulated. That real domain registered on name.com is what the whole SSL step runs against.
- AI features are powered by Qwen3 30B via Nebius Token Factory — used for both domain name suggestions and jingle lyrics. Jingle audio is produced by MiniMax Music 3.0 via GMI Cloud, an AI music model licensed for commercial use.
Challenges I ran into
- Sandbox vs. reality. name.com's sandbox is genuinely free and safe, but its zones don't resolve publicly — meaning the SSL leg of the pipeline can only ever be demoed for real against a real production domain. Designing the app to make that boundary explicit (rather than faking a "simulated" certificate) took longer to get right but is the difference between a toy and something that actually proves the integration works.
- Let's Encrypt staging occasionally returns a transient "Service busy" before certbot ever reaches the DNS-01 hook at all. Worth a narrow, explicit retry — not a blanket "retry everything," since a genuine validation failure would just fail again identically.
Accomplishments that I'm proud of
The pipeline isn't simulated anywhere. A real domain was searched, registered, and had its A record created and deleted against name.com's live production API. A real Let's Encrypt certificate was issued end-to-end — DNS-01 challenge written and verified through name.com's own DNS, certificate downloaded, certificate revoked — against a domain I actually own. The SSL step requires a real production domain because sandbox zones aren't publicly resolvable and a DNS-01 challenge can only succeed against a domain that exists in public DNS. Nothing here is a mockup.
How fast is it in practice?
A full end-to-end run was timed against the live APIs:
- Connection check (sandbox + production
hello): ~0.8s each - AI domain name suggestions (Qwen3 30B on Nebius): ~1s warm
- Domain search (name.com sandbox): ~1s
- Domain registration (availability check + create): ~3s total
- A record creation: <1s
- SSL certificate provisioning (certbot + DNS-01 + Let's Encrypt staging): ~13s
- Certificate revocation: ~1s
- DNS record deletion: <1s
- AI jingle generation (lyrics + MiniMax Music audio): ~43s warm
The entire pipeline from search to signed certificate completes in well under a minute against real APIs with no mocking. The SSL step — which involves spawning certbot, creating a DNS TXT record, polling authoritative nameservers, and completing a full ACME DNS-01 challenge with Let's Encrypt — finished in 13 seconds on the deployed instance.
What I learned
Reading the actual name.com OpenAPI spec caught details that mattered: the exact shape of the 429
rate-limit header, which endpoints were deprecated, the minimum DNS TTL, and what a 404
on CreateRecord actually means. Details like that are the difference between code that works
consistently and code that breaks the first time something doesn't go perfectly.
What's next
Gradio can expose this exact pipeline as a real MCP server — turning "search, register, map, secure" into tools any MCP-compatible agent could call directly, headless, no browser required. That's the natural next step for a pipeline that's already just a series of pure async functions underneath the UI.
Try it out live
Domain registration, DNS record creation, and SSL provisioning are all live. The SSL step runs against a real production domain registered on name.com.
Log in or sign up for Devpost to join the conversation.