2 · DNS + SSL

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

## Metadata
- title: 2 · DNS + SSL
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/02-dns-ssl/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 5
- step_number: 2
- est_time: ~20 min
- description: Confirm the staging subdomain resolves to the server and serves a valid TLS chain before the first release lands — a deploy onto an unresolved or untrusted host wastes a round-trip.
- tags: codecanyon, laravel, dns, ssl

## Execution rules (binding)
- This is step 2 of phase 5 (~20 min) — do only this step, then stop at its `## Checklist`.
- Follow `## Steps` in order. Do not skip steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (browser, downloads, OAuth, moving files) need the human — wait for or instruct them; 🤖 **Agent** steps you run in the shell.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, **stop, show what you got, and ask how to proceed** — do not guess or rewrite the procedure.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the step done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this page describes — no refactors, added features, or later-phase work unless the page says so.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.

---

# 2 · DNS + SSL

## TL;DR

**Objective** — confirm the staging subdomain resolves to the server and serves a valid TLS chain *before* the first release lands, so the deploy doesn't fail on an unresolved or untrusted host.

:::note[User part + done-when]
**👤 User part** — the DNS + certificate are dashboard work: create the `staging` subdomain pointed at the server IP and issue/confirm the certificate in your DNS + hosting panel. An agent can verify resolution and the TLS chain, but it can't click "add subdomain" or "issue certificate."

**Done when** `dig +short` returns the server IP and `curl -sI` returns a response over a valid (green-padlock) TLS chain. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (👤 DNS/cert panel, 🤖 verification).
:::

## Background

The subdomain and certificate were set up in Phase 4. This is the **confirmation gate**: get the subdomain resolving and the padlock green *before* the release lands, so the deploy doesn't fail on an unresolved or untrusted host.

## Steps

### 1. Create / confirm the subdomain

The subdomain and certificate are account-level actions — create them in your panel so the host is reachable and trusted before deploying.

:::note[Who does this]
👤 **User** creates the `staging` subdomain in DNS and issues/confirms the certificate in the hosting panel — dashboard actions only a person can complete.
:::

<Steps>

1. **Create the `staging` subdomain** in your DNS, pointed at the server's IP.

   - ✅ A `staging` subdomain exists in DNS, pointed at the server IP.

2. **Issue or confirm the certificate** (hosting panel or `certbot`).

   - ✅ A valid certificate covers the staging subdomain.

</Steps>

### 2. Verify resolution and TLS

Confirm the subdomain resolves to the server and serves a trusted TLS chain before the release lands.

<Steps>

1. **Check DNS resolution and the TLS chain.**

   ```bash
   dig +short staging.yourapp.com        # expect the server IP
   curl -sI https://staging.yourapp.com | head -1   # expect HTTP/2 + valid TLS chain
   # Expected: the server IP, then an HTTP/2 status line over a valid TLS chain
   ```

   - ✅ `dig` returns the server IP and `curl -sI` responds over a valid TLS chain.

</Steps>

:::note[A 500 on the homepage is fine right now]
Until the installer runs (page 4), the database is empty and `/` may return `HTTP 500`. You're only verifying DNS resolution and a trusted TLS chain here — not application output.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Resolution verified** — `staging.yourapp.com` resolves to the server (`dig +short`).
- [ ] **🤖 TLS verified** — `curl -sI` returns a response over a valid TLS chain (green padlock).

:::next[Next step]
[First release](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/03-first-release/)
:::

# 2 · DNS + SSL

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/02-dns-ssl/

## TL;DR

**Objective** — confirm the staging subdomain resolves to the server and serves a valid TLS chain *before* the first release lands, so the deploy doesn't fail on an unresolved or untrusted host.

:::note[User part + done-when]
**👤 User part** — the DNS + certificate are dashboard work: create the `staging` subdomain pointed at the server IP and issue/confirm the certificate in your DNS + hosting panel. An agent can verify resolution and the TLS chain, but it can't click "add subdomain" or "issue certificate."

**Done when** `dig +short` returns the server IP and `curl -sI` returns a response over a valid (green-padlock) TLS chain. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (👤 DNS/cert panel, 🤖 verification).
:::

## Background

The subdomain and certificate were set up in Phase 4. This is the **confirmation gate**: get the subdomain resolving and the padlock green *before* the release lands, so the deploy doesn't fail on an unresolved or untrusted host.

## Steps

### 1. Create / confirm the subdomain

The subdomain and certificate are account-level actions — create them in your panel so the host is reachable and trusted before deploying.

:::note[Who does this]
👤 **User** creates the `staging` subdomain in DNS and issues/confirms the certificate in the hosting panel — dashboard actions only a person can complete.
:::

<Steps>

1. **Create the `staging` subdomain** in your DNS, pointed at the server's IP.

   - ✅ A `staging` subdomain exists in DNS, pointed at the server IP.

2. **Issue or confirm the certificate** (hosting panel or `certbot`).

   - ✅ A valid certificate covers the staging subdomain.

</Steps>

### 2. Verify resolution and TLS

Confirm the subdomain resolves to the server and serves a trusted TLS chain before the release lands.

<Steps>

1. **Check DNS resolution and the TLS chain.**

   ```bash
   dig +short staging.yourapp.com        # expect the server IP
   curl -sI https://staging.yourapp.com | head -1   # expect HTTP/2 + valid TLS chain
   # Expected: the server IP, then an HTTP/2 status line over a valid TLS chain
   ```

   - ✅ `dig` returns the server IP and `curl -sI` responds over a valid TLS chain.

</Steps>

:::note[A 500 on the homepage is fine right now]
Until the installer runs (page 4), the database is empty and `/` may return `HTTP 500`. You're only verifying DNS resolution and a trusted TLS chain here — not application output.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Resolution verified** — `staging.yourapp.com` resolves to the server (`dig +short`).
- [ ] **🤖 TLS verified** — `curl -sI` returns a response over a valid TLS chain (green padlock).

:::next[Next step]
[First release](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/03-first-release/)
:::

TL;DR

Objective — confirm the staging subdomain resolves to the server and serves a valid TLS chain before the first release lands, so the deploy doesn’t fail on an unresolved or untrusted host.

Background

The subdomain and certificate were set up in Phase 4. This is the confirmation gate: get the subdomain resolving and the padlock green before the release lands, so the deploy doesn’t fail on an unresolved or untrusted host.

Steps

1. Create / confirm the subdomain

The subdomain and certificate are account-level actions — create them in your panel so the host is reachable and trusted before deploying.

Create the staging subdomain in your DNS, pointed at the server’s IP.
- ✅ A staging subdomain exists in DNS, pointed at the server IP.
Issue or confirm the certificate (hosting panel or certbot).
- ✅ A valid certificate covers the staging subdomain.

2. Verify resolution and TLS

Confirm the subdomain resolves to the server and serves a trusted TLS chain before the release lands.

Check DNS resolution and the TLS chain.

dig +short staging.yourapp.com        # expect the server IP
curl -sI https://staging.yourapp.com | head -1   # expect HTTP/2 + valid TLS chain
# Expected: the server IP, then an HTTP/2 status line over a valid TLS chain

✅ dig returns the server IP and curl -sI responds over a valid TLS chain.

Checklist

Do not mark this step done until every box below is checked.

🤖 Resolution verified — staging.yourapp.com resolves to the server (dig +short).
🤖 TLS verified — curl -sI returns a response over a valid TLS chain (green padlock).

First release

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

## Metadata
- title: 2 · DNS + SSL
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/02-dns-ssl/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 5
- step_number: 2
- est_time: ~20 min
- description: Confirm the staging subdomain resolves to the server and serves a valid TLS chain before the first release lands — a deploy onto an unresolved or untrusted host wastes a round-trip.
- tags: codecanyon, laravel, dns, ssl

## Execution rules (binding)
- This is step 2 of phase 5 (~20 min) — do only this step, then stop at its `## Checklist`.
- Follow `## Steps` in order. Do not skip steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (browser, downloads, OAuth, moving files) need the human — wait for or instruct them; 🤖 **Agent** steps you run in the shell.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, **stop, show what you got, and ask how to proceed** — do not guess or rewrite the procedure.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the step done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this page describes — no refactors, added features, or later-phase work unless the page says so.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.

---

# 2 · DNS + SSL

## TL;DR

**Objective** — confirm the staging subdomain resolves to the server and serves a valid TLS chain *before* the first release lands, so the deploy doesn't fail on an unresolved or untrusted host.

:::note[User part + done-when]
**👤 User part** — the DNS + certificate are dashboard work: create the `staging` subdomain pointed at the server IP and issue/confirm the certificate in your DNS + hosting panel. An agent can verify resolution and the TLS chain, but it can't click "add subdomain" or "issue certificate."

**Done when** `dig +short` returns the server IP and `curl -sI` returns a response over a valid (green-padlock) TLS chain. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (👤 DNS/cert panel, 🤖 verification).
:::

## Background

The subdomain and certificate were set up in Phase 4. This is the **confirmation gate**: get the subdomain resolving and the padlock green *before* the release lands, so the deploy doesn't fail on an unresolved or untrusted host.

## Steps

### 1. Create / confirm the subdomain

The subdomain and certificate are account-level actions — create them in your panel so the host is reachable and trusted before deploying.

:::note[Who does this]
👤 **User** creates the `staging` subdomain in DNS and issues/confirms the certificate in the hosting panel — dashboard actions only a person can complete.
:::

<Steps>

1. **Create the `staging` subdomain** in your DNS, pointed at the server's IP.

   - ✅ A `staging` subdomain exists in DNS, pointed at the server IP.

2. **Issue or confirm the certificate** (hosting panel or `certbot`).

   - ✅ A valid certificate covers the staging subdomain.

</Steps>

### 2. Verify resolution and TLS

Confirm the subdomain resolves to the server and serves a trusted TLS chain before the release lands.

<Steps>

1. **Check DNS resolution and the TLS chain.**

   ```bash
   dig +short staging.yourapp.com        # expect the server IP
   curl -sI https://staging.yourapp.com | head -1   # expect HTTP/2 + valid TLS chain
   # Expected: the server IP, then an HTTP/2 status line over a valid TLS chain
   ```

   - ✅ `dig` returns the server IP and `curl -sI` responds over a valid TLS chain.

</Steps>

:::note[A 500 on the homepage is fine right now]
Until the installer runs (page 4), the database is empty and `/` may return `HTTP 500`. You're only verifying DNS resolution and a trusted TLS chain here — not application output.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Resolution verified** — `staging.yourapp.com` resolves to the server (`dig +short`).
- [ ] **🤖 TLS verified** — `curl -sI` returns a response over a valid TLS chain (green padlock).

:::next[Next step]
[First release](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/03-first-release/)
:::

# 2 · DNS + SSL

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/02-dns-ssl/

## TL;DR

**Objective** — confirm the staging subdomain resolves to the server and serves a valid TLS chain *before* the first release lands, so the deploy doesn't fail on an unresolved or untrusted host.

:::note[User part + done-when]
**👤 User part** — the DNS + certificate are dashboard work: create the `staging` subdomain pointed at the server IP and issue/confirm the certificate in your DNS + hosting panel. An agent can verify resolution and the TLS chain, but it can't click "add subdomain" or "issue certificate."

**Done when** `dig +short` returns the server IP and `curl -sI` returns a response over a valid (green-padlock) TLS chain. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (👤 DNS/cert panel, 🤖 verification).
:::

## Background

The subdomain and certificate were set up in Phase 4. This is the **confirmation gate**: get the subdomain resolving and the padlock green *before* the release lands, so the deploy doesn't fail on an unresolved or untrusted host.

## Steps

### 1. Create / confirm the subdomain

The subdomain and certificate are account-level actions — create them in your panel so the host is reachable and trusted before deploying.

:::note[Who does this]
👤 **User** creates the `staging` subdomain in DNS and issues/confirms the certificate in the hosting panel — dashboard actions only a person can complete.
:::

<Steps>

1. **Create the `staging` subdomain** in your DNS, pointed at the server's IP.

   - ✅ A `staging` subdomain exists in DNS, pointed at the server IP.

2. **Issue or confirm the certificate** (hosting panel or `certbot`).

   - ✅ A valid certificate covers the staging subdomain.

</Steps>

### 2. Verify resolution and TLS

Confirm the subdomain resolves to the server and serves a trusted TLS chain before the release lands.

<Steps>

1. **Check DNS resolution and the TLS chain.**

   ```bash
   dig +short staging.yourapp.com        # expect the server IP
   curl -sI https://staging.yourapp.com | head -1   # expect HTTP/2 + valid TLS chain
   # Expected: the server IP, then an HTTP/2 status line over a valid TLS chain
   ```

   - ✅ `dig` returns the server IP and `curl -sI` responds over a valid TLS chain.

</Steps>

:::note[A 500 on the homepage is fine right now]
Until the installer runs (page 4), the database is empty and `/` may return `HTTP 500`. You're only verifying DNS resolution and a trusted TLS chain here — not application output.
:::

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Resolution verified** — `staging.yourapp.com` resolves to the server (`dig +short`).
- [ ] **🤖 TLS verified** — `curl -sI` returns a response over a valid TLS chain (green padlock).

:::next[Next step]
[First release](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/03-first-release/)
:::