Transferring Domains Off Zeabur and Switching DNS: the 60-Day Lock, .tw Domains, URLs to Update

Domains bought on Zeabur need a transfer; domains only pointed at Zeabur need DNS changes. ICANN's transfer rules, whether Cloudflare accepts .tw, and the webhook and login URLs people forget to update.

Key points

  • Don't change registrant details before transferring: after a change, transfers to another registrar are blocked for 60 days.
  • Registrars must provide the auth code within 5 calendar days.
  • Cloudflare Registrar does not support .tw domains.
  • After switching, update chatbot webhooks, payment notification URLs, OAuth redirect URIs and CORS settings by hand.
How was this verified? (2 tested, 2 from official docs)
Tested ourselves
  • ICANN transfer restrictions and auth-code rules: checked against ICANN's official FAQ
  • .tw is not on Cloudflare Registrar's supported list: checked against Cloudflare's official TLD list (2026-10-17)
Written from official docs, not run ourselves
  • Zeabur's actual domain transfer screens: Zeabur announced self-service transfers, but its docs have no transfer steps yet, and we have no domain bought on Zeabur to test with
  • Whether Zeabur lets you change a domain's nameservers to an external provider: not documented; check in the dashboard
Contents (5 sections)
  1. First, which case are you?
  2. The day before: lower the TTL
  3. A. The domain was bought on Zeabur
  4. B. The domain only points at Zeabur
  5. URLs people most often forget after switching

First, which case are you?

  • A. The domain was bought on Zeabur: you need to transfer it to another registrar and change DNS
  • B. The domain was bought elsewhere (GoDaddy, Gandi, Cloudflare…) and only points at Zeabur: no transfer needed, just change the DNS records

The day before: lower the TTL

Set the TTL of the relevant DNS records to 300 seconds (5 minutes). Changes take effect faster after the switch, and if something goes wrong you can switch back quickly.

A. The domain was bought on Zeabur

Keep the site up first

According to the announcement, Zeabur has opened self-service domain transfers, but its docs don’t describe the transfer steps yet, and we have no domain bought on Zeabur to test with. The safer order is:

  1. If Zeabur’s domain settings let you change the nameservers, switch them to the two nameservers Cloudflare gives you (the free plan is enough) and recreate all DNS records in Cloudflare first. That way the site and email keep working even if the transfer stalls
  2. Then get the auth code and transfer the domain to the new registrar

If you can’t change the nameservers, start the transfer directly, and start early.

ICANN’s transfer rules (to avoid getting stuck)

From ICANN’s FAQ:

  • A registrar may refuse a transfer within 60 days of initial registration
  • It may also refuse within 60 days of a previous transfer
  • You cannot transfer to another registrar within 60 days of changing the registrant name. So don’t change the registrant name or email before transferring
  • Your registrar must provide the auth code (AuthInfo/EPP code) within 5 calendar days of your request

Where to transfer to

  • Cloudflare Registrar: renews at cost, but .tw is not on its supported list (we checked the official list on 10/17). For other domains, confirm support on the official list before starting
  • .tw and .com.tw: transfer to a registrar that handles .tw domains

B. The domain only points at Zeabur

At your DNS provider, replace the records that point at Zeabur with the values your new platform gives you:

New platformRecords you usually set
Cloudflare (frontends, static sites)Add a custom domain in Cloudflare; if the domain is already on Cloudflare, the records are created automatically
Cloud RunDepends on the method you choose; see the Cloud Run post
VPSAn A record pointing at the VPS IP

Delete the old Zeabur records so nothing keeps pointing at a place that disappears in December.

URLs people most often forget after switching

Once the domain or URL changes, these places do not update themselves:

  • LINE: LINE Developers → Messaging API → Webhook URL
  • Payments: payment result notification URLs and webhooks (Stripe, ECPay, NewebPay…)
  • Social login: authorized redirect URIs in Google Cloud Console and the Facebook developer dashboard
  • Frontend config: the API URL (for example VITE_API_URL) and the backend’s allowed CORS origins
  • Other webhooks: GitHub, Notion, form tools, n8n trigger URLs

After updating, trigger each one for real (send your bot a message, run a test payment) to confirm the new URL actually receives it.