17 ਦਸੰ 2025·8 ਮਿੰਟ

ਵੈੱਬ ਐਪ ਲਈ ਕਸਟਮ ਡੋਮੇਨ ਸੈਟਅਪ: DNS, SSL, ਅਤੇ Cutover

Q: Should my main site be on the apex domain or on www?

Default to one canonical hostname and redirect everything else to it. - Choose either (apex) or as the “real” one. - Treat the other as a single 301 redirect. This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.

Q: When should I lower DNS TTL before switching domains?

Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out. - Common cutover TTL: 300–600 seconds - After the move is stable: raise TTL back up (often 1–4 hours ) Only lower TTL on the records you’re actually going to change.

Q: What DNS record should I use: A, CNAME, or ALIAS?

For many app setups: - Use CNAME for subdomains like or when you’re pointing to a provider hostname. - Use A (or ALIAS/ANAME if your DNS supports it) for the apex . Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.

Q: Do I need SSL ready before I change DNS?

Don’t switch user traffic until HTTPS is valid on the new hostname(s) . A practical order: - Add the domain in your host/platform (for example, in Koder.ai custom domain settings) - Complete domain verification (often via TXT) - Wait until the certificate is issued for every hostname you’ll serve - Only then update DNS to send real users there This avoids browser warnings and blocked requests right at cutover.

Q: What auth and SSO settings do I need to update after a domain change?

Update identity settings before cutover. Typical items that must match the new domain exactly: - OAuth/SSO redirect (callback) URLs - Allowed origins / CORS settings - Any allowlisted logout URLs If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.

ਵੈੱਬ ਐਪ ਲਈ ਕਸਟਮ ਡੋਮੇਨ ਸੈਟਅਪ — ਸਪਸ਼ਟ DNS ਰਿਕਾਰਡ ਸਟੈਪ, SSL ਜਾਰੀ ਕਰਨ, ਰੀਡਾਇਰੈਕਟਸ ਅਤੇ ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਵਾਲੇ cutover ਲਈ ਘੱਟ-ਖਤਰਾ ਯੋਜਨਾ।

ਕਸਟਮ ਡੋਮੇਨ ਨਾਲ ਕੀ ਬਦਲਦਾ ਹੈ (ਅਤੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ)

ਕਸਟਮ ਡੋਮੇਨ ਸਿਰਫ਼ ਇੱਕ ਸੋਹਣਾ URL ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਪਤੇ (ਜਿਵੇਂ Koder.ai ਦੇ ਅਧੀਨ ਇੱਕ ਅਪਲਿਕੇਸ਼ਨ) ਤੋਂ ਆਪਣੀ ਆਪਣੀ ਡੋਮੇਨ ‘ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਨੈੱਟਵਰਕ ਇਸਨੂੰ ਇਕ ਵੱਖਰੇ ਸਾਈਟ ਵਜੋਂ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ। ਇਸਦਾ ਅਸਰ ਰਾਊਟਿੰਗ, ਸੁਰੱਖਿਆ, ਅਤੇ ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਕਸਟਮ ਡੋਮੇਨ ‘ਤੇ ਸਵਿੱਚ ਕਰਦੇ ਹੋ ਤਾਂ ਕੁਝ ਚੀਜ਼ਾਂ ਤੁਰੰਤ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ:

DNS ਰਾਊਟਿੰਗ: ਯੂਜ਼ਰਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਪੁਰਾਣੇ ਹੋਸਟਨੇਮ ਤੋਂ ਰੁਕਕੇ ਉਸ ਨਵੀਂ ਟਾਰਗਟ ‘ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ DNS ਵਿੱਚ ਲਿਖਦੇ ਹੋ।
TLS/SSL: ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਨਵੇਂ ਹੋਸਟਨੇਮ(ਸ) ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਯੂਜ਼ਰਾਂ ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਐਕਟਿਵ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ।
ਰੀਡਾਇਰੈਕਟਸ: ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਯੂਜ਼ਰ www ਤੇ ਆਉਣਗੇ ਜਾਂ apex ਡੋਮੇਨ ਤੇ, ਅਤੇ HTTP ਤੋਂ HTTPS ਨਿਯਮ ਸਹੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਕੁਕੀਆਂ ਅਤੇ ਸੈਸ਼ਨ: ਕੁਕੀਆਂ ਡੋਮੇਨ ਤੇ ਆਧਾਰਤ ਹੁੰਦੀਆਂ ਹਨ। old-platform.example ਦੀ ਲੋਗਿਨ ਕੁਕੀ ਆਪਣੇ-ਆਪ ਹੀ app.yourdomain.com ‘ਤੇ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ।
ਕੇਸ਼ਿੰਗ ਅਤੇ ਪ੍ਰੋਪੇਗੇਸ਼ਨ: DNS ਰੀਜ਼ੋਲਵਰ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਨਤੀਜੇ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਹਰ ਕੋਈ ਇੱਕੋ ਸਮੇਂ ਸਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ।

ਛੋਟੀ ਡਾਊਨਟਾਈਮ ਆਮ ਤੌਰ ‘ਤੇ ਟਾਈਮਿੰਗ ਕਾਰਨ ਹੁੰਦੀ ਹੈ। DNS ਪਹਿਲਾਂ ਨਵੀਂ ਹੋਸਟ ਨੂੰ ਟ੍ਰੈਫਿਕ ਭੇਜ ਸਕਦਾ ਹੈ ਪਰ SSL ਤਿਆਰ ਨਹੀਂ ਹੁੰਦਾ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਉਜ਼ਰ ਚੇਤਾਵਨੀ ਆ ਸਕਦੀ ਹੈ। ਜਾਂ ਵਿਰੋਧੀ ਘਟਨਾ: SSL ਤਿਆਰ ਹੈ ਪਰ DNS ਕੈਸ਼ ਕਾਰਨ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਪੁਰਾਣੇ ਸਥਾਨ ‘ਤੇ ਹੀ ਜਾ ਰਹੇ ਹਨ।

ਰੀਡਾਇਰੈਕਟਸ ਵੀ ਲੌਗਿਨ ਨੂੰ ਸੁਖਾਵਟੇ ਤਰੀਕੇ ਨਾਲ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਰੀਡਾਇਰੈਕਟ ਹੋਸਟਨੇਮ ਬਦਲਦਾ ਹੈ (apex ਤੋਂ www ਜਾਂ ਉਲਟ), ਤਾਂ ਕੁਕੀ ਡ੍ਰਾਪ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਉਹ ਦੂਜੇ ਹੋਸਟ ਲਈ ਸੀਟ ਕੀਤੀ ਗਈ ਸੀ। ਆਥ ਪ੍ਰੋਵਾਈਡਰ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਉਹਨਾਂ ਦੀ callback URL ਪੁਰਾਣੀ ਡੋਮੇਨ ਤੇ ਹੀ ਹੋਵੇ।

ਏਕ ਨਿਯਮ: ਇੱਕ low-risk cutover ਵਿੱਚ overlap ਪਲਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਪੁਰਾਣੀ URL ਚੱਲਦੀ ਰਹੇ, ਨਵੀਂ ਡੋਮੇਨ ਪੈਰੈਲੇਲ ਉੱਪਰ ਆਵੇ, ਫਿਰ ਇੱਕ ਪੂਰੇ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟ ਕੀਤਾ ਜਾਵੇ ਅਤੇ rollback ਸਧਾਰਨ ਹੋਵੇ (DNS ਨੂੰ ਵਾਪਸ ਕਰਨਾ)।

DNS ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਡੋਮੇਨ ਅਤੇ ਹੋਸਟਨੇਮ ਫੈਸਲ ਕਰ ਲਵੋ

ਕੋਈ ਵੀ ਚੀਜ਼ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨਾਮਾਂ ਨੂੰ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਟਾਈਪ ਕਰਵਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਉਹਨਾਂ ਨਾਮਾਂ ਨੂੰ ਜੋ ਚੁੱਪ-ਚਾਪ ਰੀਡਾਇਰੈਕਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ “ਆਧੇ-ਕਾਮ ਕਰ ਰਹੇ” ਮਾਮਲੇ ਇਸ ਕਰਕੇ ਹੁੰਦੇ ਹਨ ਕਿ ਟੀਮ ਇੱਕ ਸੱਚੇ ਹੋਸਟਨੇਮ 'ਤੇ ਇਕੱਠੀ ਸਹਿਮਤੀ ਨਹੀਂ ਬਣਾਂਦੀ।

ਬੜੀ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: apex (example.com) ਜਾਂ www (www.example.com) ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਬਣਾਉਣਾ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਚੁਣੋ ਅਤੇ ਦੂਜੇ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਸਮਝੋ। ਇਹ ਕੁਕੀਆਂ ਲਈ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੈ: ਜਦੋਂ ਐਪ ਇਕ ਸਥਿਰ ਹੋਸਟ 'ਤੇ ਰਹੇ ਤਾਂ ਸੈਸ਼ਨ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।

ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਸੋਚੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੇ ਸਬਡੋਮੇਨ ਲੋੜੀਂਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਬਾਅਦ ਵਿੱਚ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਆਮ ਤੌਰ ‘ਤੇ app.example.com ਵੈੱਬ ਐਪ ਲਈ ਅਤੇ api.example.com API ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ‘ਤੇ ਕਸਟਮ ਡੋਮੇਨ ਸੈਟ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਚੋਣਾਂ SSL ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ DNS ਪਾਇਂਟਿੰਗ ਨਾਲ ਸਿੱਧੇ ਜੁੜਦੀਆਂ ਹਨ।

ਜਾਣੋ ਕਿ ਅਸਲ ਵਿੱਚ DNS ਕਿਸਦੇ ਕੋਲ ਹੈ

ਕਈ ਵਾਰੀ ਡੋਮੇਨ ਰਜਿਸਟਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਰ DNS ਕਿਤੇ ਹੋਰ ਤੇ ਹੋਸਟ ਹੁੰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਕਾਰਡ ਅੱਜ ਕਿੱਥੇ ਸੋਧੇ ਜਾਂਦੇ ਹਨ, ਕਿਸਦੇ ਕੋਲ ਐਕਸੈੱਸ ਹੈ, ਅਤੇ ਕੋਈ ਆਟੋਮੇਸ਼ਨ (ਕੰਪਨੀ IT, ਏਜੰਸੀ, ਜਾਂ ਮੈਨੇਜਡ DNS ਪ੍ਰੋਵਾਇਡਰ) ਤਾਂ ਨਹੀਂ ਚਲਾ ਰਹੀ। ਜੇ ਤੁਸੀਂ ਲੌਗਿਨ ਕਰਕੇ ਮੌਜੂਦਾ ਰਿਕਾਰਡ ਨਹੀਂ ਵੇਖ ਸਕਦੇ ਤਾਂ ਪਹਿਲਾਂ ਇਹ ਠੀਕ ਕਰੋ।

ਡੋਮੇਨ ਦਾ ਜੋ ਪਹਿਲਾਂ ਵਰਤੋਂ ਚੁੱਕਾਇਆ ਹੋਇਆ ਹੈ ਉਹ ਵੀ ਆਡਿਟ ਕਰੋ। ਈਮੇਲ ਸਭ ਤੋਂ ਵੱਡਾ ਫੰਦਾ ਹੈ: ਰਿਕਾਰਡ ਹਟਾ ਕੇ ਜਾਂ ਓਵਰਰਾਈਟ ਕਰ ਕੇ ਤੁਸੀਂ ਮੇਲ ਡਿਲਿਵਰੀ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹੋ।

ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲੇ ਲਿਖੋ:

ਪ੍ਰਾਇਮਰੀ ਹੋਸਟਨੇਮ (apex ਜਾਂ www) ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਦਿਸ਼ਾ
ਹੁਣ ਲੋੜੀਂਦੇ ਸਬਡੋਮੇਨ (app, api, admin) ਅਤੇ ਬਾਅਦ ਦੇ ਲਈ ਵਿਚਾਰ
DNS ਕਿੱਥੇ ਹੋਸਟ ਹੈ ਅਤੇ ਕੌਣ ਬਦਲਾਅ ਕਰ ਸਕਦਾ ਹੈ
ਮੌਜੂਦਾ ਮਹੱਤਵਪੂਰਕ ਰਿਕਾਰਡ (MX, SPF, DKIM, DMARC, verification TXT)
ਕੁਕੀ ਅਤੇ ਆਥ ਉਮੀਦਾਂ (ਇੱਕ ਹੀ ਹੋਸਟ ਜਾਂ ਸਬਡੋਮੇਨ 'ਤੇ ਸਾਂਝਾ)

ਜੇ ਮਾਰਕੀਟਿੰਗ ਪਹਿਲਾਂ ਹੀ example.com ‘ਤੇ ਈਮੇਲ ਚਲਾ ਰਹੀ ਹੈ, ਤਾਂ ਮੇਲ-ਸਬੰਧੀ ਰਿਕਾਰਡ ਨੂੰ ਬਿਨਾਂ ਛੋੜੇ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਐਪ ਲਈ ਲੋੜੀਂਦੇ ਨਵੇਂ ਰਿਕਾਰਡ ਜੋੜੋ।

ਤੁਹਾਡੀ ਵਰਤੋਂ ਵਾਲੇ DNS ਰਿਕਾਰਡ ਅਤੇ ਉਹ ਕਿਉਂ ਮੁੱਖ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਰਿਸਕ ਇੱਕ ਗਲਤ DNS ਬਦਲਾਉ ਹੈ: ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਖਾਲੀ ਜਗ੍ਹਾ ਨੂੰ ਜਾ ਸਕਦਾ ਹੈ, ਈਮੇਲ ਟੁੱਟ ਸਕਦੀ ਹੈ, ਜਾਂ SSL ਵੈਰਿਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

ਮੁੱਢਲੇ ਰਿਕਾਰਡ (A, CNAME, ਆਦਿ)

A record ਇੱਕ ਨਾਮ ਨੂੰ IP ਪਤੇ ‘ਤੇ ਜੋੜਦਾ ਹੈ — ਸਿੱਧਾ “ਲੋਕਾਂ ਨੂੰ ਇਸ ਸਰਵਰ ਤੇ ਭੇਜੋ”। ਇਹ ਆਮ ਤੌਰ ‘ਤੇ apex (example.com) ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਵਾਇਡਰ ਨੇ ਇੱਕ ਫਿਕਸਡ IP ਦਿੱਤਾ ਹੈ।

CNAME record ਇੱਕ ਨਾਮ ਨੂੰ ਦੂਜੇ ਨਾਮ ਦੇ ਨਾਲ ਜੋੜਦਾ ਹੈ — “ਇਸ ਨਾਮ ਨੂੰ ਉਸ ਹੋਸਟਨੇਮ ਵਜੋਂ ਮੰਨੋ”। ਇਹ ਆਮ ਤੌਰ www.example.com ਨੂੰ ਪਲੇਟਫਾਰਮ ਹੋਸਟਨੇਮ ਵੱਲ ਪਾਇੰਟ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਕਈ DNS ਪ੍ਰੋਵਾਇਡਰ ALIAS/ANAME ਵੀ ਦਿੰਦੇ ਹਨ ਜੋ apex ਲਈ CNAME ਵਰਗਾ ਹоведਾ ਕਰਦਾ ਹੈ ਪਰ apex 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਵਾਇਡਰ ਇਸਨੂੰ ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ IPs ਨੂੰ ਹੱਥ ਨਾਲ ਬਦਲਣ ਦੀ ਲੋੜ ਘਟਾ ਦਿੰਦਾ ਹੈ।

ਸਰਲ ਮੋਡਲ:

A: name -> IP (ਡਾਇਰੈਕਟ)
CNAME: name -> name (ਅਲਿਆਸ)
TXT: name -> text (ਪ੍ਰੂਫ਼ ਅਤੇ ਨੀਤੀ)
MX: name -> mail servers (ਅਜੇ ਤੱਕ ਹੱਥ ਨਾ ਲਾਓ ਜੇ ਮਤਲਬ ਨਾ ਹੋਵੇ)

TXT ਰਿਕਾਰਡ: ਵੈਰੀਫਿਕੇਸ਼ਨ, SSL, ਅਤੇ ਈਮੇਲ ਸੁਰੱਖਿਆ

ਤੁਸੀਂ ਅਕਸਰ TXT ਰਿਕਾਰਡ domain ownership ਚੈੱਕ ਲਈ, ਅਤੇ SSL ਸਰਟੀਫਿਕੇਟ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਜੋੜੋਗੇ। TXT SPF ਜੇਹੜਾ ਈਮੇਲ ਨੀਤੀ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਮੌਜੂਦਾ SPF ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਡਿਲੀਟ ਜਾਂ ਰੀਪਲੇਸ ਕਰਨਾ ਮੇਲ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ।

TTL: ਤੁਹਾਡਾ “ਬਦਲਣ ਦੀ ਰਫਤਾਰ” ਨਾਬ

TTL ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਹੋਰ ਸਿਸਟਮ ਤੁਹਾਡੇ DNS ਜਵਾਬ ਨੂੰ ਕਿੰਨੀ ਦੇਰ ਕੈਸ਼ ਕਰਨਗੇ। Cutover ਤੋਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ TTL ਘਟਾਓ (ਆਮ ਤੌਰ ਤੇ 300–600 ਸਕਿੰਟ)। ਸਭ ਕੁਝ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ TTL ਵਾਪਸ ਵਧਾ ਦਿਓ ਤਾਂ ਕਿ ਸਰਵਰ ਲੋਡ ਘਟੇ।

ਮੌਜੂਦਾ ਰਿਕਾਰਡਾਂ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਪਹੁੰਚਾਓ, ਅਤੇ ਰੋਲਬੈਕ ਡੌਕਯੂਮੈਂਟ ਕਰੋ

ਸੋਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ zone ਦਾ ਐਕਸਪੋਰਟ ਜਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਲੈ ਲੋ। ਹਰ ਰਿਕਾਰਡ ਜੋ ਤੁਸੀਂ ਬਦਲੋਗੇ ਉਸਦਾ ਪੁਰਾਣਾ ਅਤੇ ਨਵਾਂ ਮੁੱਲ ਲਿਖੋ ਅਤੇ TTL ਦਰਜ ਕਰੋ। ਗਲਤ ਹੋਣ ‘ਤੇ ਰੋਲਬੈਕ ਮਤਲਬ ਪਹਿਲੇ ਮੁੱਲ ਨੂੰ ਵਾਪਸ ਰੱਖਣਾ ਹੈ।

ਇਹ ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਡੋਮੇਨਾਂ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਜਿਨ੍ਹਾਂ ‘ਤੇ ਪਹਿਲਾਂ ਤੋਂ MX, DKIM ਜਾਂ ਹੋਰ TXT ਰਿਕਾਰਡ ਹਨ।

SSL ਜਾਰੀ ਕਰਨ: ਵੈਰੀਫਿਕੇਸ਼ਨ, ਟਾਈਮਿੰਗ, ਅਤੇ ਕਵਰੇਜ

SSL (ਲੌਕ ਆਈਕਨ) ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ APIs ਹੀ HTTPS ਉਮੀਦ ਕਰਦੇ ਹਨ। ਬਿਨਾਂ ਇਸ ਦੇ ਚੇਤਾਵਨੀਆਂ, ਅਵਰੋਧ ਅਤੇ ਕੁਝ ਫੀਚਰ ਕੰਮ ਨਹੀਂ ਕਰਨਗੇ।

CA ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਲਈ ਇਹ ਪੂਰਾ ਵਿਸ਼ਵਾਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਡੋਮੇਨ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ। ਆਮ ਤਰੀਕੇ ਹਨ HTTP ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ DNS TXT ਵੈਰੀਫਿਕੇਸ਼ਨ:

HTTP validation: ਅਲਗ URL ਤੇ ਅਥਵਾ ਫਾਇਲ ਰਸਪਾਂਸ ਰੱਖ ਕੇ ਸਾਬਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
DNS TXT validation: DNS ਜ਼ੋਨ ਵਿੱਚ ਇੱਕ TXT ਟੋਕਨ ਜੋੜ ਕੇ ਵੈਰੀਫਾਇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

Jਦੋਂ CDN ਜਾਂ ਤੁਹਾਡੀ ਐਪ ਨਵੀਂ ਡੋਮੇਨ 'ਤੇ ਸਿੱਧੇ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ DNS validation ਅਕਸਰ ਆਸਾਨ ਰਹਿੰਦੀ ਹੈ।

ਸਰਟੀਫਿਕੇਟ ਕਿੱਥੇ ਜਾਰੀ ਹੁੰਦਾ ਹੈ ਇਹ ਤੁਹਾਡੇ ਸੈਟਅਪ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਕੁਝ ਟੀਮ ਸਰਟੀਫਿਕੇਟ ਆਪਣੇ ਹੋਸਟਿੰਗ ਸਟੈਕ 'ਤੇ ਜਾਰੀ ਕਰਦੀਆਂ ਹਨ, ਕੁਝ CDN 'ਤੇ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਪਲੇਟਫਾਰਮ (ਜਿਵੇਂ Koder.ai) ਕਸਟਮ ਡੋਮੇਨ ਸਮਰਥਨ ਦੌਰਾਨ ਇਹ ਸੰਭਾਲ ਲੈਂਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਣ Gall ਇਹ ਹੈ ਕਿ ਸਪਸ਼ਟ ਹੋਵੇ ਕੌਣ ਸਰਟੀਫਿਕੇਟ ਲਾਈਫਸਾਈਕਲ (ਜਾਰੀ/renewal) ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰੱਖਦਾ ਹੈ।

ਟਾਈਮਿੰਗ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼

ਸਰਟੀਫਿਕੇਟ ਤੁਰੰਤ ਮਿਲ ਨਹੀਂ ਸਕਦੇ। DNS ਪ੍ਰੋਪੇਗੇਸ਼ਨ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈੱਕ, ਅਤੇ ਰੇਟ ਲਿਮਿਟਸ ਕਾਰਨ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਰੀਟ੍ਰਾਈ ਅਤੇ cutover ਨੂੰ ਆਖਰੀ ਪਲ ਤੇ ਨਾ ਰੱਖੋ।

ਅਮਲੀ ਟਾਈਮਿੰਗ ਯੋਜ਼ਨਾ:

Cutover ਤੋਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ TTL ਘਟਾਓ ਤਾਂ ਕਿ ਬਦਲਾਅ ਤੇਜ਼ ਲਾਗੂ ਹੋ ਜਾਵੇ।
validation ਰਿਕਾਰਡ ਜਲਦੀ ਜੋੜੋ (DNS TXT ਜਾਂ HTTP ਟੋਕਨ)।
ਉਡੀਕ ਕਰੋ ਕੀ ਸਰਟੀਫਿਕੇਟ ਸਾਰੇ ਹੋਸਟਨੇਮ ਲਈ ਜਾਰੀ ਹੋ ਗਿਆ ਹੈ।
ਫਿਰ ਹੀ ਟ੍ਰੈਫਿਕ ਨਵੀਂ ਟਾਰਗਟ ਵੱਲ ਪਾਇੰਟ ਕਰੋ।

ਕਵਰੇਜ: ਯਕੀਨੀ ਬਣਾਓ ਸਹੀ ਹੋਸਟਨੇਮ ਸ਼ਾਮਲ ਹਨ

ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਹਰ ਉਸ ਹੋਸਟਨੇਮ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ 'ਤੇ ਯੂਜ਼ਰ ਆ ਸਕਦੇ ਹਨ। SAN ਲਿਸਟ (Subject Alternative Names) ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਦੋਹਾਂ example.com ਅਤੇ www.example.com 'ਤੇ ਉਪਲਬਧ ਹੋਵੇਗੀ, ਤਾਂ ਦੋਹਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।

Wildcard (*.example.com) ਕਈ ਸਬਡੋਮੇਨਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ apex (example.com) ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ।

ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ ਸਿਰਫ www.example.com ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਜੋ ਯੂਜ਼ਰ example.com ਟਾਈਪ ਕਰਨਗੇ ਉਹ ਚੇਤਾਵਨੀ ਦੇਖਣਗੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ ਥੰਕ ਲੇਅਰ ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਨਹੀਂ ਰੱਖਦੇ ਜਿਸਦੇ ਕੋਲ example.com ਲਈ ਵੀ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਹੋਵੇ।

ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ: www, apex, HTTP ਤੋਂ HTTPS, ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ

Choose the right plan

Pick a plan that fits your launch, from free to enterprise, as your traffic grows.

Upgrade Tier

ਰੀਡਾਇਰੈਕਟਸ ਸਾਦੇ ਲੱਗਦੇ ਹਨ ਪਰ ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਸਮੱਸਿਆਵਾਂ ਇੱਥੇ ਆਉਂਦੀਆਂ ਹਨ: ਲੂਪ, ਮਿਕਸਡ ਕੰਟੈਂਟ, ਅਤੇ ਯੂਜ਼ਰ ਲੌਗਆਊਟ ਹੋ ਜਾਣਾਂ ਕਿਉਂਕਿ ਉਹ ਹੋਸਟਸ ਵਿੱਚ ਬਰਫ਼ਲ ਹੋ ਰਹੇ ਹਨ।

ਇੱਕ canonical host ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ: ਜਾਂ www.example.com ਜਾਂ example.com (apex)। ਦੂਜਾ ਐਨਟਰੀ-poinਟ canonical host ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰੇ ਤਾਂ ਕੁਕੀਆਂ, ਸੈਸ਼ਨ ਅਤੇ SEO ਸੰਕੇਤ ਇੱਕਸਾਰ ਰਹਿੰਦੇ ਹਨ।

ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ:

ਇੱਕ canonical host, ਦੂਜੇ ਤੋਂ ਇੱਕ ਸਿੰਗਲ 301 ਰੀਡਾਇਰੈਕਟ
ਹਰ ਰਿਕਵੇਸਟ ਲਈ http:// ਤੋਂ https:// ਤੱਕ 301 ਰੀਡਾਇਰੈਕਟ
ਰੀਡਾਇਰੈਕਟ ਦੌਰਾਨ ਪੂਰਾ path ਅਤੇ query string ਸੰਭਾਲੋ (deep links ਚੱਲਣੇ ਚਾਹੀਦੇ ਹਨ)
ਸਿਰਫ ਇਕ ਵਾਰ ਰੀਡਾਇਰੈਕਟ ਕਰੋ (ਚੇਨਸ ਤੋਂ ਬਚੋ ਜਿਵੇਂ http -> https -> www)

HTTP ਤੋਂ HTTPS ਲਈ, ਐਸੇ ਨਿਯਮ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਭੇਜ਼ਣ। ਲੂਪ ਰੋਕਣ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਫੈਸਲਾ ਇਸ ਆਧਾਰ ਤੇ ਕੀਤਾ ਜਾਵੇ ਕਿ ਅਸਲ ਰੀਕਵੈਸਟ ਕੀ ਸੀ। ਜੇ ਤੁਹਾਡਾ ਐਪ ਪ੍ਰੋਕਸੀ ਜਾਂ CDN ਪਿੱਛੇ ਬੈਠਾ ਹੈ, ਤਾਂ ਅਗਾਂਹੇ headers (forwarded headers) ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਕਰੋ; ਨਹੀਂ ਤਾਂ ਐਪ ਹਰ ਰਿਕਵੇਸਟ ਨੂੰ HTTP ਸਮਝ ਕੇ ਲਗਾਤਾਰ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਮੂਹਾਂ ਤਰ੍ਹਾਂ ਦੌਰਾਨ ਪੁਰਾਣੇ paths ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ routes ਬਦਲ ਰਹੇ ਹੋ (ਜਿਵੇਂ /login ਤੋਂ /sign-in), ਤਾਂ ਉਹਨਾਂ ਲਈ ਖ਼ਾਸ ਰੀਡਾਇਰੈਕਟ ਜੋੜੋ। ਸਿਫ਼ਰ ਹੋਮਪੇਜ ਵੱਲ blanket ਰੀਡਾਇਰੈਕਟ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ—ਇਹ ਬੁੱਕਮਾਰਕ ਅਤੇ ਸਾਂਝੇ ਲਿੰਕ ਤੋੜ ਦਿੰਦਾ ਹੈ।

HSTS ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਬੰਦ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਜਲਦੀ ਜਲ੍ਹਾ ਦਿੰਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ HTTP ਟਰਬਲਸ਼ੂਟਿੰਗ ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਮਨਾਹੀ ਕਰ ਸਕਦੇ ਹਨ। HTTPS ਸਥਿਰ ਹੋਣ ਅਤੇ ਸਬਡੋਮੇਨ ਕਵਰੇਜ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ HSTS ਚਾਲੂ ਕਰੋ।

ਰੀਡਾਇਰੈਕਟਸ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਅਸਰਮੁਹਤ ਟੈਸਟ ਹੋਸਟਨੇਮ ਵਰਤੋ, ਕੁਝ ਡੀਪ ਲਿੰਕ ਟੈਸਟ ਕਰੋ (ਜਤਕ auth pages), ਅਤੇ ਕਮਾਂਡ-ਲਾਈਨ ਰਿਕਵੇਸਟ ਚਲਾਉ ਜੋ ਹਰ ਰੀਡਾਇਰੈਕਟ ਕਦਮ ਅਤੇ ਆਖਰੀ ਮੰਜ਼ਿਲ ਦਿਖਾਏ।

ਕਦਮ-ਦਰ-ਕਦਮ low-risk cutover ਯੋਜਨਾ (ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ)

ਇੱਕ ਸੁਰੱਖਿਅਤ cutover ਵੱਧਤਰ ਟਾਈਮਿੰਗ ਦੀ ਗੱਲ ਹੈ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਨਵੀਂ ਡੋਮੇਨ ਤਿਆਰ ਅਤੇ ਟੈਸਟ ਹੋਵੇ ਜਦੋਂ ਤੱਕ ਕੋਈ ਅਸਲ ਯੂਜ਼ਰ ਉੱਤੇ ਨਹੀਂ ਆ ਰਿਹਾ, ਅਤੇ ਤੁਸੀਂ ਡੀ.ਐਨ.ਐਸ. ਬਦਲਾਅ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕਿ ਘਟਨਾ ਦੌਰਾਨ ਫਸੇ ਨਾ ਰਹੋ।

1) ਉਤਪਾਦਨ DNS ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਰੈਪ ਅਤੇ ਟੈਸਟ

ਜੋ ਰਿਕਾਰਡ ਤੁਸੀਂ ਬਦਲਣ ਵਾਲੇ ਹੋ ਉਹਨਾਂ ਦੀ TTL ਘਟਾਓ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ ਕਰੋ ਅਤੇ ਪੁਰਾਣੇ TTL ਵਿੰਡੋ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰੋ ਤਾਂ ਕਿ caches ਨਵੇਂ ਘਟਾਅ ਨੂੰ ਜਾਣ ਲੈਣ।

ਅਗਲਾ, ਕਸਟਮ ਡੋਮੇਨ ਨੂੰ ਆਪਣੇ ਹੋਸਟ/ਪ੍ਰੋਵਾਇਡਰ ਵਿੱਚ ਜੋੜੋ ਅਤੇ ਜੋ ਵੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲੋੜੀਂਦੀ ਹੈ ਪੂਰੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਉਥੇ ਜੋੜੋ ਤਾਂ ਕਿ ਪਲੇਟਫਾਰਮ ownership ਸਾਬਤ ਕਰਕੇ ਰਾਊਟਿੰਗ ਤਿਆਰ ਕਰ ਸਕੇ।

SSL ਜਲਦੀ ਜਾਰੀ ਕਰੋ। ਸਰਟੀਫਿਕੇਟ ਕੁਝ ਮਿੰਟ ਜਾਂ ਹੋਰ ਸਮਾਂ ਲੈ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ cutover ਦੌਰਾਨ ਉਸ ਦੇ ਇੰਤਜ਼ਾਰ ਵਿੱਚ ਨਹੀਂ ਫਸਣਾ ਚਾਹੁੰਦੇ।

ਡੋਮੇਨ ਨੂੰ ਪਬਲਿਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਈਵੇਟ ਟੈਸਟ ਕਰੋ: ਆਪਣੇ ਮਸ਼ੀਨ 'ਤੇ ਟੈਂਪਰੇਰੀ host entry ਨਾਲ ਨਵਾਂ endpoint ਖੋਲ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਾਈਟ HTTPS ਤੇ ਸਹੀ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਲੋਡ ਹੁੰਦੀ ਹੈ।

2) ਛੋਟੇ, ਉਲਟ ਸਕਣ ਯੋਗ ਕਦਮਾਂ 'ਚ cutover

ਇੱਕ ਸਟੇਜਡ ਅੱਗੇ-ਪਿੱਛੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਰਤੋ ਤਾਂ ਕਿ ਜਲਦੀ ਰੋਕੇ ਜਾ ਸਕੇ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ:

ਪਹਿਲਾਂ TTL ਘਟਾਓ, ਫਿਰ ਪੁਰਾਣੇ TTL ਪਿਰੀਅਡ ਦੇ ਉਤਰਨ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰੋ।
ਹੋਸਟ ਵਿੱਚ ਡੋਮੇਨ ਵੈਰੀਫਿਕੇਸ਼ਨ ਪੂਰੀ ਕਰੋ ਅਤੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਯਕੀਨ ਕਰੋ ਕਿ ਡੋਮੇਨ ਸਹੀ ਐਪ ਨੂੰ ਮੁੜ ਰਹੀ ਹੈ।
ਹਰ ਹੋਸਟਨੇਮ ਲਈ SSL ਸਹੀ ਹੈ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ (apex ਅਤੇ/ਜਾਂ www) ਪਹਿਲਾਂ ਹੀ।
DNS ਨੂੰ ਨਿਯੰਤਰਿਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲੋ: ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸਬਡੋਮੇਨ, ਛੋਟੇ ਖੇਤਰ, ਜਾਂ ਸੀਮਤ ਆਡੀਅਂਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਪੁਰਾਣੀ ਡੋਮੇਨ ਨੂੰ ਚਾਲੂ ਹੀ ਰੱਖੋ ਅਤੇ redirect ਕਰਕੇ traffic ਅਤੇ error rates ਨੂੰ ਮੋਨੀਟਰ ਕਰੋ।

ਜੇ ਤੁਸੀਂ DNS ਪੱਧਰ 'ਤੇ canary ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇੱਕ ਹੋਸਟਨੇਮ (ਜਿਵੇਂ www) ਹੀ ਪਹਿਲਾਂ ਸਵਿੱਚ ਕਰੋ ਅਤੇ apex ਨੂੰ ਬਾਅਦ ਵਿਚ ਰੱਖੋ।

3) ਰੋਲਬੈਕ ਦੀ ਯੋਜਨਾ ਸ਼ਾਂਤ ਮਨ ਨਾਲ ਬਣਾਓ

ਠੰਡੇ ਦਿਮਾਗ ਨਾਲ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਵਾਪਸ ਕਰੋਗੇ (ਕਿਹੜੇ ਰਿਕਾਰਡ, ਕਿਹੜੇ ਮੁੱਲ), ਅਤੇ ਕੌਣ ਇਹ ਕਰੇਗਾ। ਰੋਲਬੈਕ ਆਮ ਤੌਰ 'ਤੇ DNS ਨੂੰ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਰਿਕਾਰਡਾਂ 'ਤੇ ਦੁਬਾਰਾ ਰੱਖਣਾ ਹੁੰਦਾ ਹੈ।

ਪੁਰਾਣਾ ਸੈਟਅਪ ਜਿਵੇਂ SSL ਆਦਿ ਵੀ ਸਹੀ ਰਹਿ‍ਣ ਦਾ ਯਕੀਨ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਵਾਪਸੀ ਤੌਰ 'ਤੇ ਸਹੀ ਢੰਗ ਨਾਲ fallback ਹੋ ਸਕਣ।

ਕੂਕੀਜ਼, ਸੈਸ਼ਨ ਅਤੇ ਆਥ ਨੂੰ ਮੂਵ ਤੋਂ ਬਾਅਦ ਟੁੱਟਣ ਤੋਂ ਬਚਾਉ

ਡੋਮੇਨ ਬਦਲਣਾ ਸਿਰਫ DNS ਬਦਲਣਾ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਲਈ "ਲੌਗਡ ਇਨ ਹੋਣਾ" ਉਹ ਕੁਕੀ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਖਾਸ ਹੋਸਟਨੇਮ ਨਾਲ ਜੋੜ ਕੇ ਭੇਜਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਕ ਹੋਸਟਨੇਮ ਤੋਂ ਦੂਜੇ ਤੇ ਸਵਿੱਚ ਕਰੋਗੇ ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਪੁਰਾਣੀਆਂ ਕੁਕੀਜ਼ ਨਹੀਂ ਭੇਜੇਗਾ ਅਤੇ ਯੂਜ਼ਰ ਆਊਟ ਲੌਗ ਹੋ ਸਕਦੇ ਹਨ।

ਕੁਕੀ ਸੈਟਿੰਗ ਆਮ ਤੌਰ ਤੇ ਕਾਰਨ ਹੁੰਦੇ ਹਨ:

Domain ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਹੋਸਟਨੇਮ ਕੁਕੀ ਪ੍ਰਾਪਤ ਕਰਨਗੇ। app.old.com ਲਈ ਸੈਟ ਕੀਤੀ ਕੁਕੀ app.new.com ਨੂੰ ਨਹੀਂ ਭੇਜੀ ਜਾਵੇਗੀ। .example.com ਲਈ ਸੈਟ ਕੀਤੀ ਕੁਕੀ app.example.com ਅਤੇ www.example.com ‘ਤੇ ਸਾਂਝੀ ਹੋ ਸਕਦੀ ਹੈ।
Path ਕੁਕੀ ਨੂੰ ਕਿੱਥੇ ਭੇਜਿਆ ਜਾਵੇ ਉਸਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਬਹੁਤ ਸੁੰਘੜਾ ਹੈ (ਜਿਵੇਂ /api), ਤਾਂ ਤੁਹਾਡੀ UI ਉਹ ਵੇਖ ਨਹੀਂ ਪਾਏਗੀ।
Secure ਮਤਲਬ ਕੁਕੀ ਸਿਰਫ HTTPS ਉੱਤੇ ਭੇਜੀ ਜਾਵੇਗੀ। HTTPS-ਕੇਵਲ ਸਤੇਤ 'ਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ HTTP ਬੇਨਤੀ ਇਸਨੂੰ ਨਹੀਂ ਭੇਜੇਗੀ।
SameSite ਕ੍ਰਾਸ-ਸਾਈਟ ਰੀਡਾਇਰੈਕਟਸ ਅਤੇ ਐਮਬੇਡਡ ਫਲੋਅ ਲਈ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ। Lax ਆਮ ਤੌਰ ਤੇ ਠੀਕ ਹੈ, ਪਰ ਕੁਝ SSO ਜਾਂ ਭੁਗਤਾਨ ਰੀਡਾਇਰੈਕਟਾਂ ਲਈ None ਅਤੇ Secure ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਰਿਸਕ ਘਟਾਉਣ ਲਈ, ਇੱਕ ਛੋਟੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਯੋਜਨਾ ਬਣਾਓ ਜਿਸ ਵਿਚ ਦੋਹਾਂ ਡੋਮੇਨਾਂ ਕੰਮ ਕਰਨ। ਪੁਰਾਣਾ ਹੋਸਟਨੇਮ ਬਤਾਇਆ ਰਹਿਣ ਦਿਓ, ਨਰਮ ਰੀਡਾਇਰੈਕਟ ਕਰੋ, ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਾਂਝਾ ਸੈਸ਼ਨ ਸਟੋਰ ਵਰਤੋਂ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਜੋ ਕਿਸੇ ਵੀ ਹੋਸਟਨੇਮ 'ਤੇ ਪਹੁੰਚੇ ਉਹ ਪਛਾਣਿਆ ਜਾ ਸਕੇ।

ਜੇ ਤੁਸੀਂ SSO ਜਾਂ OAuth ਵਰਤਦੇ ਹੋ ਤਾਂ cutover ਤੋਂ ਪਹਿਲਾਂ settings ਅੱਪਡੇਟ ਕਰੋ: callback URLs, allowed origins, ਅਤੇ ਕਿਸੇ ਵੀ allowlist ਵਿਚ 'audience' ਜਾਂ redirect URI। ਨਹੀਂ ਤਾਂ ਲਾਗਿਨ identity provider 'ਤੇ ਸਫ਼ਲ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਤੁਹਾਡੇ ਐਪ ਵੱਲ ਵਾਪਸ ਆਉਣ ਤੇ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

ਪਹਿਲਾਂ ਉਹ ਫਲੋਅ ਟੈਸਟ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦੇ ਹਨ: sign up (ਅਤੇ email verification), login/logout, password reset, checkout ਜਾਂ payment return, ਅਤੇ multi-tab sessions।

ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ www.example.com ਨੂੰ example.com ਤੱਕ redirect ਕਰਦੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੁਕੀਆਂ .example.com ਲਈ ਸੈਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ (ਜਾਂ ਇੱਕ ਹੀ ਹੋਸਟਨੇਮ ਹਮੇਸ਼ਾਂ ਵਰਤਿਆ ਜਾਵੇ)। ਨਹੀਂ ਤਾਂ ਯੂਜ਼ਰ ਹੋਸਟਨੇਮਾਂ ਵਿਚ ਬਰਫ਼ਲ ਹੋ ਕੇ ਸੈਸ਼ਨ ਗੁਆ ਸਕਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਆਊਟੇਜ ਜਾਂ ਅਜੀਬ ਚੱਲਣ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ

Ship with a real domain

Build your app on Koder.ai, then connect a custom domain when you are ready to go live.

Start Free

ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਸਮੱਸਿਆਵਾਂ “ਰਾਜ਼ਦਾਰ ਇੰਟਰਨੈੱਟ ਮੁੱਦੇ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹਨਾਂ ਵਿੱਚ DNS, ਸਰਟੀਫਿਕੇਟ, ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮਾਂ ਦੇ ਛੋਟੇ-ਛੋਟੇ ਮਿਲਾਪੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਦੇ ਪਹੁੰਚਣ 'ਤੇ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਆਸਾਨ ਫੰਦਾ apex ਡੋਮੇਨ (example.com) ਹੈ। ਬਹੁਤ ਸਾਰੇ DNS ਪ੍ਰੋਵਾਇਡਰ ਸੱਚੀ CNAME ਨੂੰ apex ਤੇ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਤੁਸੀਂ ਆਨ੍ਹਾ ਨੂੰ CNAME ਵਜੋਂ ਪਾਇੰਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਉਹ ਸ਼ਾਇਦ ਚੁਪਕੇ ਠੀਕ ਨਾ ਕੰਮ ਕਰੇ, inconsistent resolve ਹੋਵੇ, ਜਾਂ ਕੁਝ ਨੈੱਟਵਰਕਾਂ ਤੇ ਟੁੱਟ ਜਾਵੇ। ਆਪਣਾ DNS ਹੋਸਟ ਜੋ ਸਹਿਯੋਗ ਦਿੰਦਾ ਹੈ (A/AAAA ਜਾਂ ALIAS/ANAME) ਵਰਤੋਂ।

ਇਕ ਹੋਰ ਆਮ ਕਾਰਨ ਡਾਊਨਟਾਈਮ ਦਾ ਹੈ: DNS ਨੂੰ ਫਲਿੱਪ ਕਰ ਦੇਣਾ ਪਹਿਲਾਂ SSL ਤਿਆਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ। ਯੂਜ਼ਰ ਨਵੀਂ ਜਗ੍ਹਾ ਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਬ੍ਰਾਉਜ਼ਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਕਮੀ ਜਾਂ ਅਧੂਰਾ ਕਵਰੇਜ ਕਾਰਨ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ ਤੇ ਦੋਹਾਂ example.com ਅਤੇ www.example.com ਲਈ ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਨੂੰ ਦੂਜੇ ਵੱਲ redirect ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੋਵੇ।

ਆਮ ਗਲਤੀਆਂ:

TTL ਘਟਾਏ ਬਿਨਾਂ DNS ਬਦਲਣਾ ਅਤੇ ਫਿਰ ਪੁਰਾਣੇ ਜਵਾਬਾਂ ਦੇ ਖਤਮ ਹੋਣ ਲਈ ਘੰਟੇ ਇੰਤਜ਼ਾਰ ਕਰਨਾ
ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਛੱਡਦੇ ਰਹਿਣ ਜੋ ਲੂਪ ਬਣਾਉਂਦੇ ਹਨ (www -> apex, ਫਿਰ apex ਵਾਪਸ www), ਜਾਂ ਕਿਸੇ ਥਾਂ HTTP ਬਲਾਕ ਕਰਕੇ HTTPS ਦੂਜੇ ਥਾਂ ਫੋਰਸ ਕਰਨਾ
http:// ਹਾਰਡਕੋਡ ਕੀਤੇ ਐਸੈੱਟਸ ਛੱਡ ਦੇਣਾ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਚੇਤਾਵਨੀ ਅਤੇ ਟੁੱਟੇ ਹੋਏ ਫੀਚਰ ਆ ਜਾਂਦੇ ਹਨ
non-web DNS ਰਿਕਾਰਡ ਭੁੱਲ ਜਾਣਾ, ਖ਼ਾਸ ਕਰਕੇ MX ਅਤੇ TXT, ਜੋ ਈਮੇਲ ਅਤੇ ਡੋਮੇਨ ਵੈਰੀਫਿਕੇਸ਼ਨ ਟੋੜ ਸਕਦੇ ਹਨ
ਸਿਰਫ ਇੱਕ ਬ੍ਰਾਉਜ਼ਰ 'ਤੇ ਟੈਸਟ ਕਰਨਾ ਅਤੇ cached HSTS ਜਾਂ ਕੁਕੀ ਖਾਸੀਅਤਾਂ ਜੋ ਹੋਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਗੀਆਂ ਨੂੰ ਨਾ ਦੇਖਣਾ

ਇੱਕ ਤੇਜ਼ sanity check: ਦੋਹਾਂ ਹੋਸਟਨੇਮ (www ਅਤੇ apex) ਨੂੰ HTTPS ਤੇ ਖੋਲ੍ਹੋ, ਲੌਗ ਇਨ ਕਰੋ, refresh ਕਰੋ, ਅਤੇ ਪੂਸ਼ਟੀ ਕਰੋ ਕਿ address bar ਕਦੇ ਵੀ ਵਾਪਸ HTTP ਤੇ ਨਹੀਂ ਆਉਂਦਾ।

ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਕਰ ਰਹੇ ਹੋ ਤਾਂ confirm ਕਰੋ ਕਿ custom domains connected ਹਨ ਅਤੇ SSL ਜਾਰੀ ਹੋ ਚੁੱਕਾ ਹੈ ਪਹਿਲਾਂ ਹੀ, ਅਤੇ rollback ਚੋਣ ਤੇ ਤਿਆਰ ਰਹੋ ਤਾਂ ਕਿ ਕੋਈ ਗਲਤ ਰੀਕਾਰਡ ਜਾਂ redirect ਲੰਮੇ ਸਮੇਂ ਲਈ ਨਾ ਰਹਿ ਜਾਵੇ।

cutover ਤੋਂ ਪਹਿਲਾਂ, ਦੌਰਾਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਛੋਟੀ ਚੈਕਲਿਸਟ

ਇੱਕ ਸ਼ਾਂਤ cutover ਅਕਸਰ ਤਿਆਰੀ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ। ਲਕਸ਼: ਯੂਜ਼ਰ ਲੌਗਿਨ ਜਾਰੀ ਰੱਖਣ, ਕੁਕੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਰਹਿਣ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰ ਸਕੋ।

Cutover ਤੋਂ ਪਹਿਲਾਂ

ਇਹ ਉਨ੍ਹਾਂ ਕਦਮਾਂ ਨੂੰ ਕਰੋ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਹਾਲੇ ਪੁਰਾਣੇ ਡੋਮੇਨ ਵੱਲ ਜਾ ਰਿਹਾ ਹੋਵੇ। ਇੱਕ ਦਿਨ ਦੇ ਲਈ ਸਮਾਂ ਦਿਓ ਤਾਂ ਕਿ DNS ਬਦਲਾਅ settle ਹੋ ਸਕੇ:

ਉਹਨਾਂ ਰਿਕਾਰਡਾਂ ਦੀ TTL ਘਟਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਬਦਲੋਗੇ ਅਤੇ ਮੌਜੂਦਾ ਮੁੱਲ ਲਿਖ ਲਵੋ ਤਾਂ ਕਿ ਤੁਰੰਤ ਵਾਪਸੀ ਕੀਤੀ ਜਾ ਸਕੇ।
ਹਰ ਹੋਸਟਨੇਮ ਦੀ ਸੂਚੀ ਬਣਾਓ (apex, www, api, ਆਦਿ) ਅਤੇ SSL validation ਦਾ ਮੋਡ ਚੁਣੋ (DNS ਜਾਂ HTTP)।
ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਪ੍ਰੀਪੇਅਰ ਅਤੇ ਸਟੇਜਿੰਗ ਵਿੱਚ ਟੈਸਟ ਕਰੋ: HTTP -> HTTPS, www -> apex (ਜਾਂ ਉਲਟ), ਅਤੇ ਇੱਕ canonical host।
ਆਥ ਸੰਬੰਧੀ ਸੈਟਿੰਗਾਂ ਅੱਪਡੇਟ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਕਸਾਰ URLs ਦੀ ਲੋੜ ਹੈ: OAuth callback URLs, allowed origins, cookie domain, ਅਤੇ SSO config।
ਫੈਸਲਾ ਕਰੋ ਕਿ cutover ਦੌਰਾਨ ਕੌਣ ਕੀ ਮੋਨੀਟਰ ਕਰੇਗਾ (ਲੌਗ, uptime checks, support inbox) ਅਤੇ ਇੱਕ ਛੋਟੀ ਚੇਂਜ ਵਿੰਡੋ ਨਿਰਧਾਰਤ ਕਰੋ।

Cutover ਦੌਰਾਨ ਅਤੇ ਬਾਅਦ

DNS ਫਲਿੱਪ ਕਰਦਿਆਂ ਪਹਿਲਾ ਘੰਟਾ ਇੱਕ incident drill ਵਾਂਗ ਪਰਵਾਰ ਕਰੋ। ਅਸਲ ਯੂਜ਼ਰ ਫਲੋਅਜ਼ ਦੇਖੋ, ਸਿਰਫ਼ status dashboards ਨਹੀਂ:

ਦੌਰਾਨ: 4xx/5xx ਵਾਧੇ, ਰੀਡਾਇਰੈਕਟ ਲੂਪ, ਅਤੇ ਲੌਗਿਨ ਫੇਲ੍ਹਰਾਂ (ਖਾਸ ਕਰਕੇ “invalid redirect URI” ਜਾਂ ਅਚਾਨਕ session drops) ਉੱਤੇ ਨਜ਼ਰ ਹੋਵੇ।
ਬਾਅਦ: ਕਈ ਬ੍ਰਾਉਜ਼ਰਾਂ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਜਾਂਚ ਕਰੋ ਅਤੇ ਲਈ ਕਿ ਮੁੱਖ ਪੇਜ਼ HTTPS 'ਤੇ ਮਿਲਦੇ ਹਨ ਬਿਨਾਂ mixed content ਦੇ।
ਬਾਅਦ: canonical host ਦਾ ਵਿਹਾਰ ਪੁਸ਼ਟੀ ਕਰੋ (address bar ਆਖਿਰਕਾਰ ਇਕ ਹੀ host ਦਿਖਾਵੇ) ਅਤੇ ਮਹੱਤਵਪੂਰਕ ਕੁਕੀਆਂ ਸੈੱਟ ਹੋ ਕੇ ਭੇਜੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ।
ਬਾਅਦ: ਪੁਰਾਣੀ ਡੋਮੇਨ ਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ redirect ਕਰਦੇ ਰੱਖੋ। ਕਈ ਯੂਜ਼ਰ ਪੁਰਾਣੇ ਬੁੱਕਮਾਰਕ, ਈਮੇਲ, ਜਾਂ ਕੈਸ਼ਡ ਲਿੰਕ ਰਾਹੀਂ ਵਾਪਸ ਆਉਣਗੇ।

ਚਾਹੇ Koder.ai (ਜਾਂ ਹੋਰ ਕੋਈ ਪਲੇਟਫਾਰਮ) custom domains ਅਤੇ SSL ਤੁਸੀਂ ਸੰਭਾਲਦਾ ਹੋਵੇ, ਇਹ ਚੈਕਲਿਸਟ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੈ—ਜ਼ਿਆਦਾਤਰ ਮੁੱਦੇ DNS ਅਤੇ ਰੀਡਾਇਰੈਕਟਸ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਨਾ ਕਿ ਐਪ ਕੋਡ ਤੋਂ।

ਉਦਾਹਰਣ ਤੱਥ: ਪਲੇਟਫਾਰਮ URL ਤੋਂ ਕਸਟਮ ਡੋਮੇਨ ‘ਤੇ ਜਾਣਾ

Deploy without extra tooling

Deploy and host your app in one place, then handle redirects and HTTPS with confidence.

Deploy Now

ਤੁਹਾਡੀ ਐਪ ਹਣੇ myapp.koder.ai ਵਰਗੇ ਅਸਥਾਈ ਪਲੇਟਫਾਰਮ ਪਤੇ ਤੇ ਚੱਲ ਰਹੀ ਹੈ। ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਤੁਸੀਂ example.com ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, www.example.com ਨੂੰ apex ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰਦੇ ਹੋ ਅਤੇ ਹਰ ਚੀਜ਼ HTTPS 'ਤੇ ਫੋਰਸ ਹੋਵੇ।

ਸਰਲ DNS ਯੋਜਨਾ ਰਿਸਕ ਘਟਾਉਂਦੀ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਨੋਟ ਲਵੋ (ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshot ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ ਤਾਂ ਉਸਦਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਲੋ) ਅਤੇ TTL ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ ਛੋਟਾ ਕਰੋ।

ਨਵੇਂ ਰਿਕਾਰਡ ਜੋੜੋ ਜਦੋਂ ਕਿ ਮੌਜੂਦਾ ਪਲੇਟਫਾਰਮ URL ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰਹੇ:

example.com: A/ALIAS record ਜੋ ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਟਾਰਗਟ ਨੂੰ ਪਾਇੰਟ ਕਰਦਾ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ
www.example.com: CNAME ਜੋ example.com ਨੂੰ ਪਾਇੰਟ ਕਰਦਾ ਹੈ (ਜਾਂ ਪ੍ਰੋਵਾਇਡਰ ਟਾਰਗਟ ਨੂੰ, ਪ੍ਰੋਵਾਇਡਰ ਦੇ ਅਨੁਸਾਰ)
myapp.koder.ai ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ fallback ਮੌਜੂਦ ਹੋਵੇ

ਜਦੋਂ DNS ਠੀਕ ਹੋਵੇ, ਦੋਹਾਂ ਹੋਸਟਨੇਮ (example.com ਅਤੇ www.example.com) ਲਈ SSL ਦੀ ਬੇਨਤੀ ਕਰੋ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਵਿੱਚ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਅਤੇ ਐਕਟਿਵ ਨਾ ਹੋਵੇ, ਨਹੀਂ ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਚੇਤਾਵਨੀ ਹੋ ਸਕਦੀਆਂ ਹਨ।

Cutover ਟਾਈਮਲਾਈਨ ਅਤੇ ਚੈਕਪੌਇੰਟ:

T-24h: TTL ਘਟਾਓ, ਰੋਲਬੈਕ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਜਾਂਚੋ
T-0: ਡੋਮੇਨ ਨੂੰ ਐਪ ਹੋਸਟ ਵਿੱਚ ਏਨੇਬਲ ਕਰੋ, SSL ਤਿਆਰ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
T+15m: incognito ਵਿੱਚ example.com ਟੈਸਟ ਕਰੋ (ਹੋਮਪੇਜ, ਸਟੈਟਿਕ ਐਸੈੱਟਸ, API calls)
T+30m: ਰੀਡਾਇਰੈਕਟਸ ਨੂੰ ਏਨੇਬਲ ਕਰੋ (HTTP -> HTTPS ਅਤੇ www -> apex)
ਰੋਲਬੈਕ ਪਲ: ਜੇ ਲੌਗਿਨ ਜਾਂ API calls ਫੇਲ ਹੋਣ, DNS ਨੂੰ ਪਿਛਲੇ ਟਾਰਗਟ ਤੇ ਵਾਪਸ ਰੱਖੋ ਅਤੇ ਪਲੇਟਫਾਰਮ URL ਜਿਉਂਦਾ ਰੱਖੋ

ਮੂਵ ਤੋਂ ਬਾਅਦ cookie ਵਿਵਹਾਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। ਲੌਗ ਇਨ ਕਰੋ, refresh ਕਰੋ, ਅਤੇ ਚੈੱਕ ਕਰੋ ਕਿ ਤੁਸੀਂ ਦੋਹਾਂ www ਅਤੇ apex ‘ਤੇ ਲੌਗਡ ਰਹਿੰਦੇ ਹੋ। ਜੇ ਸੈਸ਼ਨ ਟੁੱਟਦੇ ਹਨ ਤਾਂ ਅਕਸਰ ਇਹ cookie domain ਜਾਂ SameSite ਸੈਟਿੰਗ ਕਾਰਨ ਹੁੰਦਾ ਹੈ ਜੋ ਪੁਰਾਣੇ ਹੋਸਟ ਨੂੰ ਮੰਨਦੀ ਰਹਿੰਦੀ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਨਿਗਰਾਨੀ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾਅਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ

Cutover ਚੱਲਾਂਦੇ ਫੇਰ, ਕੰਮ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਮੂਵ ਬਾਅਦ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਨਹੀਂ ਨੋਟਿਸ ਕਰਦਾ: ਸਰਟੀਫਿਕੇਟ ਮਿਆਦ ਨੇੜੇ ਆਉਣਾ, ਜਲਦੀ ਕੀਤਾ DNS ਬਦਲਾਅ, ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਵਿੱਚ ਕੀਤੀ ਛੋਟੀ-ਸੁਧਾਰ ਜੋ ਲੌਗਿਨ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ।

ਛੋਟਾ ਮੋਨੀਟਰੀੰਗ ਰੁਟੀਨ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕੋ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਵਿਸ਼ਾਲ ਉਪਕਰਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਕੁਝ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਕੁੰਜੀ ਪੇਜ਼ਾਂ ਲਈ availability checks (home, login, ਅਤੇ ਇਕ authenticated page), ਸਰਟੀਫਿਕੇਟ expiry alerts (ਉਦਾਹਰਣ ਲਈ 30 ਦਿਨ ਅਤੇ ਫਿਰ 7 ਦਿਨ), error-rate tracking (4xx/5xx spikes), ਅਤੇ ਹੋਰ ਰੀਡਾਇਰੈਕਟ ਪੁਸ਼ਟੀ।

24 ਤੋਂ 72 ਘੰਟਿਆਂ ਲਈ ਪਿਛਲਾ ਸੈਟਅਪ ਤਿਆਰ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਆ ਸਕੋ ਜੇ ਕੋਈ ਛੁਪਿਆ ਮੁੱਦਾ ਜਿਵੇਂ payment callback ਜਾਂ OAuth provider ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਡੋਮੇਨ ਨੂੰ ਪોઈਂਟ ਕਰ ਰਿਹਾ ਹੋਵੇ।

ਜਦੋਂ ਤੁਹਾਨੂੰ ਭਰੋਸਾ ਹੋ ਜਾਵੇ, TTL ਮੁੱਲ ਵਾਪਸ ਵਧਾ ਦਿਓ। ਘੱਟ TTL ਚੇੰਜ ਦੌਰਾਨ ਲਾਭਦਾਇਕ ਹੈ ਪਰ ਇਹ resolvers ਉੱਤੇ ਲੋਡ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਛੋਟੀ ਗਲਤੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਵਧਾ ਦਿੰਦਾ ਹੈ। ਅਕਸਰ ਤੀਮ 1 ਤੋਂ 4 ਘੰਟੇ TTL ਦੇਣਦੀ ਹੈ।

ਆਖਿਰ ਵਿੱਚ, final state ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜਦੋਂ ਯਾਦ ਤਾਜ਼ਾ ਹੋ: ਕਿਹੜੇ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹਨ (type, name, value, TTL), ਕਿਹੜੇ ਹੋਸਟਨੇਮ ਸਹੀ ਹਨ, ਅਤੇ ਠੀਕ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ। ਸ਼ਾਮਲ ਕਰੋ ਕਿ ਸਰਟੀਫਿਕੇਟ ਕਿੱਥੇ ਜਾਰੀ ਹੁੰਦੇ ਹਨ, ਉਹ ਕੀ ਕਵਰ ਕਰਦੇ ਹਨ (apex, www, subdomains), ਅਤੇ renewal ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸਦੇ ਕੋਲ ਹੈ।

ਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ 'ਤੇ build ਅਤੇ deploy ਕਰਦੇ ਹੋ ਤਾਂ ਡੋਮੇਨਾਂ ਨੂੰ ਪਹਿਲਵਾਰ ਫੀਚਰ ਵਜੋਂ ਦੇਖਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ rollback ਸਧਾਰਨ ਹੋਵੇ ਤਾਂ ਭਵਿੱਖੀ ਡੋਮੇਨ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਬਦਲਾਅਾਂ ਘੱਟ ਤਣਾਅ ਵਾਲੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

Should my main site be on the apex domain or on www?

Default to one canonical hostname and redirect everything else to it.

Choose either example.com (apex) or www.example.com as the “real” one.
Treat the other as a single 301 redirect.

This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.

When should I lower DNS TTL before switching domains?

Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.

Common cutover TTL: 300–600 seconds
After the move is stable: raise TTL back up (often 1–4 hours)

Only lower TTL on the records you’re actually going to change.

What DNS record should I use: A, CNAME, or ALIAS?

For many app setups:

Use CNAME for subdomains like www.example.com or app.example.com when you’re pointing to a provider hostname.
Use A (or ALIAS/ANAME if your DNS supports it) for the apex example.com.

Do I need SSL ready before I change DNS?

Don’t switch user traffic until HTTPS is valid on the new hostname(s).

A practical order:

Add the domain in your host/platform (for example, in Koder.ai custom domain settings)
Complete domain verification (often via TXT)
Wait until the certificate is issued for every hostname you’ll serve
Only then update DNS to send real users there

This avoids browser warnings and blocked requests right at cutover.

How do I avoid breaking email when I add web records to my domain?

Most email breakage happens when people delete or overwrite MX and TXT records.

Before changing anything:

Identify existing MX, SPF, DKIM, , and verification TXT records

How do I avoid redirect loops when forcing HTTPS and www/apex?

Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.

Use these safe defaults:

Exactly one redirect from non-canonical host → canonical host
Exactly one redirect from http:// → https://
Preserve path and query string

If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.

Will switching to a custom domain log users out?

Yes, it’s common if cookies were scoped to the old hostname.

What to check:

Cookie Domain: cookies set for old-host won’t be sent to new-host
Cookie : SSO/payment redirects can fail if it’s too strict

What auth and SSO settings do I need to update after a domain change?

Update identity settings before cutover.

Typical items that must match the new domain exactly:

OAuth/SSO redirect (callback) URLs
Allowed origins / CORS settings
Any allowlisted logout URLs

If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.

What’s the simplest rollback plan if the cutover goes wrong?

A rollback is usually just restoring the previous DNS values.

Keep it simple:

Write down the “old” record values (and TTL) before you edit anything
Keep the old endpoint live long enough to receive traffic again
Decide who will revert the records and how you’ll confirm it worked

If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.

What should I test right after the domain cutover?

Focus on real user paths, not just the homepage.

Test these on both the canonical host and the redirecting host:

Login/logout, password reset, email verification
A deep link with a query string
An authenticated page refresh (session stays valid)
API calls your frontend depends on

Also verify the address bar ends on and always on , with no mixed-content warnings.