From GoDaddy to Cloudflare: How ijyalabs.in Is Hosted, Secured, and Deployed

ijyalabs.in is a Next.js static site served entirely from Cloudflare Pages — no origin server, no containers. The domain is registered at GoDaddy; nameservers are delegated to Cloudflare; a Cloudflare Worker handles backend API calls (contact form, consulting flows). A second domain, 2se1.com / 2se1.in, demonstrates a simpler variant of the same pattern: a pure DNS-level HTTP→HTTPS redirect through Cloudflare, with no build pipeline at all.

This article walks through each layer — DNS delegation, CI/CD, TLS, and security headers — with the actual configuration files used in production.

---

1. Domain Registration at GoDaddy, Nameservers at Cloudflare

The domain is purchased and renewed at GoDaddy. That is the extent of GoDaddy's involvement. The moment you point a domain's nameservers at Cloudflare, GoDaddy becomes a registrar only — it handles billing and WHOIS but no longer answers DNS queries.

In the Cloudflare dashboard, when you add a domain, Cloudflare gives you two nameservers:

server1.ns.cloudflare.com
server2.ns.cloudflare.com

Go to GoDaddy → Manage Domain → Nameservers → Enter Custom Nameservers, and paste those two values. Propagation takes minutes to a few hours. After that, Cloudflare owns the DNS plane entirely.

---

2. DNS Records: A / CNAME Strategy for Apex and www

The transitional GitHub Pages phase

Before Cloudflare Pages was the canonical host, DNS was temporarily pointed at GitHub Pages to allow preview of the static export before full migration. A script in the repo manages this transition via the GoDaddy API:

// scripts/godaddy-sync-dns.mjs

const githubPagesApexIps = [
  "185.199.108.153",
  "185.199.109.153",
  "185.199.110.153",
  "185.199.111.153",
];

const desired = [
  {
    type: "A",
    name: "@",
    records: githubPagesApexIps.map((ip) => ({ data: ip, ttl: 600 })),
  },
  {
    type: "CNAME",
    name: "www",
    records: [{ data: "your-account.github.io", ttl: 600 }],
  },
];

The script supports three modes: list (show current records), plan (preview changes), and apply (write changes live):

npm run dns:godaddy:plan   # dry run — show what would change
npm run dns:godaddy:apply  # write records to GoDaddy via API

Production: Cloudflare Pages as the host

Once on Cloudflare, DNS for ijyalabs.in and www.ijyalabs.in is managed in the Cloudflare dashboard. Cloudflare uses CNAME flattening at the apex — normally a CNAME cannot sit at the root of a zone; Cloudflare resolves it to A records at query time, transparently. Both apex and www resolve to Cloudflare's edge network, with no separate IP list to maintain.

---

3. The Build: Next.js Static Export

ijyalabs.in uses Next.js in static export mode (output: "export"). There is no SSR, no edge runtime for the site itself — the entire site is pre-rendered HTML, CSS, and JS, written to out/.

// next.config.ts
const nextConfig: NextConfig = {
  output: "export",
  trailingSlash: true,
  images: { unoptimized: true },
};

Cloudflare Pages picks up the out/ directory as specified in wrangler.toml:

# wrangler.toml
name = "ijyalabs-in"
pages_build_output_dir = "out"

A prebuild step generates downloadable PDFs before next build runs:

"scripts": {
  "prebuild": "node scripts/generate-pdfs.mjs",
  "build": "next build"
}

---

4. CI/CD: GitHub Actions → Cloudflare Pages

Two workflows handle the deployment pipeline.

4a. CI: Validate every push

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: ["main"]
  pull_request:

env:
  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run build

This runs lint, TypeScript type checking, and a full static build on every push to main and every pull request. It catches broken pages and type errors before anything reaches production.

4b. Cloudflare Pages auto-deploy (no workflow file needed)

Cloudflare Pages has a native GitHub integration. You connect the repository in the Cloudflare dashboard once; from then on, every push to main triggers a Cloudflare-managed build using the same pipeline. The out/ directory is deployed to Cloudflare's global CDN automatically.

4c. Worker deploy: explicit manual trigger

The backend Cloudflare Worker (contact form and consulting API) is deployed separately, on demand:

# .github/workflows/deploy-cloudflare-worker-contact-api.yml
name: Deploy Cloudflare Worker (contact-api)

on:
  workflow_dispatch:   # manual only

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          workingDirectory: workers/contact-api
          command: deploy

Secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID live in GitHub repository secrets — never in the codebase.

---

5. 2se1.com / 2se1.in — Pure DNS Redirect via Cloudflare

2se1.com and 2se1.in are shortlink domains with no build pipeline whatsoever. They redirect entirely at the DNS and proxy layer using Cloudflare's Redirect Rules.

The setup:

1. Add the domain to Cloudflare; point nameservers from the registrar.
2. In DNS, create an A record pointing to 192.0.2.1 (a discard IP — traffic never reaches it).
3. Enable the Cloudflare proxy (the orange cloud icon) on that A record.
4. In Cloudflare → Rules → Redirect Rules, create:

IF  hostname equals "2se1.com"
THEN redirect to "https://your-target-destination.com"  (301, Permanent)

Cloudflare intercepts the request at the edge before it ever touches an origin server. The dummy IP is never contacted. The TLS certificate, redirect response, and all header processing happen entirely inside Cloudflare's network. No server, no hosting cost beyond the domain registration.

This is the zero-infrastructure hosting model at its most extreme.

---

6. TLS Certificates and HTTPS

Cloudflare-issued certificates

For both ijyalabs.in and the shortlink domains, Cloudflare issues TLS certificates automatically via Universal SSL. Certificates cover the apex domain and a wildcard for all subdomains. Renewal is fully automatic.

TLS version policy: enforcing TLS 1.3

By default Cloudflare supports TLS 1.0 through 1.3 for maximum compatibility. For a site serving security-conscious customers, accepting TLS 1.0 or 1.1 is unacceptable — these versions have known weaknesses (POODLE, BEAST, and related attacks).

In the Cloudflare dashboard:

SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.3

The trade-off by setting:

For ijyalabs.in, TLS 1.3 is the right floor — the target audience is modern browsers and enterprise security professionals. TLS 1.2 is the pragmatic floor for 2se1.* redirect domains where compatibility matters more than posture.

TLS 1.3 advantages over 1.2:

• Removes RSA key exchange entirely; forward secrecy is mandatory
• 1-RTT handshake by default; 0-RTT resumption available for repeat visitors
• Smaller cipher suite list — no CBC modes, no RC4, no MD5 or SHA-1 PRF
• Encrypted handshake — the certificate exchange is hidden from passive observers

A note on 0-RTT: Cloudflare supports TLS 1.3 0-RTT, which allows a returning client to send data on the first flight with no handshake round-trip. The risk is that 0-RTT data can be replayed by a network attacker. Enable it only for idempotent GET paths. The Cloudflare Worker handles POST requests (contact form, API), so 0-RTT is kept off for Worker routes while remaining available for the static site.

---

7. HSTS: HTTP Strict Transport Security

Every response from ijyalabs.in includes:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

This is set in public/_headers, which Cloudflare Pages applies to every served response:

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Breaking this down:

• max-age=63072000 — two years (the minimum required by the HSTS preload list)
• includeSubDomains — all subdomains must also be HTTPS only
• preload — signals intent to be included in the browser-native HSTS preload list

The preload list is baked into Chrome, Firefox, Safari, and Edge. Once on it, browsers refuse to make any HTTP connection to ijyalabs.in even on the very first visit — there is no initial plaintext request that could be intercepted and downgraded.

Submitting to the preload list: visit hstspreload.org, enter the domain, and confirm. Removal from the list takes weeks and is intentionally difficult. Only enable preload if you are committed to HTTPS permanently on every subdomain.

---

8. Full Security Header Stack

The complete public/_headers file shipped with ijyalabs.in:

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  X-XSS-Protection: 1; mode=block
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Resource-Policy: same-origin

Each header's purpose:

---

9. DNS Record Types in Use

The CAA record is underused and undervalued. It tells certificate authorities: only Cloudflare is authorised to issue a certificate for this domain. Without it, any CA that accepts a standard domain validation challenge can issue a certificate for your domain. With CAA in place, a compromised or rogue CA cannot issue a certificate without violating the record, which compliant CAs are required to check before issuance.

---

10. End-to-End Request Flow

flowchart TD
    B([Browser]) -->|DNS query| NS[Cloudflare Nameservers]
    NS -->|Returns edge IP| EDGE[Cloudflare Edge]
    EDGE -->|TLS 1.3 handshake| TLS{Route}
    TLS -->|2se1 domains| REDIR[301 Redirect]
    TLS -->|ijyalabs.in| FW[DDoS / Firewall]
    FW --> PAGES[Cloudflare Pages\nStatic HTML from CDN]
    PAGES -->|_headers applied| RESP([Response:\nHSTS + hardened headers])

    B2([Browser]) -->|POST /api/contact| W[Cloudflare Worker\ncontact-api]
    W -->|OAuth refresh token| GMAIL[Gmail API]
    GMAIL --> EMAIL([Email delivered])

The Worker is deployed separately via Wrangler. Its secrets (OAuth tokens, API keys) live in Cloudflare's encrypted secret store, never in the repository or in wrangler.toml.

DNS zone structure

---

Summary

The result: no origin servers to patch, no containers to scale, no load balancers to configure — and a security posture that reaches A+ on the Mozilla Observatory out of the box.