DEV Community: Tahsin Abrar

How to Check Laravel Page Memory Usage Without Guessing

Tahsin Abrar — Fri, 18 Sep 2026 20:02:36 +0000

A Laravel page once started feeling unusually heavy.

The server was running, the page was loading, and there was no obvious error. But one question kept coming up:

How much memory is this page actually using?

Tools like htop were useful for checking the server, but they did not give me a simple answer for one specific Laravel request.

The easiest solution was already available in PHP:

memory_get_peak_usage(true)

With one small log entry, I could see the peak memory usage of each Laravel request.

The Quick Solution

Open:

public/index.php

After Laravel handles the request, add:

logger(
    'Peak Memory Usage: ' .
    round(memory_get_peak_usage(true) / 1024 / 1024, 2) .
    ' MB'
);

For example:

$app->handleRequest(Request::capture());

logger(
    'Peak Memory Usage: ' .
    round(memory_get_peak_usage(true) / 1024 / 1024, 2) .
    ' MB'
);

Now open the Laravel page you want to test.

Then watch the log:

tail -f storage/logs/laravel.log

Refresh the page.

You should see something like:

Peak Memory Usage: 74.38 MB

That is the peak amount of memory PHP allocated while processing that request.

Why This Is Useful

Imagine checking several pages:

Home        → 42 MB
Dashboard   → 55 MB
Users       → 63 MB
Reports     → 210 MB

The reports page immediately stands out.

Instead of saying:

“This page feels heavy.”

you now have something measurable:

“This page reaches around 210 MB while the others stay below 70 MB.”

That gives you a much better place to start debugging.

A Real Laravel Example

Suppose the reports page contains:

$users = User::all();

If your database has 100,000 users, Laravel may load all of them into memory.

If the page only needs 50 users, use:

$users = User::paginate(50);

For large background processing, you might use:

User::chunk(1000, function ($users) {
    foreach ($users as $user) {
        // Process user
    }
});

After changing the code, test the page again.

You may get:

Before → 210 MB
After  → 68 MB

Now you can clearly see whether the optimization helped.

What Does `memory_get_peak_usage(true)` Mean?

This function:

memory_get_peak_usage(true)

returns the highest amount of memory allocated during the current PHP request.

PHP returns the value in bytes.

So we convert it to megabytes:

memory_get_peak_usage(true) / 1024 / 1024

And round it:

round(memory_get_peak_usage(true) / 1024 / 1024, 2)

That gives us an easy-to-read result like:

74.38 MB

Why Not Just Use `htop`?

htop is still very useful.

Use it when you want to understand:

total server memory
CPU usage
PHP-FPM workers
MySQL usage
overall server health

But if your question is:

How much peak memory did this Laravel request use?

then memory_get_peak_usage(true) is much more direct.

They solve different problems.

What to Check If Memory Is Too High

If one page uses much more memory than others, start by checking:

large Model::all() queries
unnecessary Eloquent relationships
huge collections
large file or image processing
PDF or Excel generation
reports loading too much data
loops that keep large amounts of data in memory

The main rule is simple:

Do not load everything into memory if you only need a small part of it.

Test More Than Once

Do not rely on one request.

Refresh the same page a few times:

Request 1 → 71.8 MB
Request 2 → 69.9 MB
Request 3 → 70.2 MB

Small differences are normal.

What matters is the general pattern.

If one page consistently stays around 70 MB and another stays around 200 MB, that difference is worth investigating.

Important: Remove the Logger After Testing

This code is for debugging:

logger(...)

Do not leave it running forever on a busy production site.

Otherwise every page request will create another log entry.

A simple workflow is:

Measure
↓
Find the expensive page
↓
Optimize
↓
Measure again
↓
Remove the logger

Final Thoughts

Laravel performance debugging becomes much easier when you stop guessing and start measuring.

If you only want to know how much peak memory a Laravel request uses, you do not need a complicated monitoring setup.

Add:

memory_get_peak_usage(true)

log the result, refresh the page, and check:

storage/logs/laravel.log

A small measurement can quickly tell you which page deserves your attention.

Measure first. Optimize second.

My Public IP Kept Changing While Connecting TablePlus to DigitalOcean - How I Fixed It

Tahsin Abrar — Sun, 30 Aug 2026 18:10:25 +0000

Recently, I ran into a small but confusing problem while connecting TablePlus to a DigitalOcean Managed Database.

At first, I thought something was wrong with TablePlus.

It wasn’t.

The real problem was my public IP address.

Here’s what happened.

The Problem

I created a managed database on DigitalOcean and wanted to connect to it from my laptop using TablePlus.

DigitalOcean has a Trusted Sources option where you need to allow the IP addresses that can connect to your database.

So I searched:

What is my IP?

I copied the IP, added it to DigitalOcean, and tried to connect.

But things were not working as expected.

Then I decided to check my public IP from the terminal.

I ran:

curl api.ipify.org

and also:

curl ifconfig.me

That made things even more confusing.

The output looked messy because the IP appeared together with some curl progress information.

For a moment, I wasn’t even sure which number was my actual IP.

First, I Cleaned Up the Command

Instead of using plain curl, I used:

curl -4 -sS https://ifconfig.me/ip && echo

Now the output was simple:

203.0.113.10

Much better.

The -4 makes sure I get an IPv4 address, and -sS removes the unnecessary progress output.

But then I noticed something strange.

A little later, I checked again and got something like:

203.0.113.14

My public IP had changed.

That was the actual problem.

Why Was My IP Changing?

My internet connection was using a dynamic public IP.

Depending on your ISP, this can also happen when you are behind something like CGNAT.

So even though I was using the same laptop and the same internet connection, the public IP seen by DigitalOcean could change.

For example:

203.0.113.10

might later become:

203.0.113.14

If DigitalOcean only trusts the first IP, TablePlus will stop connecting after the IP changes.

That explained why the connection sometimes worked and sometimes didn’t.

How I Solved It

In my case, I needed to make sure DigitalOcean trusted the correct source address.

For temporary development, the simplest solution is to check your current IP:

curl -4 -sS https://ifconfig.me/ip && echo

Then add that IP to:

DigitalOcean
→ Database
→ Network Access
→ Trusted Sources

After updating the trusted IP, I tried TablePlus again.

And this time:

Connected.

The database loaded normally.

What About Using `/24`?

While debugging this, I also learned about CIDR ranges such as:

203.0.113.0/24

A /24 allows the whole range from:

203.0.113.0

to:

203.0.113.255

This can be useful if you know your traffic can come from that whole range.

But there is an important catch.

If you see:

203.0.113.10

and later:

203.0.113.14

you should not automatically assume that you should allow:

203.0.113.0/24

That would allow many more IP addresses than just yours.

For local development, I prefer allowing my current IP unless I know exactly which CIDR range I should trust.

If your IP changes very often, a static IP, VPN with a fixed exit IP, or another stable connection can be a cleaner long-term solution.

What I Learned

The funny thing is, I started debugging this as a TablePlus issue.

Then I thought it was a DigitalOcean issue.

But in the end, it was mostly a networking issue.

If you ever face the same problem, check your public IP first:

curl -4 -sS https://ifconfig.me/ip && echo

Then compare it with the IP in your DigitalOcean Trusted Sources.

Sometimes a database connection problem has nothing to do with the database at all.

And that was the small networking lesson I learned while trying to connect TablePlus to DigitalOcean.

How I Debugged a phpMyAdmin 500 Error While Importing a Large SQL File on Laragon

Tahsin Abrar — Tue, 25 Aug 2026 12:28:37 +0000

I recently ran into a weird issue while working on a Laravel project on Windows using Laragon.

Everything was working fine until I tried to import a database through phpMyAdmin.

Instead of an SQL error, phpMyAdmin simply returned:

Internal Server Error
The server encountered an internal error or misconfiguration...

No useful message. Just HTTP 500.

My SQL file was around 97 MB, so at first I thought it was probably a PHP upload limit issue.

It wasn't that simple.

Here is how I debugged it.

1. Check which PHP configuration is actually running

From Laragon Terminal:

php --ini

Then I checked the important error settings:

php.exe -r "echo 'error_log=' . ini_get('error_log') . PHP_EOL;"
php.exe -r "echo 'log_errors=' . ini_get('log_errors') . PHP_EOL;"
php.exe -r "echo 'display_errors=' . ini_get('display_errors') . PHP_EOL;"

My output was:

error_log=D:/C-data/laragon/tmp/php_errors.log
log_errors=1
display_errors=1

One small Laragon/Git Bash issue I also found was:

type php

returned:

php is aliased to `winpty php.exe'

Because of that, commands like:

php -i | grep ...

sometimes returned:

stdout is not a tty

Using php.exe directly avoids that problem.

2. Check the PHP error log

My PHP error log was:

D:/C-data/laragon/tmp/php_errors.log

I reproduced the import error and checked it:

tail -n 50 /d/C-data/laragon/tmp/php_errors.log

Nothing useful appeared.

That was an important clue.

3. Make sure browser PHP and CLI PHP use the same php.ini

I created a temporary file:

<?php phpinfo();

Then opened it through the browser.

Important values were:

Server API: CGI/FastCGI
PHP Version: 8.4.4
Loaded Configuration File:
D:\C-data\laragon\bin\php\php-8.4.4-nts-Win32-vs17-x64\php.ini

My PHP limits were already high enough:

upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 36000

So the 97 MB SQL file should have been allowed by PHP.

4. Check Apache logs

I located the Apache error log with:

grep -Ri "ErrorLog" /d/C-data/laragon/etc/apache2 /d/C-data/laragon/bin/apache 2>/dev/null

In my case:

D:/C-data/laragon/bin/apache/httpd-2.4.54-win64-VS16/logs/error.log

Then:

tail -n 50 /d/C-data/laragon/bin/apache/httpd-2.4.54-win64-VS16/logs/error.log

Still nothing useful.

So I checked the access log:

tail -n 30 /d/C-data/laragon/bin/apache/httpd-2.4.54-win64-VS16/logs/access.log

And finally found:

POST /phpmyadmin/index.php?route=/import HTTP/1.1" 500 530

So the failure was definitely happening during the phpMyAdmin import request.

5. Check Laragon's FastCGI request limit

Because Laragon was using mod_fcgid, I searched its config:

grep -RniE "Fcgid|Timeout|LogLevel" \
/d/C-data/laragon/etc/apache2 \
/d/C-data/laragon/bin/apache/httpd-2.4.54-win64-VS16/conf 2>/dev/null

That led me to:

D:\C-data\laragon\etc\apache2\fcgid.conf

Inside I found:

FcgidIOTimeout 36000
FcgidConnectTimeout 16
FcgidMaxRequestLen 81310720

The important one was:

FcgidMaxRequestLen 81310720

That is only around 77.5 MiB.

My SQL file was:

ls -lh "/c/Users/Asus/Downloads/shabujglobal-crm (1).sql"

Output:

97M

So PHP allowed 512M, but Apache FastCGI only allowed around 77.5 MiB.

That mismatch can cause the request to fail before phpMyAdmin can properly process the upload.

6. Increase `FcgidMaxRequestLen`

Open:

D:\C-data\laragon\etc\apache2\fcgid.conf

Change:

FcgidMaxRequestLen 81310720

to:

FcgidMaxRequestLen 536870912

That gives FastCGI a 512 MiB request limit.

Then:

Save → Laragon → Restart All

and retry the import.

7. If the next error is “Maximum execution time of 300 seconds exceeded”

After fixing the request-size limit, I hit another possible bottleneck:

Fatal error: Maximum execution time of 300 seconds exceeded
in DbiMysqli.php

If you see this, do not edit DbiMysqli.php. That is only where the timeout becomes visible.

Instead, open:

D:\C-data\laragon\etc\apps\phpMyAdmin\config.inc.php

and add:

$cfg['ExecTimeLimit'] = 0;

If the file contains a closing ?>, add the line before it.

Then:

Save → Laragon → Restart All

and retry the import.

Setting ExecTimeLimit to 0 removes phpMyAdmin's execution-time limit for operations such as large imports.

In my debugging session, this was the latest issue I reached. I had not yet fully confirmed the final import after changing this setting, so treat this as the next configuration to verify if your import dies exactly at 300 seconds.

The main lesson

When phpMyAdmin gives you a generic 500 Internal Server Error while importing a large SQL file on Laragon, don't only check:

upload_max_filesize
post_max_size
memory_limit
max_execution_time

Also check these two layers:

FcgidMaxRequestLen

and:

$cfg['ExecTimeLimit']

In my case, the debugging path was basically:

97 MB SQL file
↓
PHP limits looked fine
↓
No useful PHP error log
↓
Apache access log confirmed /import returned 500
↓
FastCGI request limit was smaller than the SQL file
↓
After that, phpMyAdmin's 300-second execution limit became the next bottleneck

That is the part that can easily be missed: PHP may allow a large upload while Apache/FastCGI or phpMyAdmin still blocks it for a completely different reason.

And if you create a temporary phpinfo() file while debugging, delete it afterward.

Deploy Laravel and Vue to cPanel Automatically with GitHub Actions

Tahsin Abrar — Thu, 30 Jul 2026 11:36:52 +0000

Automatically Deploy Laravel and Vue to cPanel with GitHub Actions

Uploading a ZIP file to cPanel after every small code change becomes frustrating very quickly.

You fix a bug, build the Vue frontend, create an archive, open cPanel File Manager, upload it, extract it, run migrations, clear Laravel caches, and finally check whether the application still works.

The code change may take two minutes. The deployment takes much longer.

A better approach is:

Push the code to GitHub and let GitHub Actions build and deploy the application to cPanel automatically.

After the initial setup, deployment becomes:

git add .
git commit -m "Fix checkout issue"
git push origin main

GitHub Actions handles the remaining work.

The deployment architecture

This guide uses a push-based deployment:

The cPanel server does not clone or pull the private repository. Therefore, it does not need a GitHub deploy key, personal access token, or account-level GitHub SSH key.

GitHub Actions checks out its own repository with the workflow's built-in GITHUB_TOKEN. The workflow only needs a separate SSH key for this direction:

GitHub Actions → cPanel

This keeps the setup simpler and avoids storing an unnecessary GitHub repository credential on the production server.

What the workflow will do

Every push to the main branch will:

Check out the private repository.
Install Laravel's production dependencies.
Install frontend dependencies and build the Vue/Vite assets.
Package the application without .env, storage, or server-managed files.
Connect to cPanel through SSH.
Upload and extract the new application files.
Preserve the production .env, uploaded files, logs, and SSL challenge files.
Run database migrations and Laravel optimization commands.
Signal existing queue workers to restart.
Check a public production URL when one is configured.

This is a practical deployment for small and medium applications. It is not a zero-downtime or automatic-rollback system.

Quick reference (read this first)

Everything below is one GitHub secret. No separate "variables" — one place, one mental model, less context-switching.

Run each command where noted, take the output, paste it into the matching GitHub secret in Step 7. Replace PORT, HOST, and USER with your own values — get CPANEL_HOST, CPANEL_PORT, and CPANEL_USER first (rows 3–5), then use those same values in the commands below them.

Secret	What it is	Where to run it	Command
`CPANEL_USER`	cPanel username	cPanel Terminal	`whoami`
`CPANEL_HOST`	cPanel server hostname	cPanel dashboard	Look under General Information, or ask your host
`CPANEL_PORT`	SSH port	cPanel dashboard	Security → SSH Access (usually `22`)
`APP_DIR`	Absolute path to app folder	cPanel Terminal	`cd ~/example.com && pwd`
`PHP_BIN`	Path to CLI PHP executable	cPanel Terminal	`command -v php`
`CPANEL_SSH_PRIVATE_KEY`	Deploy SSH private key	Local machine	Generate once (Step 4): `ssh-keygen -t ed25519 -C "github-actions-to-cpanel" -f ~/.ssh/deploy-keys/cpanel_production -N ""` then read it: `cat ~/.ssh/deploy-keys/cpanel_production`
`CPANEL_KNOWN_HOSTS`	Verified SSH host fingerprint	Local machine	`ssh-keyscan -p PORT HOST > cpanel_known_hosts` then `cat cpanel_known_hosts` — e.g. `ssh-keyscan -p 22 server123.hosting-company.com > cpanel_known_hosts`
`APP_URL`	Public site URL	—	Your domain, e.g. `https://example.com`
`HEALTHCHECK_URL`	Optional public health-check URL	—	`APP_URL` + `/up`, e.g. `https://example.com/up`

CPANEL_KNOWN_HOSTS needs the real HOST and PORT filled in, not the placeholder text — that is the value most people get wrong (it fails as "Host key verification failed" later, see Common errors). Verify the fingerprint against your host before trusting it (Step 6 has the full command with ssh-keygen -lf).

Full explanation of each value, and why, is in Steps 1–7 below.

Before you start

You need:

A Laravel application using Vue and Vite.
A private GitHub repository.
composer.lock and package-lock.json committed to the repository.
SSH access to the cPanel account.
A domain whose document root can point to Laravel's public directory.
The correct command-line PHP executable for the cPanel account.

Some shared-hosting providers disable SSH, symbolic links, long-running queue workers, or custom document roots. Confirm those features with your hosting provider before continuing.

Step 1: Prepare the application directory

Open:

cPanel → Advanced → Terminal

Check the cPanel username and home directory:

whoami
echo "$HOME"

Create the Laravel application directory:

mkdir -p "$HOME/example.com"
cd "$HOME/example.com"
pwd

Example output:

/home/exampleuser/example.com

Save this complete path. It will become the GitHub variable:

APP_DIR=/home/exampleuser/example.com

Configure the domain document root as:

/home/exampleuser/example.com/public

Do not point the domain to the Laravel project root. Only the public directory should be web-accessible.

Step 2: Create the production `.env`

The workflow will never upload .env from GitHub.

Create the production file directly on cPanel:

cd "$HOME/example.com"

umask 077
touch .env
chmod 600 .env

nano .env

A minimal example looks like this:

APP_NAME="My Application"
APP_ENV=production
APP_KEY=base64:YOUR_APPLICATION_KEY
APP_DEBUG=false
APP_URL=https://example.com

LOG_CHANNEL=stack
LOG_LEVEL=error

DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=exampleuser_database
DB_USERNAME=exampleuser_dbuser
DB_PASSWORD=YOUR_DATABASE_PASSWORD

Add the mail, cache, session, queue, API, and other values required by your application.

Generate an application key from a trusted local copy of the project:

php artisan key:generate --show

Copy the generated value into the production .env.

Never replace an existing production APP_KEY unless you understand the consequences. Changing it can invalidate encrypted cookies and make existing encrypted data unreadable.

Step 3: Find the correct PHP executable

In cPanel Terminal, run:

command -v php
php -v

On some servers, the correct binary may look like:

/opt/cpanel/ea-php84/root/usr/bin/php

Test the selected binary:

/opt/cpanel/ea-php84/root/usr/bin/php -v

Save the working path as:

PHP_BIN=/opt/cpanel/ea-php84/root/usr/bin/php

Use the PHP version required by your project. The PHP version used to build Composer dependencies in GitHub Actions should match the production server as closely as possible.

Step 4: Generate the deployment SSH key

Generate this key on your trusted local computer, not inside the repository and not on the cPanel server.

mkdir -p "$HOME/.ssh/deploy-keys"
chmod 700 "$HOME/.ssh/deploy-keys"

Create an Ed25519 key pair:

ssh-keygen \
  -t ed25519 \
  -C "github-actions-to-cpanel" \
  -f "$HOME/.ssh/deploy-keys/cpanel_production" \
  -N ""

This creates:

cpanel_production       ← Private key
cpanel_production.pub   ← Public key

The key locations will be:

Private key → GitHub Actions secret
Public key  → cPanel authorized keys

The private key must never be committed to the repository.

Step 5: Authorize the public key in cPanel

Display the public key locally:

cat "$HOME/.ssh/deploy-keys/cpanel_production.pub"

Copy the complete line.

In cPanel, open:

Security
→ SSH Access
→ Manage SSH Keys
→ Import Key

Paste the public key and import it. Then select:

Manage → Authorize

Importing and authorizing may be separate actions in cPanel.

You can also add the public key from cPanel Terminal:

mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"

nano "$HOME/.ssh/authorized_keys"
chmod 600 "$HOME/.ssh/authorized_keys"

Paste the public key on its own line.

Optional key restrictions

After the deployment works, you may restrict the key in authorized_keys:

no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3... github-actions-to-cpanel

These options disable common SSH features that the deployment does not need. Test the normal key first because hosting configurations vary.

Test the connection

From your local computer, run:

ssh \
  -i "$HOME/.ssh/deploy-keys/cpanel_production" \
  -p YOUR_SSH_PORT \
  YOUR_CPANEL_USER@YOUR_CPANEL_HOST

Example:

ssh \
  -i "$HOME/.ssh/deploy-keys/cpanel_production" \
  -p 22 \
  exampleuser@server123.hosting-company.com

Do not continue until this connection works.

Step 6: Verify and save the SSH host key

Do not make the workflow trust whatever SSH key it receives during deployment.

From a trusted computer, collect the server's public host keys:

ssh-keyscan \
  -p YOUR_SSH_PORT \
  YOUR_CPANEL_HOST > cpanel_known_hosts

Display their fingerprints:

ssh-keygen \
  -lf cpanel_known_hosts \
  -E sha256

Verify the fingerprint with your hosting provider or hosting control panel. After verification, copy the complete contents of cpanel_known_hosts.

If the hosting provider later changes the server's SSH host key, the deployment will fail until this value is updated. That failure is safer than silently trusting an unexpected server.

Step 7: Add GitHub secrets

Open the repository:

Settings
→ Secrets and variables
→ Actions
→ Secrets

Add every value below as a secret (not a repository variable). One list, one context — the workflow only ever reads secrets.*.

Secret	Example / value
`CPANEL_SSH_PRIVATE_KEY`	Complete private deployment key
`CPANEL_KNOWN_HOSTS`	Verified contents of `cpanel_known_hosts`
`APP_DIR`	`/home/exampleuser/example.com`
`CPANEL_HOST`	`server123.hosting-company.com`
`CPANEL_PORT`	`22`
`CPANEL_USER`	`exampleuser`
`PHP_BIN`	`/opt/cpanel/ea-php84/root/usr/bin/php`
`APP_URL`	`https://example.com`
`HEALTHCHECK_URL`	`https://example.com/up` (optional)

Display the private key locally:

cat "$HOME/.ssh/deploy-keys/cpanel_production"

Copy the complete value, including:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

Do not paste the .pub key into CPANEL_SSH_PRIVATE_KEY.

CPANEL_KNOWN_HOSTS, APP_DIR, CPANEL_HOST, CPANEL_PORT, CPANEL_USER, PHP_BIN, APP_URL, and HEALTHCHECK_URL are not confidential by nature, but storing them as secrets keeps every deployment input in one place instead of split across vars and secrets.

APP_URL is the public application URL used during the frontend build. HEALTHCHECK_URL is optional; a lightweight public health endpoint is better than a page that requires authentication.

Optional production environment

On GitHub plans that support environments for private repositories, you can move the same secrets and variables into a protected environment named production. Then add this line to the deployment job:

environment: production

A protected environment can add approvals and restrict which branches may deploy. If your plan does not support those features for a private repository, repository-level secrets and variables still work.

Step 8: Add the GitHub Actions workflow

Create:

.github/workflows/deploy-cpanel.yml

Add the following workflow:

name: Deploy Laravel and Vue to cPanel

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: production-cpanel
  cancel-in-progress: false

env:
  APP_DIR: ${{ secrets.APP_DIR }}
  CPANEL_HOST: ${{ secrets.CPANEL_HOST }}
  CPANEL_PORT: ${{ secrets.CPANEL_PORT || '22' }}
  CPANEL_USER: ${{ secrets.CPANEL_USER }}
  PHP_BIN: ${{ secrets.PHP_BIN }}
  APP_URL: ${{ secrets.APP_URL }}
  HEALTHCHECK_URL: ${{ secrets.HEALTHCHECK_URL }}
  NODE_VERSION: "24"
  NODE_OPTIONS: --max-old-space-size=4096

jobs:
  build-and-deploy:
    name: Build and deploy production
    runs-on: ubuntu-latest
    timeout-minutes: 35

    steps:
      - name: Checkout repository
        uses: actions/checkout@v7
        with:
          fetch-depth: 1
          persist-credentials: false

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          coverage: none
          tools: composer:v2
          extensions: mbstring, xml, ctype, iconv, intl, pdo_mysql, bcmath, curl, fileinfo, gd, openssl, zip

      - name: Install production PHP dependencies
        env:
          COMPOSER_ALLOW_SUPERUSER: "1"
        run: |
          composer validate --no-check-publish

          composer install \
            --no-dev \
            --prefer-dist \
            --no-interaction \
            --no-progress \
            --optimize-autoloader

      - name: Set up Node.js
        uses: actions/setup-node@v7
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: npm
          cache-dependency-path: package-lock.json

      - name: Install frontend dependencies
        run: npm ci --no-audit --no-fund

      - name: Build frontend assets
        env:
          VITE_APP_URL: ${{ secrets.APP_URL }}
        run: npm run build

      - name: Verify the build
        run: |
          test -f artisan
          test -f vendor/autoload.php
          test -d public/build
          test -f public/build/manifest.json

      - name: Validate deployment configuration
        env:
          SSH_PRIVATE_KEY: ${{ secrets.CPANEL_SSH_PRIVATE_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.CPANEL_KNOWN_HOSTS }}
        run: |
          set -Eeuo pipefail

          : "${APP_DIR:?Missing APP_DIR variable}"
          : "${CPANEL_HOST:?Missing CPANEL_HOST variable}"
          : "${CPANEL_PORT:?Missing CPANEL_PORT variable}"
          : "${CPANEL_USER:?Missing CPANEL_USER variable}"
          : "${PHP_BIN:?Missing PHP_BIN variable}"
          : "${SSH_PRIVATE_KEY:?Missing CPANEL_SSH_PRIVATE_KEY secret}"
          : "${SSH_KNOWN_HOSTS:?Missing CPANEL_KNOWN_HOSTS secret}"

      - name: Configure SSH
        env:
          SSH_PRIVATE_KEY: ${{ secrets.CPANEL_SSH_PRIVATE_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.CPANEL_KNOWN_HOSTS }}
        run: |
          install -m 700 -d "$HOME/.ssh"

          printf '%s\n' "$SSH_PRIVATE_KEY" > "$HOME/.ssh/id_ed25519"
          chmod 600 "$HOME/.ssh/id_ed25519"

          printf '%s\n' "$SSH_KNOWN_HOSTS" > "$HOME/.ssh/known_hosts"
          chmod 600 "$HOME/.ssh/known_hosts"

      - name: Package the application
        run: |
          tar -czf /tmp/app-deploy.tar.gz \
            --exclude='./.git' \
            --exclude='./.github' \
            --exclude='./node_modules' \
            --exclude='./.env' \
            --exclude='./.env.*' \
            --exclude='./storage' \
            --exclude='./public/storage' \
            --exclude='./public/hot' \
            --exclude='./public/.well-known' \
            --exclude='./.user.ini' \
            --exclude='./php.ini' \
            --exclude='./tests' \
            .

      - name: Deploy to cPanel
        run: |
          set -Eeuo pipefail

          SSH=(
            ssh
            -i "$HOME/.ssh/id_ed25519"
            -p "$CPANEL_PORT"
            -o BatchMode=yes
            -o ConnectTimeout=15
            -o IdentitiesOnly=yes
            -o StrictHostKeyChecking=yes
            -o UserKnownHostsFile="$HOME/.ssh/known_hosts"
            "$CPANEL_USER@$CPANEL_HOST"
          )

          SCP=(
            scp
            -i "$HOME/.ssh/id_ed25519"
            -P "$CPANEL_PORT"
            -o BatchMode=yes
            -o ConnectTimeout=15
            -o IdentitiesOnly=yes
            -o StrictHostKeyChecking=yes
            -o UserKnownHostsFile="$HOME/.ssh/known_hosts"
          )

          "${SSH[@]}" \
            "mkdir -p '$APP_DIR' && test -f '$APP_DIR/.env' && test -x '$PHP_BIN'" || {
              echo '::error::APP_DIR, production .env, or PHP_BIN is invalid.'
              exit 1
            }

          "${SSH[@]}" \
            "cd '$APP_DIR' && if [ -f artisan ]; then '$PHP_BIN' artisan down --retry=60 || true; fi"

          bring_application_up() {
            "${SSH[@]}" \
              "cd '$APP_DIR' && if [ -f artisan ]; then '$PHP_BIN' artisan up; fi"
          }

          remote_update_started=0

          handle_failure() {
            status=$?

            if [ "$status" -ne 0 ]; then
              if [ "$remote_update_started" -eq 0 ]; then
                bring_application_up || true
              else
                echo '::warning::Deployment failed after the remote update started.'
                echo '::warning::The application may remain in maintenance mode for inspection.'
              fi
            fi
          }

          trap handle_failure EXIT

          "${SCP[@]}" \
            /tmp/app-deploy.tar.gz \
            "$CPANEL_USER@$CPANEL_HOST:$APP_DIR/app-deploy.tar.gz"

          remote_update_started=1

          "${SSH[@]}" \
            "APP_DIR='$APP_DIR' PHP_BIN='$PHP_BIN' bash -se" <<'REMOTE'
          set -Eeuo pipefail

          cd "$APP_DIR"

          test -f app-deploy.tar.gz

          tar -xzf app-deploy.tar.gz --overwrite
          rm app-deploy.tar.gz

          test -f .env
          test -f artisan
          test -f vendor/autoload.php
          test -f public/build/manifest.json

          mkdir -p \
            storage/app/public \
            storage/framework/cache/data \
            storage/framework/sessions \
            storage/framework/views \
            storage/logs \
            bootstrap/cache

          chmod -R ug+rwX storage bootstrap/cache

          "$PHP_BIN" artisan package:discover --ansi
          "$PHP_BIN" artisan config:clear
          "$PHP_BIN" artisan route:clear
          "$PHP_BIN" artisan view:clear
          "$PHP_BIN" artisan event:clear || true
          "$PHP_BIN" artisan migrate --force

          if [ ! -L public/storage ]; then
            "$PHP_BIN" artisan storage:link
          fi

          "$PHP_BIN" artisan optimize
          "$PHP_BIN" artisan queue:restart || true

          chmod -R ug+rwX storage bootstrap/cache
          REMOTE

          bring_application_up
          trap - EXIT

      - name: Check the production URL
        if: ${{ secrets.HEALTHCHECK_URL != '' }}
        run: |
          curl \
            --fail \
            --silent \
            --show-error \
            --location \
            --retry 5 \
            --retry-delay 5 \
            --retry-connrefused \
            --max-time 30 \
            "$HEALTHCHECK_URL" > /dev/null

      - name: Write deployment summary
        run: |
          {
            echo '## Deployment completed'
            echo
            echo "- Directory: \`$APP_DIR\`"
            echo '- Composer dependencies built on GitHub Actions'
            echo '- Vue and Vite assets built on GitHub Actions'
            echo '- Production .env and storage preserved'
          } >> "$GITHUB_STEP_SUMMARY"

The example uses PHP 8.4 and Node.js 24. Change both versions to match your application and production server.

The workflow gives GITHUB_TOKEN only read access to repository contents. It also disables persisted checkout credentials because the remaining steps do not need authenticated Git commands.

Step 9: Run the first deployment

Commit the workflow:

git add .github/workflows/deploy-cpanel.yml
git commit -m "Add automatic cPanel deployment"
git push origin main

Open:

GitHub repository → Actions

Select the workflow and follow the logs.

After it finishes, verify the application from cPanel:

cd "$HOME/example.com"

PHP_BIN=/opt/cpanel/ea-php84/root/usr/bin/php

"$PHP_BIN" artisan about
"$PHP_BIN" artisan migrate:status

ls -la public/build
ls -la public/storage

Then open the production URL.

What the workflow preserves

The deployment archive excludes:

.env
.env.*
storage/
public/storage/
public/.well-known/
.user.ini
php.ini

This prevents the workflow from replacing:

Production credentials and API keys.
User-uploaded files.
Application logs and sessions.
The public storage symbolic link.
Server-managed SSL challenge files.
Hosting-specific PHP configuration files.

The workflow includes Composer's vendor directory and Vite's public/build directory because both are built on GitHub Actions before deployment.

Important security notes

Do not add a GitHub deploy key to cPanel for this workflow

The server does not run git pull. GitHub Actions checks out the repository and sends a prepared archive to cPanel.

Adding a cPanel-to-GitHub key would create an unnecessary credential on the production server. If the server were compromised, that credential could allow the attacker to clone the repository it belongs to.

Never put secrets in `VITE_*`

Values prefixed with VITE_ may become part of the browser's JavaScript bundle.

Safe examples:

VITE_APP_NAME
VITE_APP_URL

Unsafe examples:

VITE_DB_PASSWORD
VITE_STRIPE_SECRET
VITE_OPENAI_API_KEY

Only put public frontend configuration in VITE_* variables.

Protect the production workflow

A person who can modify a production workflow may try to use the secrets available to that workflow.

At minimum:

Protect the main branch.
Require pull requests and reviews.
Require review for changes inside .github/workflows/.
Consider a CODEOWNERS rule for workflow files.
Use a protected production environment when your GitHub plan supports it.
Keep permissions: contents: read unless more access is genuinely required.
Review third-party actions and consider pinning them to full commit SHAs.
Use Dependabot to keep action versions updated.

Back up before risky migrations

The workflow runs:

php artisan migrate --force

A code rollback does not restore deleted or modified database data. Back up the database before destructive or difficult-to-reverse migrations.

`queue:restart` does not start a queue worker

The command only tells existing workers to exit gracefully after finishing their current job. A process manager, hosting feature, or scheduled command must already be running the workers.

On shared hosting, you may need a cPanel cron job instead of a continuously running worker.

Common errors

`Permission denied (publickey)`

Check that:

The deployment public key was imported and authorized in cPanel.
The matching private key was saved in CPANEL_SSH_PRIVATE_KEY.
CPANEL_USER, CPANEL_HOST, and CPANEL_PORT are correct.
The hosting account allows SSH access.

Test locally:

ssh \
  -vvv \
  -i "$HOME/.ssh/deploy-keys/cpanel_production" \
  -p YOUR_SSH_PORT \
  YOUR_CPANEL_USER@YOUR_CPANEL_HOST

`Host key verification failed`

The value in CPANEL_KNOWN_HOSTS does not match the server.

Do not disable strict host checking. Confirm whether the hosting provider intentionally changed the SSH host key, verify the new fingerprint, and then update the secret.

`Production .env is missing`

Create .env inside APP_DIR, not inside public:

cd /home/YOUR_CPANEL_USER/YOUR_APP_DIRECTORY

touch .env
chmod 600 .env
nano .env

`public/build/manifest.json` is missing

Run locally:

npm ci
npm run build

Confirm that Vite creates:

public/build/manifest.json

If your project uses a different Vite output directory, update the workflow checks.

Laravel returns HTTP 500

Check the log:

tail -n 100 storage/logs/laravel.log

Then inspect the environment, permissions, PHP extensions, database connection, and cached configuration.

If a failed deployment left the application in maintenance mode, bring it back only after fixing the problem:

"$PHP_BIN" artisan up

`storage:link` fails

Check whether public/storage already exists as a normal directory or whether the hosting provider blocks symbolic links:

ls -la public/storage

Remove or rename an incorrect directory only after confirming it does not contain files that must be preserved.

A note about deleted files

This workflow extracts the new archive over the existing application.

Files with matching names are replaced, but a file deleted from Git may remain on the server. This is one limitation of the simple archive-based approach.

For many small applications, that trade-off is acceptable. When the application grows, move to release directories and a current symbolic link:

releases/
├── 20260730-120001/
├── 20260730-123500/
└── 20260730-130800/

current -> releases/20260730-130800

That architecture makes atomic switching, cleanup, and code rollback easier, but it requires a more advanced deployment workflow and a shared storage directory.

Conclusion

Manual cPanel deployment works, but it becomes slow and error-prone when deployments are frequent.

With this setup, the regular process becomes:

git add .
git commit -m "Describe the change"
git push origin main

GitHub Actions will:

Check out the private repository with its built-in token.
Install Laravel's production dependencies.
Build the Vue and Vite assets.
Upload the application to cPanel through SSH.
Preserve .env, storage, uploads, logs, and server-managed files.
Run migrations and optimize Laravel.
Signal existing queue workers to restart.
Check the production website.

Most importantly, the cPanel server does not need access to the private GitHub repository. It only receives the deployment created by GitHub Actions.

The first setup requires care around SSH keys, host verification, server paths, PHP versions, and production secrets. After that, deployments become repeatable, predictable, and much less stressful.

Mid-Year Backend Reset: My H2 Goals for Speed, Security, and Better Docs

Tahsin Abrar — Fri, 03 Jul 2026 20:47:52 +0000

July always feels like a natural pause point.

The first half of the year is already behind us. Some features shipped. Some bugs were fixed. Some ideas worked well. A few things probably stayed in the backlog longer than expected.

For me, this is not about making a huge roadmap or setting unrealistic goals. It is more about asking a simple question:

What backend systems do I want to make better before the year ends?

After thinking about my recent work, I found myself coming back to three areas:

Performance
Security
Documentation

These are not flashy goals. They are not always visible to users. But they are the kind of improvements that make a backend codebase healthier, safer, and easier to work with over time.

Why I Like Doing a Mid-Year Engineering Reset

At the start of the year, goals often feel exciting. We plan new projects, new features, new tools, and new habits.

But by the middle of the year, reality has already happened.

Urgent fixes appear. Product priorities change. Some technical debt gets ignored because there is always something more important to ship.

That is why I like the idea of an H2 engineering reset.

It gives me a chance to review the systems I work on with a fresh mind. Instead of only asking, “What should we build next?” I can also ask:

What is slowing us down?
What keeps breaking?
What is hard to understand?
What would make the next six months easier?

This kind of reset is useful because backend quality is not built in one big moment. It is built through small, careful improvements repeated over time.

Goal 1: Improve Performance

Performance is one of those things that is easy to ignore until users start feeling the pain.

A page loads a little slower. An API takes a few extra seconds. A database query works fine with 100 records but becomes painful with 100,000 records.

At first, these issues may not look urgent. But slowly, they make the product feel heavy.

For the second half of the year, I want to be more intentional about backend performance.

Where I Want to Focus

For Laravel projects, this means looking closely at a few common areas:

Slow database queries
Missing indexes
N+1 query problems
Heavy API responses
Unnecessary background jobs
Cacheable data that is being fetched again and again

A simple example is a dashboard page.

Maybe the dashboard shows user stats, recent orders, payment data, and notifications. At first, everything works fine. But after a few months, the page starts taking longer to load.

The problem may not be the whole system. It may be one query that loads too much data, or one relationship that is not eager loaded properly.

Small fixes can make a big difference.

Practical Steps I Want to Take

My performance reset will be simple:

First, I want to identify the slowest endpoints. I do not want to guess. I want to measure.

Then, I want to review the database queries behind those endpoints. Are they doing too much? Are they using indexes properly? Are they loading relationships in a clean way?

Finally, I want to use caching where it actually makes sense.

Not everything needs to be cached. But data that does not change often should not be rebuilt on every request.

The goal is not to make everything perfect. The goal is to make the most used parts of the system faster and more reliable.

Goal 2: Strengthen Security

Security is not a one-time task.

It is not something we finish after adding authentication or installing a package. It needs regular review, especially as an application grows.

New routes are added. New permissions are created. New integrations are connected. Over time, small gaps can appear.

That is why security is my second H2 backend goal.

The Areas I Want to Recheck

In Laravel apps, I want to review things like:

Authentication flow
Authorization rules
Role and permission checks
API token usage
Form request validation
File upload handling
Sensitive data exposure
Environment configuration

One real-life situation many developers face is permission logic becoming scattered.

For example, one controller checks if a user is an admin. Another checks if the user owns the resource. Another uses a policy. Another has the logic written directly inside the method.

Everything may work, but it becomes harder to trust.

When permission logic is not consistent, future changes become risky.

Practical Steps I Want to Take

For the second half of the year, I want to clean up authorization logic and move more checks into proper Laravel policies or gates where possible.

I also want to review validation rules more carefully.

Good validation is not only about showing nice error messages. It protects the system from bad data, unexpected input, and edge cases.

Another important step is checking what data gets returned from APIs.

Sometimes an API response includes more fields than the frontend actually needs. That can accidentally expose internal or sensitive information.

So the security goal is simple:

Make access clear, input strict, and output intentional.

That one sentence is easy to remember, and it covers a lot.

Goal 3: Improve Documentation

Documentation is usually the easiest thing to delay.

When we are busy, we tell ourselves, “I will document this later.”

But later often becomes never.

Then after a few months, someone asks:

“How does this job work?”
“Why does this API behave this way?”
“What happens when this webhook fails?”
“Where is this config coming from?”

And suddenly, the missing documentation becomes expensive.

For H2, I want to treat documentation as part of the backend system, not as an extra task.

What I Want to Document Better

I do not want to write huge documents that nobody reads. I want useful documentation that helps developers move faster.

That includes:

API behavior
Important business rules
Queue jobs
Scheduled commands
Webhook flows
Environment variables
Setup steps
Common debugging notes

For example, if a payment webhook updates an order status, that flow should be easy to understand.

A developer should be able to read a short note and know:

Which event comes from the payment provider
Which route receives it
Which job processes it
Which tables are updated
What happens if the webhook fails

This does not need a 20-page document. A clear Markdown file can be enough.

Practical Steps I Want to Take

My documentation reset will start with the most confusing parts of the system.

I want to document the areas where I have previously had to explain the same thing more than once. That is usually a good sign that documentation is missing.

I also want to keep docs close to the code when possible.

For example:

API notes inside an /docs folder
Setup instructions in README.md
Complex service explanations near the related module
Short comments only where the code needs context

Good documentation does not explain every line of code. It explains the decisions, flows, and important details that are not obvious.

Keeping the Reset Realistic

The biggest mistake with planning is trying to fix everything at once.

That usually leads to frustration.

So I want to keep this H2 reset small and realistic.

Instead of saying, “Improve the whole backend,” I can say:

Optimize the top 3 slowest endpoints
Review authorization for the most sensitive modules
Document the 5 most confusing backend flows

That feels much more doable.

It also creates visible progress.

A backend system improves when we choose specific problems and solve them carefully.

Redis on Windows with Laragon and Laravel: The PATH Issue That Looks Like a Redis Issue

Tahsin Abrar — Fri, 26 Jun 2026 13:19:09 +0000

A few days ago, I was working on a Laravel project on Windows. The project needed Redis for cache and queue handling, and since I was using Laragon, I thought the setup would be simple.

Laragon already had Redis inside its bin folder. I started Redis, opened the terminal, and ran:

redis-cli ping

It returned:

PONG

Perfect.

Then I moved to my Laravel project folder, opened Git Bash, and tried the same command again.

redis-cli ping

This time, I got:

bash: redis-cli: command not found

At first, it looked like Redis was not installed properly. Then I wondered if Redis only worked inside Laragon’s www folder. Maybe my Laravel project was outside the correct directory?

But the real problem was much simpler.

It was not a Redis problem.

It was not a Laravel problem.

It was not a project folder problem.

It was a PATH problem.

In this post, I’ll walk through the full Redis setup on Windows using Laragon, how to make redis-cli work from Git Bash, and how to connect it properly with a Laravel project.

The Real Situation

My Laravel project was not inside Laragon’s default www folder. It was somewhere like this:

C:\Users\Asus\Downloads\aromablendbd

But Laragon was installed here:

D:\C-data\laragon

When I opened Laragon’s own terminal or Cmder, this worked:

redis-cli ping

Output:

PONG

But inside Git Bash from my Laravel project folder, the same command failed:

bash: redis-cli: command not found

This is where the confusion started.

Redis itself does not care where your Laravel project is located. Redis runs as a server, usually on:

127.0.0.1:6379

So any project can connect to it, whether the project is inside www, Downloads, Desktop, or another drive.

The only issue was that Git Bash did not know where redis-cli.exe was located.

Laragon’s terminal automatically adds Laragon tools to its PATH. Git Bash does not.

Step 1: Find the Redis CLI File

First, we need to find the actual redis-cli.exe file inside Laragon.

In Git Bash, run:

find /d/C-data/laragon/bin -iname "redis-cli.exe"

Your Laragon path may be different. For example, if Laragon is installed in C:\laragon, you may need:

find /c/laragon/bin -iname "redis-cli.exe"

In my case, the result was:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe

This confirmed that Redis CLI was already installed. Git Bash simply could not find it globally.

Step 2: Test Redis Using the Full Path

Before changing PATH settings, it’s always good to test the command directly.

I ran:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe ping

And the output was:

PONG

That was the important moment.

It confirmed three things:

Redis was installed.

Redis server was running.

Git Bash could reach Redis when I used the full path.

So the server was fine. The port was fine. The Laravel folder location was fine.

Only the command shortcut was missing.

Step 3: Add Redis CLI to Git Bash PATH

To make redis-cli available from any folder in Git Bash, I added the Redis folder to ~/.bashrc.

Here is the command I used:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

After that, I tested again:

redis-cli ping

This time, it worked:

PONG

Now I could run redis-cli from any folder, including my Laravel project folder.

This is the clean fix for the redis-cli: command not found issue in Git Bash.

A Small Redis CLI Mistake That Can Confuse You

At one point, I entered the Redis shell by running:

redis-cli

Then the terminal changed to something like this:

127.0.0.1:6379>

Inside this prompt, I tried:

redis-cli ping

That was wrong.

When you are inside the Redis shell, you should only write Redis commands.

Correct:

ping

Output:

PONG

Wrong:

redis-cli ping

Why?

Because redis-cli is a terminal command. It starts the Redis command-line tool.

But once you are already inside Redis CLI, you only need to type Redis commands like:

ping
set name laragon
get name
exit

So there are two valid ways to test Redis.

From the normal terminal:

redis-cli ping

Or from inside the Redis shell:

redis-cli

Then:

ping

Both are correct, but they are used in different places.

Step 4: Make Sure Redis Server Is Running

If you installed the full version of Laragon, Redis is usually included inside the Laragon bin directory.

A common Redis path looks like this:

C:\laragon\bin\redis\redis-x64-3.2.100

Or in my case:

D:\C-data\laragon\bin\redis\redis-x64-5.0.14.1

You can start Redis by running:

redis-server.exe

Or from Git Bash, using the full path:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-server.exe

Once the Redis server is running, keep that terminal open.

To stop the server later, press:

Ctrl + C

Laragon may also let you manage Redis from its menu depending on your installation.

One important note: Redis native Windows support is limited, and many Windows setups use older Redis builds. For the latest Redis versions, Docker, WSL, or Laradock can be a better option. But for local Laravel development, Laragon’s Redis works well enough in many cases.

Step 5: Configure Laravel `.env`

After Redis worked in the terminal, the next step was Laravel.

In the Laravel project, I opened the .env file and checked the Redis settings.

For my setup, I used:

REDIS_CLIENT=predis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

If you want to use Redis for cache, also check your cache setting.

For newer Laravel versions:

CACHE_STORE=redis

For older Laravel versions:

CACHE_DRIVER=redis

The key point is this:

Laravel does not need the redis-cli command to connect to Redis.

Laravel connects to Redis through PHP using the host and port:

127.0.0.1:6379

So even if redis-cli was not available in Git Bash, Laravel could still connect if the Redis client package or PHP extension was correctly installed.

Step 6: Install Laravel Dependencies

If this is an existing Laravel project, run:

composer install

This installs the dependencies listed in composer.json.

In my case, Laravel was configured to use Predis:

REDIS_CLIENT=predis

But when I tested Redis in Laravel, I got this error:

Class "Predis\Client" not found

That means Laravel wanted to use Predis, but the package was not installed.

The fix was simple:

composer require predis/predis

After installing Predis, I cleared Laravel’s cached config:

php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

This step is important because Laravel may keep old .env or config values in cache.

Predis vs PhpRedis

Laravel can use Redis in two common ways.

The first option is Predis.

REDIS_CLIENT=predis

For this, install the Composer package:

composer require predis/predis

This is often the easiest option when you are working on Windows and want a quick local setup.

The second option is PhpRedis.

REDIS_CLIENT=phpredis

For this, you need the PHP Redis extension enabled.

In Laragon, the Redis PHP extension does not always come enabled by default. You may need to download the correct php_redis.dll file that matches your PHP version, architecture, and thread-safety build.

You can check your PHP version from Laragon. Then download the matching Redis extension DLL from PECL:

https://pecl.php.net/package/redis

After downloading, copy:

php_redis.dll

Into your PHP extension folder, for example:

C:\laragon\bin\php\php-8.x.x\ext

Then add this line to your php.ini file:

extension=php_redis.dll

Restart Laragon after making the change.

For many local projects, Predis is simpler. For better performance in some production setups, PhpRedis is commonly used.

Step 7: Test Redis from Laravel Tinker

Now came the final test.

From the Laravel project folder, I ran:

php artisan optimize:clear
php artisan tinker

Inside Tinker, I first tried:

Redis::connection()->ping();

But I got:

Class "Redis" not found

This does not always mean Redis is broken. It can simply mean the Redis facade was not imported in Tinker.

The safer way is to use the full namespace:

\Illuminate\Support\Facades\Redis::connection()->ping();

Or use Laravel’s service container:

app('redis')->connection()->ping();

Expected output:

"PONG"

When I saw "PONG" from Laravel Tinker, the setup was finally complete.

At that point, Redis was working in three places:

From Laragon terminal.

From Git Bash.

From Laravel itself.

Common Errors and What They Really Mean

`bash: redis-cli: command not found`

This means your terminal cannot find redis-cli.exe.

It does not mean Redis is not installed.

Fix it by adding the Redis folder to Git Bash PATH:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

Then test:

redis-cli ping

`Class "Predis\Client" not found`

This means Laravel is using Predis, but the package is missing.

Fix:

composer require predis/predis
php artisan optimize:clear

`Class "Redis" not found`

This may happen in Tinker when the Redis facade is not imported.

Use the full namespace:

\Illuminate\Support\Facades\Redis::connection()->ping();

Or:

app('redis')->connection()->ping();

Redis Works in `www` but Not in Another Folder

This is usually not a folder issue.

Laragon terminal automatically sets PATH for Laragon tools. Git Bash does not.

Redis runs on:

127.0.0.1:6379

So your Laravel project can be anywhere as long as Redis is running and Laravel is configured correctly.

Final Working Setup

Here is the final setup that worked for me.

Redis CLI path:

/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1/redis-cli.exe

Git Bash PATH fix:

echo 'export PATH="$PATH:/d/C-data/laragon/bin/redis/redis-x64-5.0.14.1"' >> ~/.bashrc
source ~/.bashrc

Redis terminal test:

redis-cli ping

Expected:

PONG

Laravel .env:

REDIS_CLIENT=predis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
CACHE_STORE=redis

Install Predis:

composer require predis/predis

Clear Laravel config:

php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

Test in Tinker:

php artisan tinker

Then:

\Illuminate\Support\Facades\Redis::connection()->ping();

Expected:

"PONG"

How to Create a GitHub Pull Request from the Terminal

Tahsin Abrar — Tue, 23 Jun 2026 09:04:54 +0000

Pull Requests are a normal part of working with GitHub. You write code in a branch, push it to GitHub, then open a Pull Request so your team can review and merge it.

Most developers create Pull Requests from the GitHub website. That works fine.

But once you get comfortable with the terminal, you can do the whole flow without leaving your editor or command line.

In this post, we will go through a simple and practical workflow:

update your local main branch
create a new feature branch
commit your changes
push the branch to GitHub
create a Pull Request from the terminal using GitHub CLI

Let’s use a real example: you are building a login page.

First, Know the Difference: `git pull` vs Pull Request

A lot of beginners get confused here.

git pull and Pull Request are not the same thing.

`git pull`

git pull means you are taking the latest code from GitHub and bringing it into your local project.

Example:

git pull origin main

This updates your local branch with the latest code from the remote main branch.

Pull Request

A Pull Request means you are asking to merge your branch changes into another branch, usually main or develop.

So the simple idea is:

git pull  = bring latest code to your computer
Pull Request = ask to merge your code into main

To create a Pull Request from the terminal, the usual flow is:

push your branch → create PR with GitHub CLI

Step 1: Update Your Main Branch

Before starting new work, always get the latest code from the main branch.

git checkout main
git pull origin main

This helps you avoid working on old code.

Think of it like this: before building your new feature, you are making sure your project is fresh and up to date.

Step 2: Create a New Branch

Now create a new branch for your work.

git checkout -b feature/login-page

Here, feature/login-page is your working branch.

Good branch names are short, clear, and meaningful.

Examples:

feature/navbar
fix/login-error
update/readme
feature/login-page

A clear branch name helps your teammates understand what you are working on before they even open the code.

Step 3: Make Your Code Changes

Now do your actual work.

For example, you may add:

a login page layout
email and password fields
a submit button
basic styling

After changing the code, check the current Git status:

git status

This shows which files were changed, added, or deleted.

Step 4: Add Your Files

To add all changed files:

git add .

The . means Git will add all changed files in the current project.

If you only want to add one file, use the file path:

git add src/App.jsx

This is useful when you changed many files but only want to commit some of them.

Step 5: Commit Your Changes

Now create a commit:

git commit -m "Add login page UI"

A good commit message should be short but clear.

Good examples:

git commit -m "Fix navbar responsiveness"
git commit -m "Update README installation steps"
git commit -m "Add user login form"

Avoid unclear messages like:

git commit -m "changes"
git commit -m "update"
git commit -m "fix"

Your future self and your teammates will thank you for writing clear commit messages.

Step 6: Push Your Branch to GitHub

Now push your branch to GitHub:

git push -u origin feature/login-page

You can also push the current branch like this:

git push -u origin HEAD

This is very handy because you do not need to type the full branch name.

After this, your local branch exists on GitHub too.

Step 7: Install GitHub CLI

To create a Pull Request from the terminal, you need GitHub CLI.

GitHub CLI gives you the gh command.

On Windows

Open PowerShell or Windows Terminal and run:

winget install --id GitHub.cli --source winget

After installing, close the terminal and open a new one.

Then check:

gh --version

On macOS

If you use Homebrew, run:

brew install gh

Then check:

gh --version

If you see the version number, GitHub CLI is installed correctly.

Step 8: Login to GitHub CLI

You only need to do this once:

gh auth login

You will see some options. In most cases, choose:

GitHub.com
HTTPS
Yes
Login with a web browser

A browser window may open for login and authorization.

After login, check if everything is working:

gh auth status

Once you are logged in, you can create Pull Requests from the terminal without opening the GitHub website.

Step 9: Create a Pull Request from the Terminal

The easiest way is interactive mode:

gh pr create

GitHub CLI will ask you questions like:

Title:
Body:
Base branch:

The base branch is usually:

main

Or, if your team uses develop, then use:

develop

After you answer the questions, GitHub CLI creates the Pull Request and shows you the PR URL.

Create a Pull Request in One Command

You can also create the Pull Request in one line.

gh pr create --base main --head feature/login-page --title "Add login page UI" --body "This PR adds the login page UI with form fields and basic styling."

Let’s understand this command:

--base main

This is the branch where you want to merge your code.

--head feature/login-page

This is your feature branch.

--title

This is the Pull Request title.

--body

This is the Pull Request description.

If you are already inside the feature branch, you can skip --head:

gh pr create --base main --title "Add login page UI" --body "This PR adds the login page UI with form fields and basic styling."

What Should You Write in a Pull Request?

A good Pull Request should explain two things:

What changed?
How did you test it?

Here is a simple example.

PR Title

Add login page UI

PR Body

## Summary
- Added login page layout
- Added email and password input fields
- Added submit button styling

## Testing
- Ran the app locally
- Checked the login page in browser

This is clear, professional, and easy to review.

Your reviewer does not need to guess what you did.

Best Way to Write a Multiline PR Body

Sometimes you want a clean Pull Request body with headings and bullet points.

You may try to paste multiline Markdown directly inside --body, but different shells can behave differently.

The safest and cleanest way is to use a body file.

Create a file named:

pr-body.md

Put it in your project root directory:

my-project/
├── src/
├── public/
├── package.json
├── README.md
└── pr-body.md

Inside pr-body.md, write:

## Summary
- Added login page layout
- Added email and password fields
- Added submit button styling

## Testing
- Ran the app locally
- Checked login page in browser

Then create the Pull Request:

gh pr create --base main --head feature/login-page --title "Add login page UI" --body-file pr-body.md

This is usually the best option for real projects.

It keeps your command clean and your PR description easy to edit.

After creating the Pull Request, you can delete pr-body.md if you do not want to keep it in the project.

One-Line Multiline Body Without a File

If you really want to write the body directly in the command, here are safe options.

Bash, Git Bash, or macOS Terminal

gh pr create --base main --head feature/login-page --title "Add login page UI" --body $'## Summary\n- Added login page layout\n- Added email and password fields\n\n## Testing\n- Ran the app locally\n- Checked login page in browser'

Here, \n means a new line.

Windows PowerShell

gh pr create --base main --head feature/login-page --title "Add login page UI" --body "## Summary`n- Added login page layout`n- Added email and password fields`n`n## Testing`n- Ran the app locally`n- Checked login page in browser"

In PowerShell, newline is written as:

`n

Still, for most real work, I recommend using --body-file.

It is simpler and less error-prone.

Check Your Pull Request

After creating the Pull Request, you can check its status:

gh pr status

To see Pull Requests in the repository:

gh pr list

To view the current branch’s Pull Request:

gh pr view

To open it in the browser:

gh pr view --web

Opening the browser is optional. You do not need it to create the PR.

The Full Practical Workflow

Here is the complete flow you can use every day:

git checkout main
git pull origin main

git checkout -b feature/my-work

# after code changes
git status
git add .
git commit -m "Add my work"
git push -u origin HEAD

gh pr create --base main --title "Add my work" --body "Added my work and tested locally."

For a cleaner Pull Request body:

gh pr create --base main --title "Add my work" --body-file pr-body.md

That is the core workflow.

Common Problems and Fixes

Problem 1: `gh: command not found`

This means GitHub CLI is not installed, or your terminal has not refreshed yet.

On Windows:

winget install --id GitHub.cli --source winget

Then close the terminal and open it again.

On macOS:

brew install gh

Then check:

gh --version

Problem 2: You Are Not Logged In

If you see a message saying you are not logged in, run:

gh auth login

Then check:

gh auth status

Problem 3: Current Branch Is Not Pushed

If GitHub CLI says your branch is not pushed yet, run:

git push -u origin HEAD

Then try again:

gh pr create

Problem 4: Pull Request Is Created from the Wrong Branch

First, check your current branch:

git branch --show-current

If you are on the wrong branch, switch to the correct one:

git checkout feature/login-page

Then create the Pull Request:

gh pr create --base main

Stop Guessing in Controllers: Debug MySQL Directly

Tahsin Abrar — Wed, 20 May 2026 21:33:32 +0000

Every backend developer has done this at some point.

A request fails.

Something is not inserting into the database.

And suddenly the codebase turns into this:

dd($request->all());

dd($user);

dd($campaign);

Log::info($query);

You add logs in controllers.

Then services.

Then repositories.

Then queue workers.

Then event listeners.

And after two hours, you are still confused.

Because the real problem is not where you are looking.

The Day I Realized Controller Debugging Wasn’t Enough

A few months ago, a developer on a team I worked with faced a strange issue.

A simple form submission was supposed to:

create a user
assign a campaign
generate a lead
push a welcome email into queue
write an activity log

Pretty normal workflow.

But randomly, some users were being created without campaign data.

Sometimes the queue job worked.

Sometimes it didn’t.

Sometimes the transaction rolled back silently.

The first reaction?

Start adding logs everywhere.

Inside controllers:

Log::info('Controller hit');

Inside services:

Log::info('Campaign assigned');

Inside queue workers:

Log::info('Email queued');

Inside transactions:

DB::beginTransaction();

The code became a forest of debugging statements.

Still no clear answer.

The Real Problem

Here’s what most developers forget:

No matter how beautiful your architecture is…

No matter whether you use:

Laravel
Raw PHP
Node.js
Python
Java

At the end of the day, every query goes to one place:

MySQL.

Always.

Your application is just the messenger.

The database sees everything.

That realization changes how you debug systems.

Instead of Guessing, Watch the Database Directly

The moment we enabled MySQL General Query Log, everything became obvious.

We literally watched the queries execute live.

One terminal command showed the full story.

SET GLOBAL general_log = 'ON';

Then:

tail -f /var/lib/mysql/hostname.log

And suddenly we could see:

INSERT INTO users ...

UPDATE campaigns ...

ROLLBACK;

That last line explained everything.

The transaction was rolling back because another process locked a table for a few seconds.

No controller log would have shown the full picture that clearly.

This Is Why Framework-Level Debugging Often Fails

Modern applications are no longer simple.

A single request may involve:

queues
events
transactions
scheduled jobs
caching
background workers
third-party APIs

By the time you debug from inside the controller, the actual issue may already be happening somewhere else entirely.

This is why developers sometimes spend hours debugging “application logic” when the real problem is:

a deadlock
a lock wait
a slow query
missing index
rollback
transaction conflict

And MySQL already knows all of this.

The Most Useful MySQL Debugging Tools

Honestly, there are four MySQL features every backend developer should know.

Not just DBAs.

Actual application developers.

Because these tools solve real-world production headaches.

1. General Query Log

See everything.

This is the closest thing to “watching the database think.”

Enable it:

SET GLOBAL general_log = 'ON';

Now every query gets logged.

You can literally submit a form and watch the database flow in real time.

This becomes incredibly useful when:

one request touches multiple tables
transactions fail
duplicate queries happen
hidden queries execute behind ORM magic

Especially in large Laravel applications where Eloquent sometimes hides too much.

2. Slow Query Log

Find hidden performance problems.

This one saves applications.

Seriously.

Sometimes developers optimize controllers endlessly while the real problem is one terrible query.

Enable it:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

Now MySQL logs anything slower than one second.

This helps identify:

missing indexes
N+1 problems
huge scans
inefficient joins

I once saw a dashboard drop from 12 seconds to under 800ms just because a slow query log exposed a missing index.

The application code itself was completely fine.

3. InnoDB Status

Understand deadlocks & locks.

This command feels like magic the first time you use it.

SHOW ENGINE INNODB STATUS;

If your application ever experiences:

hanging requests
frozen queues
stuck inserts
transaction conflicts

This command can immediately reveal:

LATEST DETECTED DEADLOCK

or:

LOCK WAIT

And suddenly the mystery disappears.

4. General Log Table Audit

This is where debugging becomes much more practical.

Most developers enable General Query Log and only think about the log file.

But MySQL can also write general logs into a table:

mysql.general_log

That means you can inspect logs using normal SQL.

You can filter by:

latest queries
specific table name
specific command type
specific MySQL thread ID
insert/update/delete queries
commit or rollback queries
transaction flow

This is much better than randomly placing Log::info() everywhere.

Prerequisite: Make Sure General Log Writes to Table

Before querying mysql.general_log, check where MySQL is writing logs.

SHOW VARIABLES LIKE 'log_output';
SHOW VARIABLES LIKE 'general_log';

If log_output is only FILE, logs will go to a file.

If you want to query logs from a table, enable table output:

SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

If you want both file and table logging:

SET GLOBAL log_output = 'TABLE,FILE';
SET GLOBAL general_log = 'ON';

Now MySQL will write General Query Log entries into:

mysql.general_log

Important note:

You need enough MySQL permission to run SET GLOBAL and read from mysql.general_log.

This is usually something you do in a local, staging, or temporary production debugging session with proper access.

View Latest Queries from General Log Table

Once General Query Log is enabled with table output, you can inspect the latest queries like this:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
ORDER BY event_time DESC
LIMIT 100;

This gives you the real database activity.

Not what you think Laravel executed.

Not what your controller expected.

Not what your service class assumed.

What MySQL actually received.

Filter Only Actual SQL Queries

The general log contains different command types.

For example:

Connect
Query
Prepare
Execute
Quit

Most of the time, you only care about actual SQL statements.

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
ORDER BY event_time DESC
LIMIT 100;

This removes connection noise and focuses on real queries.

Find Queries for a Specific Table

Suppose your issue is related to the users table.

You can filter only queries that touched users:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

For campaign-related debugging:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%campaigns%'
ORDER BY event_time DESC
LIMIT 100;

This is extremely useful when one request touches multiple tables.

For example, one form submission may touch:

users
campaigns
leads
jobs
activity_logs

Instead of checking five different PHP files, you can ask MySQL directly:

“What happened to this table?”

Check Only INSERT Queries

If your form submission is supposed to create a user, check whether the INSERT query actually reached MySQL.

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'INSERT%'
ORDER BY event_time DESC
LIMIT 100;

Specific table:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'INSERT%'
  AND argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

Now you can answer important questions:

Did the insert query happen?

Did it happen once?

Did it happen multiple times?

Did it happen before rollback?

Did another process insert something unexpectedly?

That is the kind of answer controller logs often fail to provide.

Check UPDATE and DELETE Queries

For update issues:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'UPDATE%'
ORDER BY event_time DESC
LIMIT 100;

For delete issues:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'DELETE%'
ORDER BY event_time DESC
LIMIT 100;

For a specific table update:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE command_type = 'Query'
  AND argument LIKE 'UPDATE%'
  AND argument LIKE '%campaigns%'
ORDER BY event_time DESC
LIMIT 100;

This helps you catch accidental updates or deletes triggered by:

model observers
queue jobs
event listeners
cron jobs
scheduled commands
background workers

Check COMMIT and ROLLBACK

This is one of the most important parts.

Sometimes the query runs successfully.

But the transaction rolls back later.

To check transaction result:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

If you see:

ROLLBACK

after your insert or update queries, then your problem is not the insert query itself.

Your problem is somewhere inside the transaction.

Maybe an exception happened.

Maybe a lock wait happened.

Maybe another process created a conflict.

Maybe a queue or event triggered something unexpected.

This is exactly why debugging only from the controller is not enough.

Trace One Request Using Thread ID

This is where things become really powerful.

Every MySQL connection has a thread_id.

If you find one suspicious query, copy its thread_id.

Then filter the full flow for that connection:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

Now you can see the query sequence in order.

Example output may look like this:

START TRANSACTION;

INSERT INTO users ...

UPDATE campaigns ...

INSERT INTO leads ...

ROLLBACK;

That tells the real story.

Not guesswork.

Not random logs.

The actual database flow.

Trace Transaction Start, Commit, and Rollback

If you only want transaction-related statements:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) LIKE 'start transaction%'
   OR LOWER(argument) = 'begin'
   OR LOWER(argument) = 'commit'
   OR LOWER(argument) = 'rollback'
ORDER BY event_time DESC
LIMIT 100;

For a specific thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
  AND (
        LOWER(argument) LIKE 'start transaction%'
        OR LOWER(argument) = 'begin'
        OR LOWER(argument) = 'commit'
        OR LOWER(argument) = 'rollback'
      )
ORDER BY event_time ASC;

This is very useful when a form submission works sometimes and fails randomly.

Because now you can see:

when the transaction started
which queries happened inside it
whether it committed
whether it rolled back

Can We Filter POST Requests from MySQL?

Not directly.

MySQL does not know whether the original HTTP request was:

GET
POST
PUT
PATCH
DELETE

MySQL only sees SQL.

So from the database side, you usually filter write operations:

INSERT
UPDATE
DELETE
COMMIT
ROLLBACK

For example, a POST request that creates a user usually results in:

INSERT INTO users ...

A PATCH request may result in:

UPDATE users ...

A delete action may result in:

DELETE FROM users ...

So instead of searching for “POST” inside MySQL, search for the SQL operation caused by that POST request.

Application-Level Request Tracking Example

If you want to connect application request logs with MySQL logs, add a request ID at application level.

Laravel example:

use Illuminate\Support\Str;
use Illuminate\Support\Facades\Log;

$requestId = request()->header('X-Request-Id') ?? (string) Str::uuid();

Log::withContext([
    'request_id' => $requestId,
    'method' => request()->method(),
    'path' => request()->path(),
]);

Log::info('Request started');

Now your Laravel logs can tell you:

request_id: 7e71e1d8-3d9b-45e5-8a80-ef98c0d9c101
method: POST
path: /users

Then you can add a temporary MySQL session marker:

DB::statement("SET @debug_request_id = ?", [$requestId]);

This statement will also appear inside the General Query Log.

Now search for that marker:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%debug_request_id%'
ORDER BY event_time DESC
LIMIT 20;

Once you find the thread_id, inspect all queries from that same thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

This gives you a bridge between:

Laravel request
controller/service logs
actual MySQL queries
transaction commit/rollback result

That is much better than guessing.

Example: Debugging a Failed User Creation

Imagine this flow:

user submits form
Laravel receives POST request
application starts transaction
user is inserted
campaign is assigned
lead is generated
something fails
transaction rolls back

From application logs, you may only see:

User creation failed

But from MySQL general log, you can check:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
   OR argument LIKE '%campaigns%'
   OR argument LIKE '%leads%'
   OR LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

Then you may discover:

INSERT INTO users ...

UPDATE campaigns ...

INSERT INTO leads ...

ROLLBACK;

Now the problem is clear.

The user insert happened.

The campaign update happened.

The lead insert happened.

But the transaction rolled back.

So the debugging direction changes immediately.

You stop asking:

“Why did user insert fail?”

And start asking:

“What caused the rollback?”

That is a huge difference.

Clean General Log Table

Do not let mysql.general_log grow forever.

After debugging, clean it.

First, disable General Query Log:

SET GLOBAL general_log = 'OFF';

Then truncate the table:

TRUNCATE TABLE mysql.general_log;

If you still need debugging, enable it again:

SET GLOBAL general_log = 'ON';

Full cleanup flow:

SET GLOBAL general_log = 'OFF';

TRUNCATE TABLE mysql.general_log;

SET GLOBAL general_log = 'ON';

Important note:

Do not use this as permanent production logging.

This is for temporary debugging.

Disable General Query Log After Debugging

This is the part developers often forget.

After investigation, turn it off:

SET GLOBAL general_log = 'OFF';

You can verify:

SHOW VARIABLES LIKE 'general_log';

If the value is OFF, logging is disabled.

One Important Thing Most Developers Ignore

Do not leave general_log permanently enabled in production.

That is a bad idea.

Because:

logs become massive
storage grows quickly
performance can suffer
sensitive query data may appear in logs
debugging tables can become noisy very fast

The smarter workflow is temporary debugging.

Temporary Debugging Workflow

Enable table logging:

SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

Reproduce the issue.

Check recent queries:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
ORDER BY event_time DESC
LIMIT 100;

Filter by table:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE argument LIKE '%users%'
ORDER BY event_time DESC
LIMIT 100;

Filter by transaction result:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE LOWER(argument) IN ('commit', 'rollback')
ORDER BY event_time DESC
LIMIT 100;

Trace one thread:

SELECT
    event_time,
    user_host,
    thread_id,
    command_type,
    argument
FROM mysql.general_log
WHERE thread_id = 12345
ORDER BY event_time ASC;

Then disable logging:

SET GLOBAL general_log = 'OFF';

And clean the table:

TRUNCATE TABLE mysql.general_log;

That is the workflow.

Enable.

Reproduce.

Inspect.

Filter.

Understand.

Disable.

Clean.

That is how you stop guessing and start debugging from the place that sees everything:

Stack Pointer vs Base Pointer: A Friendly Guide to How Function Calls Work

Tahsin Abrar — Mon, 18 May 2026 11:38:49 +0000

Have you ever called a function and wondered what really happens inside the computer?

package main

import "fmt"

func add(x int, y int) int {
    result := x + y
    return result
}

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

We know the output will be:

But inside the machine, a lot of quiet work happens.

The CPU needs to remember:

Where did this function start?

Where should it return?

Where are the arguments?

Where are the local variables?

Which function is currently running?

This is where the stack, stack frame, stack pointer, and base pointer come in.

Let’s break them down in a simple way.

First, What Is a Stack?

A stack is a special area of memory used while a program is running.

Think of it like a stack of plates.

You put a plate on top.

You remove the top plate first.

You cannot remove a plate from the middle without disturbing the others.

In programming, the stack works in a similar way.

When a function is called, the program creates a small memory area for that function. This small area is called a stack frame.

When the function finishes, its stack frame is removed.

So if main() calls add(), the stack may look like this:

add() stack frame
main() stack frame

add() is on top because it is currently running.

When add() finishes, its stack frame is removed, and the program returns to main().

What Is a Stack Frame?

A stack frame is the memory space a function gets while it is running.

It usually stores things like:

Function arguments
Return address
Old base pointer
Local variables
Temporary values

For our add() function:

func add(x int, y int) int {
    result := x + y
    return result
}

The stack frame may contain:

x = 10
y = 4
return address
old base pointer
result = 14

The exact layout depends on the CPU, compiler, operating system, and calling convention. But the main idea is the same:

A function needs a private workspace while it runs.

That workspace is its stack frame.

A Quick Note About Memory Addresses

Before we go deeper, let’s clear up one common confusion.

On most modern systems, memory is byte-addressable. That means every byte has its own address.

So memory addresses can look like this:

0, 1, 2, 3, 4, 5, 6, 7, 8 ...

But when we draw memory in larger chunks, like 4-byte chunks on a 32-bit-style example, we often label them like this:

0, 4, 8, 12, 16 ...

This does not mean addresses 1, 2, and 3 do not exist.

It simply means we are drawing memory in 4-byte blocks.

Address 0  -> byte 1 of first block
Address 1  -> byte 2 of first block
Address 2  -> byte 3 of first block
Address 3  -> byte 4 of first block

Address 4  -> byte 1 of second block

For this article, we will use a simple 32-bit mental model where each slot is 4 bytes.

So our stack addresses may move like this:

In many systems, the stack grows downward, which means the address gets smaller as new data is pushed onto the stack.

What Is the Stack Pointer?

The stack pointer, often called SP, points to the current top of the stack.

Imagine you are stacking plates.

The stack pointer is like your finger pointing at the top plate.

When a new value is pushed onto the stack, the stack pointer moves.

When a value is popped from the stack, the stack pointer moves back.

Before push:

Address 76 -> old value
Address 72 -> top of stack  <- SP

Push new value:

Address 76 -> old value
Address 72 -> old top
Address 68 -> new value     <- SP

Because our example stack grows downward, pushing data makes SP move from 72 to 68.

So the stack pointer is dynamic.

It keeps changing as the stack grows and shrinks.

What Is the Base Pointer?

The base pointer, often called BP or frame pointer, points to a stable location inside the current function’s stack frame.

Unlike the stack pointer, the base pointer usually stays fixed while the function is running.

Why do we need that?

Because the stack pointer keeps moving.

If the program only used SP, it would be hard to find local variables and arguments after more values are pushed or popped.

The base pointer solves this problem.

It gives the function a fixed reference point.

From that fixed point, the program can find values using offsets.

BP + 8   -> first argument
BP + 12  -> second argument
BP - 4   -> first local variable
BP - 8   -> second local variable

So the base pointer helps the program answer questions like:

Where is x?

Where is y?

Where is result?

Where should I return after this function ends?

Stack Pointer vs Base Pointer

Here is the simple difference:

Register	Meaning	Behavior
Stack Pointer	Points to the current top of the stack	Changes often
Base Pointer	Points to a fixed place in the current stack frame	Usually stays fixed during the function

A simple way to remember it:

SP tracks movement.

BP gives stability.

The stack pointer is like a moving bookmark.

The base pointer is like an anchor.

What Happens When `main()` Runs?

func main() {
    a := 10
    sum := add(a, 4)
    fmt.Println(sum)
}

When main() starts, the program creates a stack frame for main.

Inside that frame, it stores local variables such as:

a = 10
sum = ?

At first, sum does not have its final value because add(a, 4) has not returned yet.

So the stack may look like this:

main stack frame
----------------
return address
old BP
a = 10

Now main() calls add(a, 4).

That means the program needs a new stack frame for add().

What Happens When `add()` Is Called?

This line is important:

sum := add(a, 4)

The program needs to call add() with two values:

x = 10
y = 4

So it creates a new stack frame for add().

A simplified stack frame may look like this:

add stack frame
---------------
y = 4
x = 10
return address
old BP
result = 0

The order can vary depending on the system, but the idea is the same.

The add() function needs:

Its arguments: x and y

A return address: where to go back after add() finishes

The old base pointer: so the caller’s stack frame can be restored

Its local variable: result

Why Do We Need a Return Address?

When main() calls add(), the CPU jumps to the code for add().

But after add() finishes, the CPU must know where to go back.

It needs to return to this line:

sum := add(a, 4)

More specifically, it needs to return to the next step after the function call, so the returned value can be stored in sum.

That “go back here” location is called the return address.

Without a return address, the program would get lost.

It would finish add() and then have no idea where to continue.

Why Save the Old Base Pointer?

Before add() starts, main() already has its own base pointer.

When add() starts, it gets a new base pointer for its own stack frame.

But when add() finishes, the program must restore the old base pointer so main() can continue correctly.

That is why the old base pointer is saved inside the new stack frame.

Think of it like leaving a breadcrumb.

Before entering a new function, the program says:

“Let me save where I came from, so I can restore it later.”

When the function ends, the old base pointer is loaded back.

Now the caller’s stack frame becomes active again.

How `add()` Finds `x`, `y`, and `result`

Inside add(), we have this line:

result := x + y

The CPU does not understand variable names like humans do.

It does not think:

“Oh, x means 10 and y means 4.”

Instead, the compiler maps variables to memory locations.

Using the base pointer, the program can find values by offsets.

BP + 8   -> x
BP + 12  -> y
BP - 4   -> result

So when the function needs x, it looks at something like:

BP + 8

When it needs y, it looks at:

BP + 12

When it needs to store result, it may use:

BP - 4

So the line:

result := x + y

becomes something like:

read value at BP + 8
read value at BP + 12
add them
store the answer at BP - 4

x = 10
y = 4

result = 14

Returning Back to `main()`

Now add() reaches this line:

return result

The function returns 14.

Then the add() stack frame is no longer needed.

So the program removes it from the stack.

The stack pointer moves back.

The old base pointer is restored.

The return address tells the CPU where to continue.

Now we are back inside main().

The returned value 14 is stored in sum.

sum := 14

Then this line runs:

fmt.Println(sum)

And we see:

A Simple Visual Summary

Here is a simplified version of what happens.

Before calling add():

main stack frame
----------------
a = 10
sum = ?

While add() is running:

add stack frame
---------------
x = 10
y = 4
result = 14

main stack frame
----------------
a = 10
sum = ?

After add() returns:

main stack frame
----------------
a = 10
sum = 14

Then main() prints:

Does This Always Work Exactly Like This?

Not always.

This article uses a simplified model to make the concept easy to understand.

Real systems can be more complex.

Modern compilers may optimize away the base pointer.

Function arguments may be passed through registers instead of the stack.

Go uses goroutine stacks, which can grow and move.

The exact stack layout depends on architecture, compiler version, and calling convention.

But the core idea is still useful:

Functions need stack frames.

The stack pointer tracks the top of the stack.

The base pointer gives a stable reference point inside a function frame.

Return addresses help the program continue from the correct place.

Old base pointers help restore the caller’s frame.

Once you understand this model, debugging, assembly, recursion, memory layout, and low-level programming all become much less mysterious.

A Real-Life Way to Remember It

Imagine you are reading a book and solving exercises.

You are on Chapter 5.

Suddenly, Chapter 5 says:

“Before continuing, go solve Example 2 from Chapter 3.”

So you place a bookmark in Chapter 5.

Then you go to Chapter 3 and solve the example.

After finishing, you return to the bookmark in Chapter 5.

In this story:

The bookmark is like the return address.

Your current page position is like the stack pointer.

The start of your current exercise notes is like the base pointer.

The notes for each exercise are like stack frames.

Every function call is like temporarily jumping into another task, while carefully remembering how to come back.

How to Connect a Namecheap Domain to a DigitalOcean Droplet with Nginx

Tahsin Abrar — Sat, 16 May 2026 15:31:38 +0000

Buying a domain is exciting. Creating a server is exciting too.

But the moment you try to connect both of them, things can feel confusing.

You bought your domain from Namecheap. You created a VPS on DigitalOcean. Now you expect your website to open when someone visits your domain.

But unlike shared hosting or cPanel hosting, DigitalOcean does not automatically connect everything for you.

You need to set up two important things:

DNS : so your domain points to your server
Nginx : so your server knows how to serve your website

In this guide, we will walk through the full setup in a simple and beginner-friendly way.

By the end, your domain will point to your DigitalOcean Droplet, Nginx will serve your website, and HTTPS will be enabled.

The Big Picture

Before touching any settings, let’s understand the flow.

Namecheap Domain
        ↓
DNS points to DigitalOcean IP
        ↓
DigitalOcean Droplet
        ↓
Nginx Web Server
        ↓
Your Website

Your domain is like a human-friendly address.

Your DigitalOcean Droplet is the actual server.

DNS connects the domain to the server.

Nginx receives the request and serves your website files or forwards traffic to your app.

Step 1: Create a DigitalOcean Droplet

First, create a Droplet on DigitalOcean.

For a beginner project or test website, this setup is usually enough:

Ubuntu 22.04 LTS
Basic Droplet
1 GB RAM

After the Droplet is created, DigitalOcean will give you a public IP address.

It will look something like this:

159.89.xxx.xxx

Keep this IP address safe. You will need it in the next step.

This IP is where your domain will point.

Step 2: Point Your Namecheap Domain to DigitalOcean

Now go to your Namecheap account.

Open:

Domain List
→ Manage
→ Advanced DNS

There are two common ways to connect your domain.

Option A: Use A Records

This is the easiest method for beginners.

Add these DNS records:

Type	Host	Value
A Record	@	Your DigitalOcean IP
A Record	www	Your DigitalOcean IP

Example:

Type	Host	Value
A Record	@	159.89.xxx.xxx
A Record	www	159.89.xxx.xxx

You can keep TTL as the default value.

Here is what this does:

example.com       → DigitalOcean server
www.example.com   → DigitalOcean server

So both the root domain and the www version will go to the same Droplet.

For most simple projects, this is the best starting point.

Option B: Use DigitalOcean Nameservers

Another option is to manage DNS from DigitalOcean instead of Namecheap.

In DigitalOcean, go to:

Networking
→ Domains
→ Add Domain

Add your domain there.

DigitalOcean will give you nameservers like:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Then go back to Namecheap:

Domain
→ Manage
→ Nameservers
→ Custom DNS

Add those three DigitalOcean nameservers and save.

This method is useful when you want to manage all DNS records from DigitalOcean, especially if you have multiple subdomains or services.

Which DNS Method Should You Choose?

For beginners, use A Records.

It is simple, clear, and easy to debug.

Use DigitalOcean nameservers when your setup becomes larger, for example:

api.example.com
app.example.com
blog.example.com
admin.example.com

For now, we will continue with the beginner-friendly A Record method.

Step 3: Wait for DNS Propagation

DNS changes are not always instant.

Sometimes they work in a few minutes. Sometimes they take longer.

Usually, it can take:

5 minutes to 1 hour

In some cases, it may take up to:

24 hours

You can use tools like DNS Checker to see whether your domain is pointing to the correct server IP.

A common beginner mistake is changing DNS and immediately thinking something is broken. Sometimes nothing is broken. DNS just needs a little time.

Step 4: Connect to Your Server with SSH

Now connect to your DigitalOcean Droplet.

On Mac or Linux, open your terminal.

On Windows, you can use PowerShell or PuTTY.

Run:

ssh root@YOUR_SERVER_IP

Example:

ssh root@159.89.xxx.xxx

The first time you connect, your terminal may ask for confirmation. Type:

yes

Then enter your password or use your SSH key, depending on how you created the Droplet.

Step 5: Install Nginx

Once you are inside the server, update the package list:

sudo apt update

Then install Nginx:

sudo apt install nginx -y

Check if Nginx is running:

sudo systemctl status nginx

If everything is working, you should see that Nginx is active.

At this point, if you open your server IP in the browser, you may see the default Nginx welcome page.

That means your web server is working.

Step 6: Configure the Firewall

Ubuntu servers often use ufw for firewall management.

Allow Nginx traffic:

sudo ufw allow 'Nginx Full'

Also allow SSH so you do not lock yourself out:

sudo ufw allow OpenSSH

Then enable the firewall:

sudo ufw enable

You can check the firewall status with:

sudo ufw status

You should see that HTTP, HTTPS, and SSH traffic are allowed.

Step 7: Create a Website Folder

Now create a folder for your website.

sudo mkdir -p /var/www/myproject

Create a test HTML file:

sudo nano /var/www/myproject/index.html

Paste this:

<h1>Hello from DigitalOcean</h1>

Save the file:

CTRL + X
Y
Enter

This simple file will help us confirm that the domain and Nginx setup are working.

Step 8: Create an Nginx Server Block

An Nginx server block tells Nginx how to handle traffic for a specific domain.

Create a new config file:

sudo nano /etc/nginx/sites-available/myproject

Paste this configuration:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/myproject;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Replace this:

example.com www.example.com

With your real domain.

For example:

server_name mycoolsite.com www.mycoolsite.com;

This config says:

“When someone visits this domain, serve files from /var/www/myproject.”

Step 9: Enable the Site

Nginx keeps available site configs in:

/etc/nginx/sites-available/

But it only uses configs that are linked in:

/etc/nginx/sites-enabled/

So we need to enable the site:

sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/

Step 10: Test and Reload Nginx

Before restarting Nginx, always test the config:

sudo nginx -t

If everything is fine, you should see something like:

syntax is ok
test is successful

Now reload Nginx:

sudo systemctl reload nginx

Open your domain in the browser:

http://yourdomain.com

You should see:

Hello from DigitalOcean

Great. Your domain is now connected to your Droplet.

Step 11: Add HTTPS with Certbot

A production website should use HTTPS.

For that, we can use Certbot with Let’s Encrypt.

Install Certbot:

sudo apt install certbot python3-certbot-nginx -y

Then run:

sudo certbot --nginx

Certbot will ask you to choose the domain.

Select your domain and allow redirect to HTTPS.

After that, your site should work with:

https://yourdomain.com

Certbot also sets up automatic renewal, so your SSL certificate can renew before it expires.

Final Architecture

Your setup now looks like this:

Namecheap
   ↓
DNS A Record
   ↓
DigitalOcean Droplet IP
   ↓
Nginx
   ↓
Website Files

This is a common real-world setup used by many developers.

Why This Feels Different from cPanel Hosting

If you are coming from cPanel hosting, DigitalOcean may feel harder at first.

That is normal.

With cPanel hosting, the hosting company usually handles many things for you:

DNS
Apache or Nginx
SSL
PHP
File manager
Email tools

You often just change nameservers and upload your files.

But with a DigitalOcean VPS, you manage the server yourself.

That means you are responsible for:

Nginx
Firewall
SSL
App runtime
Deployment
Security
Logs

The benefit is flexibility.

You can run Node.js, Laravel, Docker, PostgreSQL, Redis, background workers, multiple apps, and more.

The tradeoff is that you need to understand the server setup.

A Real-Life Example

Imagine you built a small portfolio website.

You bought:

myportfolio.com

from Namecheap.

Then you created a DigitalOcean Droplet with this IP:

159.89.100.50

In Namecheap, you add:

Type	Host	Value
A Record	@	159.89.100.50
A Record	www	159.89.100.50

Then on your server, your Nginx config looks like this:

server {
    listen 80;
    server_name myportfolio.com www.myportfolio.com;

    root /var/www/myportfolio;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

After reloading Nginx and setting up SSL, visitors can open:

https://myportfolio.com

And see your website.

That is the full journey from domain to live website.

Hubs, Switches, and Routers Explained Like You're Debugging a Real Network

Tahsin Abrar — Mon, 11 May 2026 06:48:03 +0000

Have you ever connected your laptop to Wi-Fi, opened a browser, typed a URL, and wondered:

"How does my message actually reach the right computer?"

As developers, we often work with APIs, servers, ports, IP addresses, localhost, Docker networks, cloud servers, and routers. But networking can feel confusing because many explanations jump straight into heavy terms.

So let's slow down and make it simple.

In this post, we'll understand three important network devices:

Hub
Switch
Router

We'll also see how data moves from one computer to another inside a local network, and how your computer decides whether to send data directly to another device or through the router.

This article is based on the provided networking class transcript about hubs, switches, routers, MAC tables, and internal communication.

First, Imagine a Small Room Full of Computers

Imagine five computers connected in the same room.

One computer wants to send a message to another computer.

For example:

Computer A wants to send data to Computer D

That sounds simple. But the network has to answer some important questions:

Who sent the data?
Who should receive it?
Are both devices in the same network?
Should the data go to another device first?

This is where hubs, switches, and routers come in.

The Hub: The Loud but Not-So-Smart Device

A hub is one of the simplest network devices.

You can think of it like a loudspeaker.

When one computer sends data to a hub, the hub does not check who the data is for. It simply forwards the data to every other connected port.

So if Computer A sends data through a hub, the hub sends it to:

Computer B
Computer C
Computer D
Computer E

Even if the message was only meant for Computer D.

The other computers receive the data, check it, and then ignore it if it is not meant for them.

Why is a hub considered "not smart"?

Because a hub works at the physical layer, also called Layer 1.

It only understands electrical signals or bits.

It does not understand:

MAC addresses
IP addresses
Ports
Applications
Actual message content

So a hub cannot make smart forwarding decisions.

It just repeats the signal.

Simple way to remember a hub

A hub says:

"I don't know who needs this, so I'll send it to everyone."

That is why hubs are rarely used in modern networks.

The Switch: A Smarter Device That Learns

A switch is much smarter than a hub.

A switch works at the data link layer, also called Layer 2.

That means a switch can understand MAC addresses.

A MAC address is like the hardware address of a network device. Every network interface has one.

For example, imagine five devices connected to a switch:

Port 1 -> Computer A
Port 2 -> Computer B
Port 3 -> Computer C
Port 4 -> Computer D
Port 5 -> Computer E

Each computer has a MAC address:

Computer A -> MAC A
Computer B -> MAC B
Computer C -> MAC C
Computer D -> MAC D
Computer E -> MAC E

Now Computer A wants to send data to Computer D.

The Ethernet frame may look like this in a simplified way:

Source MAC: A
Destination MAC: D
Data: Hello

When the switch receives this frame, it checks the source MAC address.

It says:

MAC A came from Port 1

Then it saves that information in a table.

This table is commonly called:

MAC address table
CAM table
Forwarding database
Bridge table

Different books and vendors may use different names, but the idea is the same.

The switch keeps a record like this:

MAC Address    Port
A              1

What Happens When the Switch Does Not Know the Destination?

Now the switch checks the destination MAC address:

Destination MAC: D

But imagine this is the first time the switch has seen Computer D.

So the switch does not yet know which port leads to MAC D.

What does it do?

It floods the frame.

That means it sends the frame to every port except the port it came from.

So the frame goes to:

Port 2
Port 3
Port 4
Port 5

Computer B receives it and says:

This is not for me.

Computer C says the same.

Computer E says the same.

But Computer D checks the destination MAC and says:

This is mine.

So Computer D accepts the frame.

How the Switch Learns Over Time

Now Computer D replies to Computer A.

The reply frame looks like this:

Source MAC: D
Destination MAC: A
Data: Hello back

The switch receives the frame from Port 4.

It checks the source MAC address and learns:

MAC D came from Port 4

Now the switch table becomes:

MAC Address    Port
A              1
D              4

Next time Computer A sends data to Computer D, the switch does not need to flood the frame.

It already knows:

MAC D is on Port 4

So it sends the frame only to Port 4.

That is why a switch is more efficient than a hub.

Simple way to remember a switch

A switch says:

"I’ll learn where devices are, then send data only where it needs to go."

Hub vs Switch in One Simple Example

Imagine a classroom.

A hub is like a student who receives a note and shouts it to the whole class.

A switch is like a helpful class monitor who learns where everyone sits and quietly gives the note to the right person.

That is the main difference.

Where Does the Router Fit In?

A router works at the network layer, also called Layer 3.

That means a router understands IP addresses.

A switch mainly cares about MAC addresses inside a local network.

A router cares about moving data between different networks.

For example:

Your laptop -> your home network
Your home network -> the internet
The internet -> another server

The router is the device that connects your local network to other networks.

Simple way to remember a router

A router says:

"This data needs to go outside this network. I know where to send it next."

Your Home Router Is Usually More Than Just a Router

This part is important.

The device we casually call a "router" at home is usually not just a router.

It often contains multiple things inside one box:

Router
Switch
Wi-Fi access point
DHCP server
Firewall/NAT features

So when you plug an Ethernet cable into your home router, you are usually plugging it into the switch part of the device.

When your laptop connects through Wi-Fi, it connects through the wireless access point part.

The real routing happens when data needs to leave your local network and go somewhere else, like the internet.

LAN Interface and WAN Interface

A home router usually has two sides:

LAN side

This is your local network.

Your laptop, phone, printer, TV, and other home devices live here.

Example local IP addresses:

192.168.1.10
192.168.1.11
192.168.1.12

Your router may have a local IP like:

192.168.1.1

This is often called the default gateway.

WAN side

This is the side connected to your internet provider.

The router gets a public or provider-side IP address on this side.

So your router sits between:

Your private home network
The outside internet

How Does a Computer Decide Where to Send Data?

Now comes a very important question.

Suppose your computer wants to send data to another IP address.

How does it know whether the destination is inside the same local network or outside?

It uses:

Its own IP address
The destination IP address
The subnet mask
The default gateway

Usually, your computer gets these from DHCP.

A DHCP server may give your device:

IP address:       192.168.1.10
Subnet mask:      255.255.255.0
Default gateway:  192.168.1.1

Now your computer can make a decision.

Example 1: Sending Data Inside the Same Network

Let's say:

Computer A IP: 192.168.1.10
Computer C IP: 192.168.1.11
Subnet mask:   255.255.255.0

Computer A wants to send data to Computer C.

It checks whether both IP addresses belong to the same network.

With this subnet mask, both addresses are part of:

192.168.1.0/24

So Computer A understands:

Computer C is in my local network.

That means Computer A does not need to send the data to the router for routing.

Instead, it sends an Ethernet frame directly toward Computer C's MAC address.

Simplified frame:

Source MAC: A
Destination MAC: C
Source IP: 192.168.1.10
Destination IP: 192.168.1.11

The switch receives the frame and forwards it to Computer C.

The router part does not need to be involved.

Example 2: Sending Data Outside the Network

Now imagine Computer A wants to send data to:

8.8.8.8

That IP is not inside the local network 192.168.1.0/24.

So Computer A understands:

This destination is outside my network.

Now something interesting happens.

The destination IP stays as:

8.8.8.8

But the destination MAC address becomes the MAC address of the router.

Simplified frame:

Source MAC: A
Destination MAC: Router
Source IP: 192.168.1.10
Destination IP: 8.8.8.8

Why?

Because inside the local network, the computer can only deliver frames to local devices by MAC address.

To reach the outside world, it sends the frame to the default gateway first.

The router receives it, looks at the destination IP, and then decides where to send it next.

Important Detail: MAC Address Changes, IP Address Stays

This is one of the most useful networking ideas to understand.

When data moves across networks, the IP packet is trying to reach the final IP address.

But at each local network hop, the MAC address may change.

For example:

Your laptop -> Router
Router -> ISP device
ISP device -> next router
Next router -> destination server

Each step may use a different source and destination MAC address.

But the destination IP is still the final server's IP.

That is why:

Switches care about MAC addresses.
Routers care about IP addresses.

A Developer-Friendly Example

Imagine you are building a backend API.

Your laptop is running a frontend app:

http://localhost:5173

Another computer on the same Wi-Fi is running an API server:

http://192.168.1.25:3000

When your laptop calls that API, it checks:

Am I in the same network as 192.168.1.25?

If yes, your laptop sends the frame toward that device's MAC address.

The switch or Wi-Fi access point handles local delivery.

The router does not need to send the traffic to the internet.

Now imagine your app calls:

https://api.github.com

That server is outside your local network.

So your laptop sends the frame to the router's MAC address.

The router then forwards the packet toward the internet.

This is happening all the time while you code.

Quick Comparison: Hub vs Switch vs Router

Device	Layer	Understands	Main Job
Hub	Layer 1	Bits/signals	Sends data to all ports
Switch	Layer 2	MAC addresses	Sends frames inside a local network
Router	Layer 3	IP addresses	Sends packets between networks

Common Terms You Should Remember

Frame

A frame belongs to the data link layer.

It contains MAC address information.

Source MAC
Destination MAC
Payload

Packet

A packet belongs to the network layer.

It contains IP address information.

Source IP
Destination IP
Payload

Segment

A segment usually belongs to TCP at the transport layer.

It contains port information.

Source port
Destination port
Data

MAC address table

A switch uses this table to remember which MAC address is connected to which port.

MAC Address    Port
A              1
C              3
D              4

Default gateway

The default gateway is usually your router's local IP address.

Your computer sends data to the default gateway when the destination is outside the local network.

A Simple Mental Model

Here is the easiest way to remember everything:

Hub:
"I will send it to everyone."

Switch:
"I will send it to the correct local device if I know where it is."

Router:
"I will send it to another network."

That's it.

Once you understand this, many networking topics become easier:

DHCP
ARP
Subnetting
NAT
Docker networking
Kubernetes networking
Cloud VPCs
Firewalls
Load balancers

DNS Made Simple: What Really Happens Before Your Browser Opens a Website

Tahsin Abrar — Thu, 23 Apr 2026 16:25:15 +0000

We use domain names every day.

We type google.com, facebook.com, or linkedin.com into a browser, press Enter, and the website opens in seconds. It feels simple. Almost boring.

But under the hood, something very important happens before your browser can even start talking to that website.

That thing is DNS.

And here is the part many developers miss early on: if you want to understand TLS/SSL, networking, deployment, or even why a request is slow, you need to understand DNS first.

Because before secure communication begins, your browser has to answer one basic question:

"Where is this website actually hosted?”

Let's break it down in the simplest possible way.

First, let's understand the URL

Take this URL:

https://blog.example.com

It has a few parts:

https → the scheme or protocol
blog → the subdomain
example → the main domain
.com → the top-level domain (TLD)

Another example:

https://engineering.linkedin.com

Here:

https is the protocol
engineering is the subdomain
linkedin is the domain
.com is the TLD

This structure matters because DNS works with these names.

Before we go into DNS, we need to understand one thing clearly:

a domain name is not the real machine address.

It is the human-friendly name for that machine.

Why domain names exist

Humans are good at remembering words.

Machines are good at working with numbers.

That is the heart of the whole idea.

You can easily remember:

facebook.com

But remembering something like this is much harder:

157.240.22.35

That number is an IP address.

An IP address is the real network address of a machine or server.

So when you type a domain name into a browser, your system has to find the IP address behind that name.

That translation is what DNS does.

A simple real-life example

Think about your home address.

If someone knows your address, they can find your house.

Computers work in a similar way.

Every machine connected to a network needs an address. On the internet, that address is the IP address.

Now imagine you built an app locally on your laptop. Maybe it runs on:

localhost:3000

That works on your own machine because your machine knows what localhost means.

But if you deploy that app to a server on AWS, DigitalOcean, or anywhere else, people cannot visit it using localhost.

They need the address of that server.

That real address is the IP address.

But asking users to remember IP addresses is a terrible experience.

So instead of telling people:

Visit 142.250.183.206

we give the server a domain name like:

myapp.com

Now people can remember the name, and machines can still connect using the IP.

That mapping between a human-friendly name and a machine-friendly IP is the whole point of DNS.

So what is DNS?

DNS stands for Domain Name System.

Let's keep it simple:

DNS is the system that converts a domain name into an IP address.

For example:

You type facebook.com
DNS finds the IP address behind facebook.com
Your browser uses that IP to contact the correct server

It is called a system because it is not just one thing.

It involves multiple parts working together:

your browser
your operating system
DNS caches
a DNS resolver
root name servers
TLD name servers
authoritative name servers

That is why it is not called just "domain name lookup.”

It is a system.

Before DNS goes to the internet, it checks cache

This is one of the most useful things to understand.

When you visit a website, your computer does not always start from scratch.

It first checks whether the answer is already stored somewhere.

This stored answer is called cache.

Think of cache like a shortcut memory.

If the system already knows the IP address for a domain, it can skip a lot of work.

That makes everything faster.

Usually, the lookup goes through these layers:

Browser cache
Operating system cache
DNS resolver cache
If not found, then the full DNS lookup starts

That is why websites often open very quickly the second time you visit them.

The full DNS journey, step by step

Now let's walk through what actually happens when you type:

facebook.com

into your browser.

1. The browser checks its own cache

Your browser first asks:

"Do I already know the IP for this domain?”

If yes, great. It uses that IP immediately.

If not, it moves to the next step.

2. The operating system checks its cache

If the browser does not have the answer, your operating system checks whether it has that domain-to-IP mapping stored.

If the OS already knows it, it returns the IP to the browser.

If not, the request continues.

3. The system asks a DNS resolver

Now the request goes to a DNS resolver.

In many cases, this resolver belongs to your ISP, though it could also be a public DNS service.

Its job is to find the answer for you.

And just like the browser and OS, the resolver also checks its own cache first.

If the resolver already knows the IP for facebook.com, it returns it immediately.

If not, now the real DNS lookup begins.

The resolver starts asking other DNS servers

This is where many learners get confused, but the logic is actually very clean.

The resolver does not magically know every IP address in the world.

Instead, it asks the right servers in the right order.

4. It asks a root name server

The resolver asks a root name server something like:

"I need information about .com. Where should I go next?”

Notice something important:

It is not asking for the final IP address yet.

It is asking where the .com information is managed.

The root server replies with the address of the TLD name server for .com.

5. It asks the TLD name server

Now the resolver goes to the .com TLD server and asks:

"Who is responsible for facebook.com?”

Again, this server usually does not return the final website IP directly.

Instead, it returns the address of the authoritative name server for that domain.

That server is the source of truth for the domain's DNS records.

6. It asks the authoritative name server

Now the resolver asks the authoritative name server:

"What is the IP address for facebook.com?”

This server returns the actual DNS record, such as the IP address.

Now the resolver finally has the answer it needs.

7. The answer comes back and gets cached

Once the resolver gets the IP address, it does two useful things:

it returns the answer to your operating system
it stores the answer in cache for future requests

Then the OS may cache it too.

Then the browser may cache it too.

That means the next lookup can be much faster.

8. The browser can finally contact the server

Now your browser has the IP address.

At this point, it can finally open a network connection to the actual server and send the real HTTP or HTTPS request.

That is the moment when the website request truly begins.

So yes, DNS happens before the browser can talk to the web server.

And that is exactly why DNS matters when learning TLS/SSL.

A simple mental model

If all the server names sound too abstract, use this mental model:

Root server → "I do not know the full answer, but I know who handles .com.”
TLD server → "I do not know the full answer, but I know who handles facebook.com.”
Authoritative server → "I am responsible for this domain. Here is the actual answer.”

That is the chain.

Why DNS is called "resolution”

You may hear the phrase:

DNS resolution

This simply means:

the process of resolving a domain name into an IP address

So if someone says:

"The DNS resolution failed”

they mean:

"The system could not turn the domain name into an IP address”

No IP, no connection.
No connection, no website.

Where subdomains fit into this

Let's say you have a domain like:

example.com

You can create subdomains like:

blog.example.com
api.example.com
admin.example.com

This is useful because one domain can support multiple services.

For example:

blog.example.com → blog website
api.example.com → backend API
admin.example.com → internal admin dashboard

Same parent domain.
Different subdomains.
Different purposes.

That is why learning domain structure matters before learning DNS deeply.

Why websites feel fast after the first visit

A lot of developers notice this but do not always connect it to DNS.

The first request may take a bit longer because the system needs to find the IP.

Later requests are faster because the answer may already exist in:

browser cache
OS cache
resolver cache

That means the system can skip most of the lookup chain.

So if a website opens instantly the second time, caching is often part of the reason.

Does DNS use TCP or UDP?

In simple learning material, DNS is often explained with UDP, and that is a good starting point.

Why?

Because UDP is lightweight and fast. It does not need a full connection setup like TCP.

For many standard DNS queries, that makes it a great fit.

A simple way to think about it is:

DNS wants to ask a quick question
get a quick answer
and move on

That said, in real systems, DNS can also use TCP in some cases.

But when you are first learning how DNS feels fast and lightweight, starting with UDP gives you the right intuition.

Why DNS matters before TLS/SSL

This is the part many people skip.

They jump into HTTPS, SSL certificates, and TLS handshakes without asking a more basic question:

How did the browser even find the server in the first place?

Before secure communication starts, the browser needs to know where to connect.

That means:

resolve the domain name into an IP address
connect to the server
then begin TLS/SSL and HTTP communication

So if DNS is unclear, TLS/SSL will always feel a little foggy too.

Understanding DNS first makes the next networking topics much easier.

Why developers should care about this

It is easy to think:

"Do I really need to know all this? I can just build apps.”

You can. For a while.

But sooner or later, deeper understanding starts to matter.

Maybe:

your production request is slow
your domain is not pointing to the right server
your subdomain is broken
your SSL setup is failing
your infrastructure behaves differently across environments
a tool's official docs feel harder than they should

This is where fundamentals help.

When you understand DNS, you stop treating networking like magic.

You start seeing the path.

And once you can see the path, debugging becomes easier.

A small story every developer can relate to

Imagine this.

You deploy your app.
The code is fine.
The server is running.
But the site still does not open.

At first, you think:

is the backend broken?
is the port wrong?
is Nginx failing?
is HTTPS misconfigured?

But the real problem turns out to be simple:

the domain is not resolving correctly.

That one small DNS issue can make the whole app feel "down.”

This is why solid developers do not only learn frameworks.

They learn what happens around the request too.

The big lesson: do not skip the basics

A lot of hard topics become easier when your basics are strong.

Docker makes more sense.
Kubernetes makes more sense.
TLS/SSL makes more sense.
Load balancers, CDNs, proxies, reverse proxies, and hosting all make more sense.

Not because they are easy.

But because you already understand the ground they stand on.

Many developers struggle with official docs not because their English is bad, but because the underlying computer science concepts are still shaky.

That is normal.

And the fix is not shortcuts.

The fix is going back, learning the core ideas properly, and revisiting them again and again until they feel natural.

That is how real confidence is built.

DEV Community: Tahsin Abrar

How to Check Laravel Page Memory Usage Without Guessing

The Quick Solution

Why This Is Useful

A Real Laravel Example

What Does memory_get_peak_usage(true) Mean?

Why Not Just Use htop?

What to Check If Memory Is Too High

Test More Than Once

Important: Remove the Logger After Testing

Final Thoughts

My Public IP Kept Changing While Connecting TablePlus to DigitalOcean - How I Fixed It

The Problem

First, I Cleaned Up the Command

Why Was My IP Changing?

How I Solved It

What About Using /24?

What I Learned

How I Debugged a phpMyAdmin 500 Error While Importing a Large SQL File on Laragon

1. Check which PHP configuration is actually running

2. Check the PHP error log

3. Make sure browser PHP and CLI PHP use the same php.ini

4. Check Apache logs

5. Check Laragon's FastCGI request limit

6. Increase FcgidMaxRequestLen

7. If the next error is “Maximum execution time of 300 seconds exceeded”

The main lesson

Deploy Laravel and Vue to cPanel Automatically with GitHub Actions

Automatically Deploy Laravel and Vue to cPanel with GitHub Actions

The deployment architecture

What the workflow will do

Quick reference (read this first)

Before you start

Step 1: Prepare the application directory

Step 2: Create the production .env

Step 3: Find the correct PHP executable

Step 4: Generate the deployment SSH key

Step 5: Authorize the public key in cPanel

Optional key restrictions

Test the connection

Step 6: Verify and save the SSH host key

Step 7: Add GitHub secrets

Optional production environment

Step 8: Add the GitHub Actions workflow

Step 9: Run the first deployment

What the workflow preserves

Important security notes

Do not add a GitHub deploy key to cPanel for this workflow

Never put secrets in VITE_*

Protect the production workflow

Back up before risky migrations

queue:restart does not start a queue worker

Common errors

Permission denied (publickey)

Host key verification failed

Production .env is missing

public/build/manifest.json is missing

Laravel returns HTTP 500

storage:link fails

A note about deleted files

Conclusion

Mid-Year Backend Reset: My H2 Goals for Speed, Security, and Better Docs

Why I Like Doing a Mid-Year Engineering Reset

Goal 1: Improve Performance

Where I Want to Focus

Practical Steps I Want to Take

Goal 2: Strengthen Security

The Areas I Want to Recheck

Practical Steps I Want to Take

Goal 3: Improve Documentation

What I Want to Document Better

Practical Steps I Want to Take

Keeping the Reset Realistic

Redis on Windows with Laragon and Laravel: The PATH Issue That Looks Like a Redis Issue

The Real Situation

Step 1: Find the Redis CLI File

Step 2: Test Redis Using the Full Path

Step 3: Add Redis CLI to Git Bash PATH

A Small Redis CLI Mistake That Can Confuse You

Step 4: Make Sure Redis Server Is Running

What Does `memory_get_peak_usage(true)` Mean?

Why Not Just Use `htop`?

What About Using `/24`?

6. Increase `FcgidMaxRequestLen`

Step 2: Create the production `.env`

Never put secrets in `VITE_*`

`queue:restart` does not start a queue worker

`Permission denied (publickey)`

`Host key verification failed`

`Production .env is missing`

`public/build/manifest.json` is missing

`storage:link` fails

Step 5: Configure Laravel `.env`

`bash: redis-cli: command not found`

`Class "Predis\Client" not found`

`Class "Redis" not found`

Redis Works in `www` but Not in Another Folder

First, Know the Difference: `git pull` vs Pull Request

`git pull`

Problem 1: `gh: command not found`