OpenCoreDev Drops Domain SDK 0.2.0 – One TypeScript API to Manage Customer Domains Across Vercel, Cloudflare, Railway, Render, and Netlify
TL;DR: OpenCoreDev released Domain SDK 0.2.0 — a TypeScript library that gives you one unified API for Vercel, Cloudflare for SaaS, Railway, Render, and Netlify. If you run a SaaS that lets customers use custom domains, this saves you writing five different integrations (and the bugs that come with them).
Let’s be real: supporting custom domains in a SaaS product is painful. Vercel’s API is different from Netlify’s, which is different from Cloudflare for SaaS, Railway, and Render. Different payloads, different auth flows, different polling logic. The usual solution? Maintain five separate integrations and pray you catch every edge case.
Domain SDK 0.2.0 kills that repetition. It wraps all five providers behind a single TypeScript client with seven methods: add, get, refresh, list, verify, remove, and waitUntilActive. You write the workflow once; the adapter handles each provider’s quirks.
What Domain SDK Actually Does (and What It Doesn’t)
Before you dive in, get clear on the scope. The SDK does not register domains, host DNS, deploy apps, proxy traffic, or store tenant data. Your app keeps control of tenant authorization and state. The provider remains the source of truth. The SDK simply translates your generic domain instructions into each platform’s native API.
- Add – Register a custom hostname on the provider.
- Verify – Confirm ownership via DNS or HTTP challenge.
- Remove – Detach the hostname cleanly.
- WaitUntilActive – Poll until the domain is verified and TLS is ready.
The client is stateless and idempotent — retries are safe, and calling add again won’t cause side effects. Every method accepts an AbortSignal, so you control timeouts and cancellations.
The package runs server-side only (Node ≥20, Bun supported, ESM-only, one dependency — tldts). Credentials never reach browser code.
Why Malaysian SaaS Builders Should Care
If you’re running a bootstrapped SaaS in Malaysia — a booking platform, invoice tool, or e-commerce engine — you probably let customers bring their own domain. Every time you switch platforms (Vercel to Railway, or a new customer needs a subdomain), you end up diving into a different dashboard and manually checking DNS propagation. That’s time you should spend on your product, not on domain wrangling.
With Domain SDK, you build one “add domain” flow in your admin panel. The customer types their domain, you call add, the SDK returns the DNS records they need to set. Once they set them, verify and waitUntilActive handle the rest. Less context-switching, fewer late-night support tickets.
Each adapter is a separate entry point — ./vercel, ./cloudflare, ./railway, ./render, ./netlify. Changing platforms means changing one import line, not rewriting your deployment logic. That’s handy when you experiment with different hosting options without locking into one vendor.
Provider Support: Platform by Platform
Not every provider supports the same features. Rather than hard-coding assumptions, the SDK exposes a client.capabilities object you can read at runtime. Here’s the breakdown:
| Capability | Vercel | Cloudflare for SaaS | Railway | Render | Netlify |
|---|---|---|---|---|---|
| List domains | ✓ | ✓ | ✓ | ✓ | ✓ |
| Explicit verification | ✓ | — | — | ✓ | — |
| Managed certificates | ✓ | ✓ | ✓ | ✓ | ✓ |
| Apex domains | ✓ | — | ✓ | ✓ | ✓ |
| Wildcard domains | — | — | — | ✓ | — |
| Automatic customer DNS | — | — | — | — | — |
Key callouts: Cloudflare for SaaS requires a CNAME target, so it doesn’t support apex domains. Render is the only provider that accepts wildcard hostnames. No adapter edits customer DNS automatically — that’s up to you or your customers.
How Domain Status and DNS Records Work
DNS, ownership verification, and TLS certificates all finish at different times. The SDK models them separately with a DomainStatus union that has eight possible values: pending, pending_dns, pending_verification, pending_certificate, active, misconfigured, failed, and unknown.
Each Domain object also includes separate fields for verification (pending | verified | failed | unknown), certificate (pending | active | expiring | failed | unknown), and an issues array. Every issue has a code, message, optional record, and a retryable flag — so you know exactly what’s wrong and whether you can retry.
DNS records are typed the same way. A DnsRecord includes type, name, value, optional ttl, purpose, required, status, and an optional description. The purpose field tells you what the record is for — routing, ownership, certificate, or other. The status field shows pending, valid, invalid, or unknown.
For example, a Vercel hostname surfaces three distinct records:
| Type | Name | Purpose |
|---|---|---|
| CNAME | app.customer.com | routing |
| TXT | _vercel.app.customer.com | ownership |
| TXT | _acme-challenge.app.customer.com | certificate |
This means your integration code doesn’t have to guess why a domain isn’t working — the SDK tells you exactly what’s pending or broken.
Ready to Simplify Your Domain Workflow?
Domain SDK 0.2.0 is live on npm and ready to integrate into your project. If you’re building a SaaS product for Malaysian SMEs and want to cut down on integration overhead, this is a solid tool to try. Check it out and see how it fits your stack.