Forem: ahmet gedik

CI/CD Pipeline for a Multi-Site Video Platform

ahmet gedik — Wed, 29 Apr 2026 21:00:01 +0000

Deploying a video platform to four separate hosting environments used to mean running a script manually and hoping nothing went wrong. Here's how I replaced that with a GitHub Actions CI/CD pipeline for DailyWatch and its sibling sites.

The Problem

Four sites, each on LiteSpeed shared hosting. Same codebase, different configurations (.env files, API keys, region settings). Deployments were FTP-based — no SSH, no Docker on the hosts, no Kubernetes. Just good old file transfer.

Manual deploys meant:

Forgetting to deploy to one site
Deploying stale code after switching branches
No rollback mechanism

GitHub Actions Workflow Structure

The workflow triggers on pushes to main and runs three stages: lint, test, deploy.

# .github/workflows/deploy.yml
name: Deploy Multi-Site

on:
  push:
    branches: [main]
  workflow_dispatch:  # Manual trigger

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: sqlite3, pdo_sqlite, curl
      - name: PHP Lint
        run: find app/ public/ -name '*.php' -exec php -l {} \;
      - name: Check .htaccess syntax
        run: |
          apache2ctl -t -f /dev/null -c "Include $(pwd)/public/.htaccess" 2>&1 || true

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: sqlite3, pdo_sqlite, curl, zip
      - name: Run Tests
        run: |
          php tests/run.php
        env:
          APP_ENV: testing

  deploy:
    needs: test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        site: [dwv, tvh, vvv, tvs]
      fail-fast: false  # Don't cancel other deploys if one fails
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to ${{ matrix.site }}
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets[format('{0}_FTP_HOST', matrix.site)] }}
          username: ${{ secrets[format('{0}_FTP_USER', matrix.site)] }}
          password: ${{ secrets[format('{0}_FTP_PASS', matrix.site)] }}
          server-dir: /public_html/
          exclude: |
            **/.env
            **/data/**
            **/*.log
            **/.git/**
            **/tests/**

The matrix strategy runs four deploy jobs in parallel. fail-fast: false ensures a failure on one site doesn't cancel the others — if tvh fails, dwv, vvv, and tvs still deploy.

FTP Secrets Management

Each site gets three secrets in GitHub repository settings:

DWV_FTP_HOST, DWV_FTP_USER, DWV_FTP_PASS
TVH_FTP_HOST, TVH_FTP_USER, TVH_FTP_PASS
VVV_FTP_HOST, VVV_FTP_USER, VVV_FTP_PASS
TVS_FTP_HOST, TVS_FTP_USER, TVS_FTP_PASS

The format() function in the workflow dynamically selects the right secret based on the matrix value. No hardcoded credentials in the YAML.

Post-Deploy: Cache Clearing

LiteSpeed caches aggressively. After deploy, clear it:

      - name: Clear LiteSpeed Cache
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets[format('{0}_FTP_HOST', matrix.site)] }}
          username: ${{ secrets[format('{0}_FTP_USER', matrix.site)] }}
          password: ${{ secrets[format('{0}_FTP_PASS', matrix.site)] }}
          server-dir: /lscache/
          dangerous-clean-slate: true  # Wipe the directory

Alternatively, hit a cache-clear endpoint after deploy:

      - name: Trigger Cache Clear
        run: |
          SITE_URL=${{ secrets[format('{0}_URL', matrix.site)] }}
          curl -sf "${SITE_URL}/task/clear-cache?key=${{ secrets.TASK_KEY }}" || true

Deploy Verification

Deploying is only half the job. Verify the deploy actually worked:

      - name: Verify Deployment
        run: |
          SITE_URL=${{ secrets[format('{0}_URL', matrix.site)] }}
          STATUS=$(curl -s -o /dev/null -w '%{http_code}' "${SITE_URL}")
          if [ "$STATUS" != "200" ]; then
            echo "::error::Site returned HTTP $STATUS after deploy"
            exit 1
          fi
          # Check version marker
          VERSION=$(curl -sf "${SITE_URL}/health" | jq -r '.version')
          echo "Deployed version: $VERSION"

The health endpoint returns the current git commit hash, so you can confirm the deploy propagated.

Notifications

Add a Slack or Discord notification at the end:

  notify:
    needs: deploy
    runs-on: ubuntu-latest
    if: always()
    steps:
      - name: Send Notification
        run: |
          STATUS="success"
          if [ "${{ needs.deploy.result }}" != "success" ]; then
            STATUS="failure"
          fi
          curl -X POST "${{ secrets.DISCORD_WEBHOOK }}" \
            -H 'Content-Type: application/json' \
            -d "{\"content\": \"Deploy $STATUS for commit ${{ github.sha }}\"}"

Lessons from Production

FTP is slow — The parallel matrix strategy cuts total deploy time from 12 minutes (sequential) to about 4 minutes.
Line endings matter — Config files must be Unix LF. A stray \r in FTP path configs corrupts remote paths silently.
Exclude patterns are critical — Never deploy .env files or data/ directories. One bad deploy can wipe your production database.

The pipeline has handled 200+ deploys to DailyWatch and the other sites without a manual intervention. It's not fancy, but it's reliable.

This article is part of the Building DailyWatch series.

CI/CD Pipeline for a Multi-Site Video Platform

ahmet gedik — Wed, 29 Apr 2026 09:00:01 +0000

The TrendVidStream codebase is shared across 4 LiteSpeed servers. Each server has its own .env with region assignments, API keys, and site-specific config. A git push to main should safely update all 4 without human intervention.

GitHub Actions handles this with a matrix deploy strategy.

Repository Layout Relevant to CI

v2/
├── app/
├── public/
├── templates/
├── cron/
├── site_envs/
│   ├── dwv.env
│   ├── tvh.env
│   ├── tvs.env        ← TrendVidStream production config
│   └── vvv.env
├── deploy_hosts.conf  ← FTP credentials (NEVER committed)
├── api_keys.conf      ← YouTube keys (committed, excluded from .gitignore)
├── version.txt        ← Git SHA, bumped on each deploy
└── .github/
    └── workflows/
        └── deploy.yml

Full Workflow

# .github/workflows/deploy.yml
name: CI/CD

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

env:
  PHP_VERSION: '8.3'

jobs:
  # ─── Phase 1: Static analysis + tests ───────────────────────
  quality:
    name: Quality Gates
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP ${{ env.PHP_VERSION }}
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ env.PHP_VERSION }}
          extensions: pdo_sqlite, gd, curl, intl
          tools: phpstan, cs2pr
          coverage: none

      - name: Cache Composer
        uses: actions/cache@v4
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: PHP syntax check
        run: >
          find app/ public/ cron/ -name '*.php'
          -exec php -l {} \; 2>&1 | tee /tmp/syntax.log;
          grep -v 'No syntax errors' /tmp/syntax.log | grep -v '^$' || true

      - name: PHPStan analysis
        run: vendor/bin/phpstan analyse app/ --level=6 --no-progress

      - name: Unit tests
        run: vendor/bin/phpunit tests/ --testdox --colors=always

      - name: Validate deploy_hosts.conf line endings
        run: |
          if file deploy_hosts.conf | grep -q CRLF; then
            echo "::error::deploy_hosts.conf has Windows line endings"
            exit 1
          fi

      - name: Validate .env files exist for all sites
        run: |
          for site in dwv tvh tvs vvv; do
            if [ ! -f "site_envs/${site}.env" ]; then
              echo "::error::Missing site_envs/${site}.env"
              exit 1
            fi
          done
          echo "All .env files present"

      - name: Check no secrets in tracked files
        run: |
          # Ensure .env files are not tracked
          if git ls-files | grep -q '\.env$'; then
            echo "::error::.env file is tracked by git"
            exit 1
          fi

  # ─── Phase 2: Write version.txt ──────────────────────────────
  version:
    name: Tag Version
    needs: quality
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Write version file
        run: |
          echo "${{ github.sha }}" > version.txt
          echo "$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> version.txt

      - name: Upload version artifact
        uses: actions/upload-artifact@v4
        with:
          name: version
          path: version.txt

  # ─── Phase 3: Parallel deploy to all 4 hosts ─────────────────
  deploy:
    name: Deploy — ${{ matrix.site }}
    needs: version
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        include:
          - site: tvs
            site_env: tvs.env
          - site: dwv
            site_env: dwv.env
          - site: tvh
            site_env: tvh.env
          - site: vvv
            site_env: vvv.env

    steps:
      - uses: actions/checkout@v4

      - name: Download version artifact
        uses: actions/download-artifact@v4
        with:
          name: version

      - name: Install lftp
        run: sudo apt-get install -y lftp

      - name: Deploy to ${{ matrix.site }}
        env:
          FTP_HOST: ${{ secrets[format('FTP_{0}_HOST', matrix.site)] }}
          FTP_USER: ${{ secrets[format('FTP_{0}_USER', matrix.site)] }}
          FTP_PASS: ${{ secrets[format('FTP_{0}_PASS', matrix.site)] }}
          FTP_PATH: ${{ secrets[format('FTP_{0}_PATH', matrix.site)] }}
        run: |
          lftp -u "$FTP_USER","$FTP_PASS" "$FTP_HOST" << 'LFTP'
            set ssl:verify-certificate no
            set net:timeout 60
            set net:max-retries 5
            set net:reconnect-interval-base 5

            # Mirror app files (excludes data, logs, .env)
            mirror -R --ignore-time --verbose \
              --exclude .git/ \
              --exclude .github/ \
              --exclude backlink/ \
              --exclude 'site_envs/' \
              --exclude 'data/' \
              --exclude '*.log' \
              --exclude '*.db' \
              ./ $FTP_PATH

            # Deploy this site's env file
            put site_envs/${{ matrix.site_env }} -o $FTP_PATH/.env

            # Deploy shared API keys
            put api_keys.conf -o $FTP_PATH/api_keys.conf

            # Deploy version marker
            put version.txt -o $FTP_PATH/version.txt

            # Clear LiteSpeed page cache
            rm -rf $FTP_PATH/lscache

            quit
          LFTP

      - name: Verify deployment
        env:
          FTP_HOST: ${{ secrets[format('FTP_{0}_HOST', matrix.site)] }}
          FTP_USER: ${{ secrets[format('FTP_{0}_USER', matrix.site)] }}
          FTP_PASS: ${{ secrets[format('FTP_{0}_PASS', matrix.site)] }}
          FTP_PATH: ${{ secrets[format('FTP_{0}_PATH', matrix.site)] }}
        run: |
          REMOTE=$(lftp -u "$FTP_USER","$FTP_PASS" "$FTP_HOST" -e \
            "set ssl:verify-certificate no; get $FTP_PATH/version.txt -o /tmp/remote_ver.txt; quit")
          LOCAL=$(head -1 version.txt)
          REMOTE_SHA=$(head -1 /tmp/remote_ver.txt)
          if [ "$LOCAL" = "$REMOTE_SHA" ]; then
            echo "[${{ matrix.site }}] OK: $REMOTE_SHA"
          else
            echo "[${{ matrix.site }}] MISMATCH: local=$LOCAL remote=$REMOTE_SHA"
            exit 1
          fi

  # ─── Phase 4: Summary ─────────────────────────────────────────
  summary:
    name: Deploy Summary
    needs: deploy
    if: always()
    runs-on: ubuntu-latest
    steps:
      - name: Output result
        run: |
          echo "## Deploy Result" >> $GITHUB_STEP_SUMMARY
          echo "| Site | Status |" >> $GITHUB_STEP_SUMMARY
          echo "|---|---|" >> $GITHUB_STEP_SUMMARY
          echo "| tvs | ${{ needs.deploy.result }} |" >> $GITHUB_STEP_SUMMARY
          echo "| dwv | ${{ needs.deploy.result }} |" >> $GITHUB_STEP_SUMMARY
          echo "| tvh | ${{ needs.deploy.result }} |" >> $GITHUB_STEP_SUMMARY
          echo "| vvv | ${{ needs.deploy.result }} |" >> $GITHUB_STEP_SUMMARY

Pull Request Workflow (Test Only)

On pull requests, only the quality gates run — no deployment:

# Reuses the same quality job, skips version + deploy
# because of the `if: github.ref == 'refs/heads/main'` guards

Cron Monitoring Job

# .github/workflows/monitor.yml
name: Monitor Cron Health

on:
  schedule:
    - cron: '0 6 * * *'  # Daily at 06:00 UTC

jobs:
  ping:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        url:
          - https://trendvidstream.com/health
          - https://topvideohub.com/health
          - https://dailywatch.video/health
    steps:
      - name: Health check ${{ matrix.url }}
        run: |
          STATUS=$(curl -s -o /dev/null -w '%{http_code}' \
            --max-time 10 '${{ matrix.url }}')
          if [ "$STATUS" != "200" ]; then
            echo "::error::${{ matrix.url }} returned HTTP $STATUS"
            exit 1
          fi
          echo "${{ matrix.url }} OK ($STATUS)"

Total Pipeline Time

Phase	Time
Quality gates	~50s
Version tag	~5s
Parallel FTP × 4	~3.5min
Verification × 4	~20s
Total	~5min

Every commit to TrendVidStream now deploys to all 4 global servers in under 5 minutes with zero manual steps.

This is part of the "Building TrendVidStream" series, documenting the architecture behind a global video directory covering Nordic, Middle Eastern, and Central European regions.

CI/CD Pipeline for a Multi-Site Video Platform

ahmet gedik — Tue, 28 Apr 2026 23:00:01 +0000

ViralVidVault is part of a family of video platforms, each running on separate LiteSpeed shared hosting. Same codebase, different configurations. Deploying manually to multiple hosts was error-prone and tedious. Here's the GitHub Actions pipeline that replaced it.

Constraints

Shared hosting means no SSH, no Docker on the server, no git pull. The only deployment option is FTP. The pipeline needs to:

Run PHP linting and tests
Deploy to multiple hosts in parallel
Exclude sensitive files (.env, data/)
Clear LiteSpeed cache after deploy
Verify each deployment succeeded

The Workflow

# .github/workflows/deploy.yml
name: Test and Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      site:
        description: 'Deploy specific site (or all)'
        required: false
        default: 'all'
        type: choice
        options: [all, dwv, tvh, vvv, tvs]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: sqlite3, pdo_sqlite, curl
      - name: Lint PHP files
        run: |
          EXIT_CODE=0
          while IFS= read -r file; do
            php -l "$file" > /dev/null 2>&1 || EXIT_CODE=1
          done < <(find app/ public/ cron/ -name '*.php')
          exit $EXIT_CODE
      - name: Run test suite
        run: php tests/run.php
        env:
          APP_ENV: testing

  deploy:
    needs: test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        site: [dwv, tvh, vvv, tvs]
      fail-fast: false
    steps:
      - uses: actions/checkout@v4

      - name: Deploy via FTP
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets[format('{0}_FTP_HOST', matrix.site)] }}
          username: ${{ secrets[format('{0}_FTP_USER', matrix.site)] }}
          password: ${{ secrets[format('{0}_FTP_PASS', matrix.site)] }}
          server-dir: /public_html/
          exclude: |
            **/.env
            **/data/**
            **/*.log
            **/.git/**
            **/tests/**
            **/backlink/**

      - name: Clear LiteSpeed cache
        run: |
          curl -sf "${{ secrets[format('{0}_URL', matrix.site)] }}/task/clear-cache?key=${{ secrets.TASK_KEY }}" \
            --max-time 10 || echo "Cache clear timed out (non-fatal)"

The workflow_dispatch input lets you deploy a single site manually from the GitHub UI. Useful when you need to hotfix one site without touching the others.

Matrix Strategy Deep Dive

The matrix keyword creates four parallel jobs, one per site. Each job has its own runner and its own set of secrets:

    strategy:
      matrix:
        site: [dwv, tvh, vvv, tvs]
      fail-fast: false

fail-fast: false is critical. Without it, if the tvh deploy fails (say, FTP timeout), GitHub cancels the vvv, dwv, and tvs jobs too. That turns one problem into four.

Secrets Organization

Twelve repository secrets, three per site:

DWV_FTP_HOST=ftp.dailywatch.video
DWV_FTP_USER=deploy@dailywatch.video
DWV_FTP_PASS=<password>

VVV_FTP_HOST=ftp.viralvidvault.com
VVV_FTP_USER=deploy@viralvidvault.com
VVV_FTP_PASS=<password>

# ... same pattern for TVH, TVS

The format() function dynamically resolves the right secret:

server: ${{ secrets[format('{0}_FTP_HOST', matrix.site)] }}
# When matrix.site = 'vvv', resolves to secrets.VVV_FTP_HOST

Post-Deploy Verification

Deploy doesn't mean working. Add a verification step:

      - name: Verify deployment
        run: |
          URL="${{ secrets[format('{0}_URL', matrix.site)] }}"
          echo "Checking $URL..."

          # Basic availability check
          HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' "$URL" --max-time 15)
          if [ "$HTTP_CODE" != "200" ]; then
            echo "::error::${{ matrix.site }} returned HTTP $HTTP_CODE"
            exit 1
          fi

          # Version check via health endpoint
          DEPLOYED=$(curl -sf "$URL/health" --max-time 10 | python3 -c "import sys,json; print(json.load(sys.stdin).get('commit','unknown'))")
          echo "${{ matrix.site }}: HTTP $HTTP_CODE, version $DEPLOYED"

This catches silent failures — FTP uploads that seem to succeed but actually fail due to permissions, disk space, or path misconfigurations.

Notifications on Failure

A deploy that fails silently is worse than a deploy that fails loudly:

  notify:
    needs: deploy
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Alert on failure
        run: |
          curl -X POST "${{ secrets.DISCORD_WEBHOOK }}" \
            -H 'Content-Type: application/json' \
            -d '{"content": "Deploy FAILED for ${{ github.sha }}. Check: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"}'

Production Results

Since switching to this pipeline for ViralVidVault and the other sites:

Deploy time went from 15 minutes (manual, sequential) to 4 minutes (automated, parallel)
Zero missed deployments (no more "forgot to deploy to tvs")
Three bad deploys caught by the verification step before any user noticed

The FTP constraint makes this less elegant than a container-based deploy, but the reliability improvement is the same. Automate the boring parts, verify the important parts.

This article is part of the Building ViralVidVault series.

CI/CD Pipeline for a Multi-Site Video Platform

ahmet gedik — Tue, 28 Apr 2026 13:13:14 +0000

Deploying TopVideoHub means pushing to 4 LiteSpeed servers that each cover different Asia-Pacific regions. Manual FTP to 4 hosts is error-prone. GitHub Actions turned that into a one-push workflow.

Here is the full pipeline.

Constraints: Shared Hosting Reality

Shared LiteSpeed hosting does not give you SSH access, Docker runners on the server, or webhook endpoints. The deployment method is FTP via lftp. The CI pipeline must:

Run tests and lint PHP without a server
Deploy via FTP in parallel to all 4 hosts
Clear the LiteSpeed page cache after deploy
Send a notification when all hosts are live

Repository Secrets

In GitHub Settings → Secrets and variables → Actions, create one secret per host:

FTP_DWV_HOST=ftp.dailywatch.video
FTP_DWV_USER=deploy_user
FTP_DWV_PASS=super_secret
FTP_DWV_PATH=/htdocs

FTP_TVH_HOST=ftp.topvideohub.com
FTP_TVH_USER=deploy_user
FTP_TVH_PASS=super_secret
FTP_TVH_PATH=/htdocs

# ... repeat for tvs and vvv

Main Workflow

# .github/workflows/deploy.yml
name: Test and Deploy

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

jobs:
  # ─── Phase 1: Test ───────────────────────────────────────────
  test:
    name: PHP Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: pdo_sqlite, gd, curl
          coverage: none

      - name: Validate composer.json
        run: composer validate --strict

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: PHP Lint (syntax check)
        run: |
          find app/ public/ cron/ templates/ \
            -name '*.php' \
            -exec php -l {} \; | grep -v 'No syntax errors'

      - name: Run unit tests
        run: vendor/bin/phpunit tests/ --testdox

      - name: Validate .htaccess syntax
        run: |
          if grep -P '\t' public/.htaccess; then
            echo "ERROR: .htaccess contains tab characters"
            exit 1
          fi
          echo ".htaccess OK"

      - name: Check deploy_hosts.conf line endings
        run: |
          if grep -Pc '\r' deploy_hosts.conf > /dev/null 2>&1; then
            echo "ERROR: deploy_hosts.conf has Windows line endings!"
            exit 1
          fi
          echo "deploy_hosts.conf OK"

  # ─── Phase 2: Deploy (only on push to main) ───────────────────
  deploy:
    name: Deploy — ${{ matrix.site }}
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false          # Don't cancel other deploys if one fails
      matrix:
        site: [dwv, tvh, tvs, vvv]

    steps:
      - uses: actions/checkout@v4

      - name: Install lftp
        run: sudo apt-get install -y lftp

      - name: Deploy via FTP
        env:
          FTP_HOST: ${{ secrets[format('FTP_{0}_HOST', matrix.site)] }}
          FTP_USER: ${{ secrets[format('FTP_{0}_USER', matrix.site)] }}
          FTP_PASS: ${{ secrets[format('FTP_{0}_PASS', matrix.site)] }}
          FTP_PATH: ${{ secrets[format('FTP_{0}_PATH', matrix.site)] }}
        run: |
          lftp -u "$FTP_USER","$FTP_PASS" "$FTP_HOST" << 'LFTP'
            set ssl:verify-certificate no
            set net:timeout 60
            set net:max-retries 3
            mirror -R --verbose --ignore-time \
              --exclude .git/ \
              --exclude .github/ \
              --exclude .env \
              --exclude 'data/' \
              --exclude '*.log' \
              --exclude '*.db' \
              --exclude 'backlink/' \
              ./ $FTP_PATH
            put api_keys.conf -o $FTP_PATH/api_keys.conf
            rm -rf $FTP_PATH/lscache
            quit
          LFTP

      - name: Verify deploy
        env:
          FTP_HOST: ${{ secrets[format('FTP_{0}_HOST', matrix.site)] }}
          FTP_USER: ${{ secrets[format('FTP_{0}_USER', matrix.site)] }}
          FTP_PASS: ${{ secrets[format('FTP_{0}_PASS', matrix.site)] }}
          FTP_PATH: ${{ secrets[format('FTP_{0}_PATH', matrix.site)] }}
        run: |
          REMOTE_VER=$(lftp -u "$FTP_USER","$FTP_PASS" "$FTP_HOST" -e \
            "set ssl:verify-certificate no; cat $FTP_PATH/version.txt; quit")
          LOCAL_VER=$(cat version.txt)
          if [ "$REMOTE_VER" = "$LOCAL_VER" ]; then
            echo "[${{ matrix.site }}] Verify PASSED: $REMOTE_VER"
          else
            echo "[${{ matrix.site }}] Verify FAILED: remote=$REMOTE_VER local=$LOCAL_VER"
            exit 1
          fi

  # ─── Phase 3: Post-deploy notification ───────────────────────
  notify:
    name: Notify
    needs: deploy
    if: always()
    runs-on: ubuntu-latest
    steps:
      - name: Post status to Slack
        uses: slackapi/slack-github-action@v1.26.0
        with:
          payload: |
            {
              "text": "TopVideoHub deploy ${{ needs.deploy.result == 'success' && '✓ succeeded' || '✗ failed' }} on `${{ github.ref_name }}` by ${{ github.actor }}"
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

PHP Unit Test Example

<?php
// tests/QuotaManagerTest.php

use PHPUnit\Framework\TestCase;

class QuotaManagerTest extends TestCase
{
    private PDO $db;

    protected function setUp(): void
    {
        // In-memory SQLite for tests — no file I/O
        $this->db = new PDO('sqlite::memory:');
        $this->db->exec(file_get_contents(__DIR__ . '/../schema.sql'));
    }

    public function testQuotaDecrement(): void
    {
        $mgr = new QuotaManager($this->db);
        $mgr->setQuota('key1', 10000);

        $mgr->consume('key1', 100);
        $this->assertSame(9900, $mgr->remaining('key1'));
    }

    public function testKeyRotation(): void
    {
        $mgr = new QuotaManager($this->db);
        $mgr->setQuota('key1', 0);   // Exhausted
        $mgr->setQuota('key2', 10000);

        $activeKey = $mgr->getActiveKey();
        $this->assertSame('key2', $activeKey);
    }

    public function testRegionFetchOrder(): void
    {
        $regions = ['US', 'GB', 'JP', 'KR', 'TW', 'SG', 'VN', 'TH', 'HK'];
        $this->assertCount(9, $regions);
        $this->assertContains('JP', $regions);
        $this->assertContains('KR', $regions);
    }
}

Caching the Composer Install

- name: Cache Composer packages
  uses: actions/cache@v4
  with:
    path: vendor
    key: composer-${{ hashFiles('composer.lock') }}
    restore-keys: composer-

- name: Install dependencies
  run: composer install --no-dev --optimize-autoloader

Parallel Deploy Performance

The matrix strategy runs all 4 deployments simultaneously. Wall-clock time for a full deploy to all 4 LiteSpeed hosts:

Step	Time
PHP tests + lint	~45s
FTP mirror (parallel × 4)	~3min
Verify + notify	~15s
Total	~4min

Without parallelism, sequential FTP to 4 hosts would take ~12 minutes.

Branch Protection

# .github/branch_protection.yml (via GitHub API or UI)
branch: main
required_status_checks:
  strict: true
  contexts:
    - "PHP Tests"
require_pull_request_reviews:
  required_approving_review_count: 1
restrict_pushes: true

Every commit to TopVideoHub now goes through this pipeline. The matrix deploy means all 4 servers are updated in under 4 minutes from a git push.

This is part of the "Building TopVideoHub" series, documenting the architecture behind a video discovery platform covering 9 Asia-Pacific regions.

Redis Caching Strategies for Video Content Platforms

ahmet gedik — Mon, 20 Apr 2026 05:00:02 +0000

TrendVidStream serves trending video content from 8 regions: US, GB, CH, DK, AE, BE, CZ, FI. The Nordic and Central European regions trend quietly, while UAE can spike hard when regional events drive traffic. A flat TTL for all regions wastes quota on quiet regions and serves stale data to spiking ones.

Redis lets us handle that heterogeneity cleanly.

Current Stack vs Redis

The platform currently uses a 3-tier PHP file cache. Redis fits in as the middle tier:

Request
  → Redis (sub-millisecond, in-memory)
  → PHP file cache (milliseconds, disk)
  → SQLite (single-digit ms, WAL mode)

For a multi-worker PHP-FPM setup, Redis solves the shared-state problem: file-based caches are per-server. Redis is shared across all workers automatically.

Trending Lists: Redis Lists

<?php

class TrendingCache
{
    private Redis $r;

    // Region-specific TTLs — Nordic/Central EU trends slowly,
    // UAE and GB can spike fast
    private const REGION_TTL = [
        'AE' => 5400,   // 1.5h — UAE news/events spike
        'GB' => 7200,   // 2h
        'US' => 7200,   // 2h
        'CH' => 10800,  // 3h — stable Swiss market
        'DK' => 10800,  // 3h — stable Nordic
        'BE' => 10800,  // 3h
        'CZ' => 14400,  // 4h — Central EU slower cycle
        'FI' => 14400,  // 4h — Finland quietest
    ];

    public function set(string $region, array $videos): void
    {
        $key = "tvs:trending:{$region}";
        $ttl = self::REGION_TTL[$region] ?? 10800;

        $pipe = $this->r->pipeline();
        $pipe->del($key);

        foreach ($videos as $video) {
            $pipe->rPush($key, json_encode([
                'id'        => $video['video_id'],
                'title'     => $video['title'],
                'thumb'     => $video['thumbnail'],
                'channel'   => $video['channel_title'],
                'views'     => $video['view_count'],
                'category'  => $video['category_id'],
            ]));
        }

        $pipe->expire($key, $ttl);
        $pipe->execute();
    }

    public function get(string $region, int $page = 1, int $perPage = 20): ?array
    {
        $key   = "tvs:trending:{$region}";
        $start = ($page - 1) * $perPage;
        $end   = $start + $perPage - 1;

        $items = $this->r->lRange($key, $start, $end);
        if (empty($items)) {
            return null;
        }

        return array_map(
            fn($v) => json_decode($v, true),
            $items
        );
    }

    public function count(string $region): int
    {
        return (int)$this->r->lLen("tvs:trending:{$region}");
    }
}

Sorted Sets for Cross-Region Trending

TrendVidStream's home page surfaces videos trending in the most regions simultaneously — a pan-European trending feed:

<?php

class CrossRegionCache
{
    /**
     * Score = number of regions a video is trending in.
     * ZUNIONSTORES the region lists into a single cross-region feed.
     */
    public function rebuild(array $regions): void
    {
        $tempKeys = [];

        foreach ($regions as $region) {
            $srcKey  = "tvs:trending:{$region}";
            $tempKey = "tvs:temp:scores:{$region}";

            // Fetch all video IDs from this region's list
            $videos = $this->r->lRange($srcKey, 0, -1);
            if (empty($videos)) {
                continue;
            }

            $pipe = $this->r->pipeline();
            $pipe->del($tempKey);
            foreach ($videos as $raw) {
                $v = json_decode($raw, true);
                $pipe->zAdd($tempKey, 1, $v['id']);
            }
            $pipe->execute();

            $tempKeys[] = $tempKey;
        }

        if (empty($tempKeys)) {
            return;
        }

        // Union all region scores — video trending in 4 regions scores 4
        $this->r->zUnionStore(
            'tvs:global:trending',
            $tempKeys,
            array_fill(0, count($tempKeys), 1),
            'SUM'
        );
        $this->r->expire('tvs:global:trending', 10800);

        // Cleanup temp keys
        $this->r->del($tempKeys);
    }

    public function getTopGlobal(int $n = 20): array
    {
        // Highest score = most regions trending
        return $this->r->zRevRange('tvs:global:trending', 0, $n - 1, true);
    }
}

Hash Sets for Video Metadata

<?php

class VideoMetaCache
{
    private const TTL = 21600; // 6h — matches watch page HTTP cache

    public function set(string $videoId, array $meta): void
    {
        $key = "tvs:video:{$videoId}";
        $this->r->hMSet($key, [
            'title'       => $meta['title'],
            'description' => mb_substr($meta['description'], 0, 500),
            'channel'     => $meta['channel_title'],
            'thumb_high'  => $meta['thumbnail_high'],
            'view_count'  => $meta['view_count'],
            'like_count'  => $meta['like_count'],
            'category_id' => $meta['category_id'],
            'region'      => $meta['region'],
            'cached_at'   => time(),
        ]);
        $this->r->expire($key, self::TTL);
    }

    public function get(string $videoId): ?array
    {
        $data = $this->r->hGetAll("tvs:video:{$videoId}");
        return empty($data) ? null : $data;
    }

    public function mGet(array $videoIds): array
    {
        $pipe = $this->r->pipeline();
        foreach ($videoIds as $id) {
            $pipe->hGetAll("tvs:video:{$id}");
        }
        $results = $pipe->execute();

        return array_combine(
            $videoIds,
            array_map(fn($r) => empty($r) ? null : $r, $results)
        );
    }
}

Cache Invalidation Patterns

Write-Through on Cron Fetch

<?php

class CronFetcher
{
    public function fetchRegion(string $region): void
    {
        $videos = $this->youtube->fetchTrending($region);

        // 1. Persist to SQLite
        $this->db->upsertVideos($videos, $region);

        // 2. Write-through: update Redis immediately
        $this->trendingCache->set($region, $videos);

        // 3. Invalidate search results for this region
        $this->invalidateSearchCache($region);

        // 4. Invalidate PHP page cache for affected pages
        $this->clearPageCache($region);
    }

    private function invalidateSearchCache(string $region): void
    {
        // Use SCAN — never KEYS in production
        $cursor = null;
        do {
            [$cursor, $keys] = $this->r->scan(
                $cursor,
                ['match' => "tvs:search:{$region}:*", 'count' => 200]
            );
            if ($keys) {
                $this->r->del($keys);
            }
        } while ($cursor !== 0);
    }
}

Stale-While-Revalidate in PHP

<?php

function getTrendingWithSWR(string $region, TrendingCache $cache, Database $db): array
{
    $data = $cache->get($region);

    if ($data !== null) {
        $ttl = $cache->getTTL($region);
        // If less than 20% of TTL remains, trigger async refresh
        if ($ttl < ($cache::REGION_TTL[$region] ?? 10800) * 0.2) {
            // Schedule background refresh without blocking the request
            if (function_exists('fastcgi_finish_request')) {
                register_shutdown_function(function() use ($region, $db, $cache) {
                    fastcgi_finish_request();
                    $fresh = $db->getTrending($region, 50);
                    $cache->set($region, $fresh);
                });
            }
        }
        return $data;
    }

    // Cache miss — fetch from SQLite
    $videos = $db->getTrending($region, 50);
    $cache->set($region, $videos);
    return array_slice($videos, 0, 20);
}

Memory Budget

For 8 regions at TrendVidStream:

Key type	Count	Avg size	Total
Trending lists	8 × 50 items	~600B/item	~240KB
Video metadata hashes	~400 videos	~900B	~360KB
Search results	~300 cached	~2KB	~600KB
Global trending sorted set	1	~15KB	~15KB
Total			~1.2MB

A 32MB Redis instance comfortably serves TrendVidStream with room for 25× growth.

This is part of the "Building TrendVidStream" series, documenting the architecture behind a global video directory covering Nordic, Middle Eastern, and Central European regions.

Dockerizing a Video Platform: From Dev to Production

ahmet gedik — Sun, 19 Apr 2026 10:00:01 +0000

TrendVidStream aggregates trending video content from 8 regions spanning the Nordics, Middle East, and Central Europe — CH, DK, AE, BE, CZ, FI plus US and GB. Each region has its own cron schedule and fetch cadence. Keeping all of that consistent between a developer's laptop and a LiteSpeed production server is where Docker earns its keep.

The Problem with PHP+SQLite on Bare Metal

SQLite has no server to install, which seems like an advantage. The catch is that PHP extensions, system SQLite versions, and locale settings can differ silently between machines. A developer on Ubuntu 24.04 with SQLite 3.45 behaves differently from the LiteSpeed server running SQLite 3.39 from the distro package manager.

Docker freezes these variables into a reproducible image.

Multi-Stage Dockerfile

# Stage 1: Build dependencies
FROM php:8.3-cli-alpine AS deps

RUN apk add --no-cache git curl unzip
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer

WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install \
      --no-dev \
      --optimize-autoloader \
      --no-interaction \
      --no-progress

# Stage 2: Production runtime
FROM php:8.3-fpm-alpine AS production

RUN apk add --no-cache \
        sqlite-dev \
        libpng-dev libjpeg-turbo-dev freetype-dev \
        curl-dev icu-dev && \
    docker-php-ext-configure gd \
        --with-freetype --with-jpeg && \
    docker-php-ext-install \
        pdo_sqlite gd curl intl opcache

# OPcache tuned for a read-heavy video platform
COPY docker/opcache.ini /usr/local/etc/php/conf.d/opcache.ini

WORKDIR /var/www/html

COPY --from=deps /app/vendor ./vendor
COPY app/           ./app/
COPY public/        ./public/
COPY templates/     ./templates/
COPY cron/          ./cron/
COPY api_keys.conf  ./

# data/ is ALWAYS a volume — never in the image
RUN mkdir -p data/pagecache && \
    chown -R www-data:www-data data

USER www-data
EXPOSE 9000
CMD ["php-fpm"]

; docker/opcache.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=8192
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1

docker-compose.yml for Local Dev

version: '3.9'

services:
  app:
    build:
      context: .
      target: production
    volumes:
      # Live code reload — mount source over image copies
      - ./app:/var/www/html/app:ro
      - ./templates:/var/www/html/templates:ro
      - ./public:/var/www/html/public:ro
      # Persistent SQLite database
      - tvs_data:/var/www/html/data
    environment:
      SITE_NAME: TrendVidStream
      SITE_URL: https://trendvidstream.com
      FETCH_REGIONS: "US,GB,CH,DK,AE,BE,CZ,FI"
      DB_PATH: /var/www/html/data/videos.db
      CACHE_PATH: /var/www/html/data/pagecache
    networks:
      - tvs

  nginx:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    volumes:
      - ./public:/var/www/html/public:ro
      - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - app
    networks:
      - tvs

  cron:
    build:
      context: .
      target: production
    volumes:
      - tvs_data:/var/www/html/data
    environment:
      FETCH_REGIONS: "US,GB,CH,DK,AE,BE,CZ,FI"
      DB_PATH: /var/www/html/data/videos.db
    command: >
      sh -c 'while true;
        do php /var/www/html/cron/fetch_videos.php;
        sleep 25200;
      done'
    networks:
      - tvs

volumes:
  tvs_data:

networks:
  tvs:

Nginx Dev Config (LiteSpeed Proxy)

server {
    listen 80;
    root /var/www/html/public;
    index index.php;
    charset utf-8;

    # Same rewrite logic as production .htaccess
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass   app:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
        # Simulate Cloudflare Flexible SSL header
        fastcgi_param  HTTP_X_FORWARDED_PROTO https;
    }

    location ~* \.(css|js|woff2|svg|webp|png|jpg)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

LiteSpeed Gap: What Docker Cannot Replicate

LiteSpeed has two production-only behaviours:

1. The lscache/ directory — LiteSpeed writes HTML page cache here. On Docker/Nginx this directory simply does not appear. The PHP fallback page cache in data/pagecache/ is used instead:

<?php

const IS_LITESPEED = (PHP_SAPI === 'litespeed');

function serveFromCache(string $cacheKey): bool
{
    if (IS_LITESPEED) {
        // LiteSpeed handles this at the web server layer
        return false;
    }

    $file = CACHE_PATH . '/' . md5($cacheKey) . '.html';
    if (file_exists($file) && (time() - filemtime($file)) < 10800) {
        readfile($file);
        return true;
    }
    return false;
}

2. <IfModule LiteSpeed> blocks — Apache and Nginx silently skip these, so .htaccess cache headers do not interfere with local dev.

SQLite WAL Mode Check

# Verify WAL mode is active after first boot
docker compose exec app \
  sqlite3 data/videos.db 'PRAGMA journal_mode;'
# Expected output: wal

<?php
// Set on first connection — idempotent
$pdo->exec('PRAGMA journal_mode=WAL');
$pdo->exec('PRAGMA synchronous=NORMAL');
$pdo->exec('PRAGMA cache_size=-32768'); // 32MB page cache

Developer Workflow

# Bootstrap: one command from clone to running platform
docker compose up -d --build

# Seed the database with real trending data
docker compose exec cron php /var/www/html/cron/fetch_videos.php

# Tail the fetcher logs
docker compose logs -f cron

# Open a SQLite shell
docker compose exec app sqlite3 data/videos.db

# Build the production image without dev mounts
docker build --target production -t tvs:latest .

# Check image size
docker images tvs:latest
# Should be ~95MB

Deployment: From Docker Image to LiteSpeed

The production LiteSpeed servers do not run Docker — they are shared hosting. The Docker image serves three purposes:

CI testing — GitHub Actions builds the image and runs PHPUnit inside it
Local dev — Developers run the full stack locally
Staging preview — docker compose up spins up a functional preview before FTP deploy

The actual deploy to TrendVidStream production uses lftp to mirror files to the LiteSpeed server, as covered in other articles in this series.

Results

The Dockerfile enforced PHP 8.3 with identical extensions across the team and CI. Three previously silent bugs (a strftime() locale difference, a missing intl extension on one machine, and a SQLite version discrepancy) were caught before they ever reached production.

This is part of the "Building TrendVidStream" series, documenting the architecture behind a global video directory covering Nordic, Middle Eastern, and Central European regions.

Redis Caching Strategies for Video Content Platforms

ahmet gedik — Sat, 18 Apr 2026 22:00:01 +0000

A video platform that pulls content from seven European regions needs aggressive caching or it folds under its own weight. ViralVidVault curates viral videos from across Europe, and the caching architecture went through several iterations. Here's what stuck.

Why Not Just Use File Cache?

File-based caching works for single-server setups, and it's what ViralVidVault started with. But it has limits:

No atomic operations (race conditions on cache writes)
No built-in expiry (you manage TTLs yourself)
No data structure support (everything is serialize/unserialize)

Redis solves all three while adding sub-millisecond reads.

Data Structures That Match the Domain

The trick with Redis is picking the right data structure for each access pattern.

Hashes for Video Metadata

Each video is a hash with individual fields you can read or update independently:

function cacheVideoMeta(Redis $redis, array $video): void {
    $key = "vid:{$video['id']}";
    $redis->hMSet($key, [
        'title'     => $video['title'],
        'channel'   => $video['channel_title'],
        'thumb'     => $video['thumbnail_url'],
        'views'     => $video['view_count'],
        'region'    => $video['region'],
        'fetched'   => time(),
    ]);
    $redis->expire($key, 21600); // 6h TTL
}

// Update just the view count without touching other fields
function updateViewCount(Redis $redis, string $videoId, int $views): void {
    $redis->hSet("vid:{$videoId}", 'views', $views);
}

Compare this to storing the whole video as a JSON string — updating a single field means deserializing, modifying, and reserializing. Hashes avoid that entirely.

Sorted Sets for Regional Trending

ViralVidVault serves different trending feeds per European region. Sorted sets keep videos ranked by a score you define:

function rebuildRegionalTrending(Redis $redis, PDO $db, string $region): void {
    $key = "trending:{$region}";
    $redis->del($key); // Clear stale data

    $stmt = $db->prepare(
        "SELECT video_id, view_count, published_at FROM videos
         WHERE region = ? AND published_at > datetime('now', '-48 hours')
         ORDER BY view_count DESC LIMIT 100"
    );
    $stmt->execute([$region]);

    $pipe = $redis->pipeline();
    while ($row = $stmt->fetch()) {
        // Score: views weighted by recency
        $age = time() - strtotime($row['published_at']);
        $score = $row['view_count'] / max($age / 3600, 1);
        $pipe->zAdd($key, $score, $row['video_id']);
    }
    $pipe->exec();
    $redis->expire($key, 10800); // 3h TTL
}

// Fetch top trending for display
function getRegionalTrending(Redis $redis, string $region, int $count = 20): array {
    return $redis->zRevRange("trending:{$region}", 0, $count - 1, true);
}

The score formula (views divided by age in hours) naturally pushes fresh viral content above old high-view videos. No application-level sorting needed.

Search Cache with Short TTL

Search results change frequently as new content arrives. Use plain string keys with aggressive TTLs:

function cacheSearchResults(Redis $redis, string $query, array $results): void {
    $key = 'search:' . md5(mb_strtolower(trim($query)));
    $redis->setex($key, 600, json_encode($results)); // 10 minutes
}

function getCachedSearch(Redis $redis, string $query): ?array {
    $key = 'search:' . md5(mb_strtolower(trim($query)));
    $data = $redis->get($key);
    return $data ? json_decode($data, true) : null;
}

Ten minutes is the sweet spot. Long enough to absorb repeated searches (people often search the same terms), short enough that new content appears promptly.

Page Cache in Redis

Full HTML page cache for category and home pages eliminates PHP execution entirely on cache hits:

function serveFromCache(Redis $redis, string $uri): bool {
    $key = 'page:' . md5($uri);
    $html = $redis->get($key);
    if ($html !== false) {
        header('X-Cache: HIT');
        echo $html;
        return true;
    }
    return false;
}

function cachePage(Redis $redis, string $uri, string $html, int $ttl = 10800): void {
    $key = 'page:' . md5($uri);
    $redis->setex($key, $ttl, $html);
}

On ViralVidVault, page cache hits serve in under 5ms. Without cache, a category page with 30 videos takes 80-150ms.

Cache Invalidation Strategy

Two invalidation triggers:

Cron-driven — When the fetcher pulls new videos for a region, bust that region's caches
TTL-driven — Let short-lived caches expire naturally

function invalidateRegion(Redis $redis, string $region): void {
    $pipe = $redis->pipeline();
    // Clear trending for this region
    $pipe->del("trending:{$region}");
    // Clear home page (contains cross-region trending)
    $pipe->del('page:' . md5('/'));
    // Category pages for this region
    foreach (getActiveCategories() as $cat) {
        $pipe->del('page:' . md5("/category/{$cat}"));
    }
    $pipe->exec();
}

Search cache is deliberately left alone — its 10-minute TTL handles staleness. Explicitly invalidating search during a fetch would cause a thundering herd as dozens of users re-execute their queries simultaneously.

Memory Budget

# redis.conf
maxmemory 192mb
maxmemory-policy allkeys-lru

192MB handles the full cache set comfortably. Video metadata hashes are small (under 500 bytes each), page caches are compressed HTML, and sorted sets are just ID-score pairs. LRU eviction means cold data drops automatically without manual cleanup.

TTL Reference

Layer	TTL	Why
Video metadata hashes	6h	Refreshed by cron fetch
Regional trending sets	3h	Rebuilt after each fetch
Page cache (home/category)	3h	Balances freshness vs load
Search results	10min	Users expect near-real-time
Channel data	24h	Rarely changes

The pattern is simple: the more user-facing the data, the shorter the TTL. Backend data that users don't see directly can afford to be stale longer.

This article is part of the Building ViralVidVault series.

Redis Caching Strategies for Video Content Platforms

ahmet gedik — Sat, 18 Apr 2026 10:00:00 +0000

Caching is the difference between a sluggish video platform and one that feels instant. DailyWatch serves trending video content from 8+ regions, and the caching strategy evolved through several iterations before landing on something solid. Here's the architecture.

The Three Cache Layers

Before jumping to Redis, understand what you're layering:

Page cache — Full HTML output stored on disk or in Redis
Data cache — Structured query results (video lists, category data)
Search cache — User query results with TTL-based expiry

Each layer has different invalidation rules and TTLs. Mixing them up is how you end up serving stale content or cache-busting too aggressively.

Redis Data Structures for Video Metadata

Video metadata fits naturally into Redis hashes. Each video gets a hash keyed by its ID:

// Store video metadata as a Redis hash
function cacheVideo(Redis $redis, array $video): void {
    $key = "video:{$video['id']}";
    $redis->hMSet($key, [
        'title'        => $video['title'],
        'channel'      => $video['channel_title'],
        'thumbnail'    => $video['thumbnail_url'],
        'views'        => $video['view_count'],
        'published_at' => $video['published_at'],
        'region'       => $video['region'],
    ]);
    $redis->expire($key, 21600); // 6 hours
}

// Batch fetch for listing pages
function getVideos(Redis $redis, array $ids): array {
    $pipe = $redis->pipeline();
    foreach ($ids as $id) {
        $pipe->hGetAll("video:{$id}");
    }
    return $pipe->exec();
}

Pipelining is essential. A category page might display 30 videos — 30 round trips to Redis would negate the caching benefit entirely.

Sorted Sets for Trending Rankings

Trending videos need ordering. Redis sorted sets handle this without re-sorting on every request:

// Update trending score (view velocity = views per hour)
function updateTrendingScore(Redis $redis, string $videoId, float $velocity): void {
    $redis->zAdd('trending:global', $velocity, $videoId);
    // Per-region sets
    $region = getVideoRegion($videoId);
    $redis->zAdd("trending:{$region}", $velocity, $videoId);
}

// Get top 20 trending for a region
function getTrending(Redis $redis, string $region, int $limit = 20): array {
    return $redis->zRevRange("trending:{$region}", 0, $limit - 1, true);
}

The zRevRange call returns videos sorted by score in descending order. No SQL query, no sorting in PHP — Redis does it in O(log(N)+M) time.

Search Cache with Smart Key Design

Search queries are expensive. Cache them, but design keys that allow partial invalidation:

function getCachedSearch(Redis $redis, string $query, int $page): ?array {
    $key = 'search:' . md5(strtolower(trim($query))) . ":p{$page}";
    $cached = $redis->get($key);
    return $cached ? json_decode($cached, true) : null;
}

function cacheSearch(Redis $redis, string $query, int $page, array $results): void {
    $key = 'search:' . md5(strtolower(trim($query))) . ":p{$page}";
    $redis->setex($key, 600, json_encode($results)); // 10 min TTL
    // Track keys for bulk invalidation
    $redis->sAdd('search:keys', $key);
    $redis->expire('search:keys', 3600);
}

Search cache TTL is intentionally short (10 minutes). Users expect search to reflect recent content, so stale results feel broken even when technically they're just "slightly old."

Cache Invalidation: The Hard Part

Invalidation runs on two triggers:

Cron fetch — When new videos arrive, bust related caches
Admin action — Manual cache clear for specific pages

function invalidateOnFetch(Redis $redis, string $region): void {
    // Clear region-specific trending
    $redis->del("trending:{$region}");
    // Clear home page cache
    $redis->del('page:home');
    // Clear category caches for affected region
    $categories = $redis->sMembers('categories:active');
    $pipe = $redis->pipeline();
    foreach ($categories as $cat) {
        $pipe->del("page:category:{$cat}");
    }
    $pipe->exec();
    // Search cache expires naturally via TTL
}

Notice that search cache is not explicitly invalidated — the short TTL handles it. Over-invalidating search would cause cache stampedes during high-traffic periods.

TTL Strategy Summary

Cache Type	TTL	Rationale
Video metadata	6 hours	Updated on cron fetch cycle
Trending sets	Until next fetch	Rebuilt entirely on new data
Category pages	3 hours	Balance freshness vs load
Search results	10 minutes	Users expect near-real-time
Home page	3 hours	Stale-while-revalidate pattern

Memory Management

Set maxmemory-policy allkeys-lru in Redis config. When memory fills up, the least recently used keys get evicted first. For DailyWatch, 256MB of Redis handles the entire cache layer comfortably — video metadata is small, and page caches are compressed HTML.

# redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru
save 900 1
save 300 10

The save directives create RDB snapshots. If Redis restarts, you lose at most 5 minutes of cache — which rebuilds quickly from the primary SQLite database anyway.

Key Takeaway

Don't cache everything in one flat key-value pattern. Match Redis data structures to your access patterns: hashes for entities, sorted sets for rankings, short-TTL strings for search. The right structure eliminates entire categories of bugs.

This article is part of the Building DailyWatch series.

Concurrent Video Fetching with Go Goroutines Across 8 Global Regions

ahmet gedik — Sat, 18 Apr 2026 00:00:02 +0000

Concurrent Video Fetching with Go Goroutines Across 8 Global Regions

TrendVidStream fetches trending video data from 8 regions: AE, FI, DK, CZ, BE, CH, US, GB. Go's goroutines and channels make concurrent fetching clean and controllable. Here's the production-ready implementation.

Worker Pool Architecture

package fetcher

import (
    "context"
    "log"
    "sync"
    "time"
)

type FetchJob struct {
    Region string
    APIKey string
}

type FetchResult struct {
    Region string
    Videos []Video
    Error  error
    Took   time.Duration
}

type Pool struct {
    workers int
    jobs    chan FetchJob
    results chan FetchResult
    client  *YTClient
    wg      sync.WaitGroup
}

func NewPool(workers int, client *YTClient) *Pool {
    return &Pool{
        workers: workers,
        jobs:    make(chan FetchJob, 20),
        results: make(chan FetchResult, 20),
        client:  client,
    }
}

func (p *Pool) Start(ctx context.Context) {
    for i := 0; i < p.workers; i++ {
        p.wg.Add(1)
        go p.worker(ctx)
    }
    go func() {
        p.wg.Wait()
        close(p.results)
    }()
}

func (p *Pool) worker(ctx context.Context) {
    defer p.wg.Done()
    for {
        select {
        case <-ctx.Done():
            return
        case job, ok := <-p.jobs:
            if !ok {
                return
            }
            start := time.Now()
            videos, err := p.client.FetchTrending(ctx, job.Region, job.APIKey, 50)
            p.results <- FetchResult{
                Region: job.Region, Videos: videos,
                Error: err, Took: time.Since(start),
            }
        }
    }
}

func (p *Pool) Submit(job FetchJob) { p.jobs <- job }
func (p *Pool) Close()             { close(p.jobs) }
func (p *Pool) Results() <-chan FetchResult { return p.results }

YouTube Client for TrendVidStream Regions

package fetcher

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "net/url"
    "time"

    "golang.org/x/time/rate"
)

// Arabic (AE) titles require no special HTTP handling — YouTube returns UTF-8.
// The direction (RTL) is a display concern, not a fetch concern.
type YTClient struct {
    http    *http.Client
    limiter *rate.Limiter
}

func NewYTClient() *YTClient {
    return &YTClient{
        http: &http.Client{
            Timeout: 30 * time.Second,
            Transport: &http.Transport{
                MaxIdleConnsPerHost: 10,
            },
        },
        limiter: rate.NewLimiter(rate.Limit(4), 8), // 4 req/s, burst 8
    }
}

func (c *YTClient) FetchTrending(ctx context.Context, region, apiKey string, n int) ([]Video, error) {
    if err := c.limiter.Wait(ctx); err != nil {
        return nil, fmt.Errorf("rate limit: %w", err)
    }

    q := url.Values{
        "part":       {"snippet,statistics"},
        "chart":      {"mostPopular"},
        "regionCode": {region},
        "maxResults": {fmt.Sprintf("%d", n)},
        "key":        {apiKey},
    }

    req, _ := http.NewRequestWithContext(
        ctx, http.MethodGet,
        "https://www.googleapis.com/youtube/v3/videos?"+q.Encode(),
        nil,
    )

    resp, err := c.http.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    switch resp.StatusCode {
    case http.StatusOK:
        // good
    case http.StatusTooManyRequests:
        // Back off and retry once
        select {
        case <-time.After(10 * time.Second):
        case <-ctx.Done():
            return nil, ctx.Err()
        }
        return c.FetchTrending(ctx, region, apiKey, n)
    default:
        return nil, fmt.Errorf("youtube API HTTP %d for region %s", resp.StatusCode, region)
    }

    var payload struct {
        Items []struct {
            ID      string `json:"id"`
            Snippet struct {
                Title             string `json:"title"`  // UTF-8, handles Arabic natively
                ChannelTitle      string `json:"channelTitle"`
                DefaultAudioLang  string `json:"defaultAudioLanguage"`
            } `json:"snippet"`
            Statistics struct {
                ViewCount string `json:"viewCount"`
            } `json:"statistics"`
        } `json:"items"`
    }
    if err := json.NewDecoder(resp.Body).Decode(&payload); err != nil {
        return nil, err
    }

    vids := make([]Video, 0, len(payload.Items))
    for _, item := range payload.Items {
        vids = append(vids, Video{
            VideoID:      item.ID,
            Title:        item.Snippet.Title,
            ChannelTitle: item.Snippet.ChannelTitle,
            Language:     item.Snippet.DefaultAudioLang,
            Region:       region,
        })
    }
    return vids, nil
}

Running the Pipeline

var tvStreamRegions = []string{"AE", "FI", "DK", "CZ", "BE", "CH", "US", "GB"}

func RunPipeline(ctx context.Context, apiKey string) ([]Video, error) {
    client := NewYTClient()
    pool := NewPool(3, client)  // 3 workers for 8 regions

    ctx, cancel := context.WithTimeout(ctx, 3*time.Minute)
    defer cancel()

    pool.Start(ctx)

    go func() {
        for _, r := range tvStreamRegions {
            pool.Submit(FetchJob{Region: r, APIKey: apiKey})
        }
        pool.Close()
    }()

    var all []Video
    var errCount int
    for result := range pool.Results() {
        if result.Error != nil {
            log.Printf("[%s] error: %v (took %v)", result.Region, result.Error, result.Took)
            errCount++
            continue
        }
        log.Printf("[%s] %d videos in %v", result.Region, len(result.Videos), result.Took)
        all = append(all, result.Videos...)
    }

    if len(all) == 0 {
        return nil, fmt.Errorf("all regions failed (%d errors)", errCount)
    }
    return all, nil
}

Performance for TrendVidStream

Workers	Time (8 regions)	Notes
1	~16s	Sequential
3	~6s	Good balance
8	~3s	Full parallel

Three workers handles TrendVidStream's 8 regions in about 6 seconds — fast enough for cron-based fetching while staying well under YouTube's rate limits. The rate limiter (4 req/s) ensures we never burst past API limits regardless of the worker count.

This article is part of the Building TrendVidStream series. Check out TrendVidStream to see these techniques in action.

Dockerizing a Video Platform: From Development to Production

ahmet gedik — Fri, 17 Apr 2026 14:00:01 +0000

When your video platform runs across multiple European regions, environment consistency stops being a nice-to-have and becomes essential. Here's how I Dockerized ViralVidVault, a viral video vault that curates trending content across European countries, from a manual setup to a fully containerized workflow.

The Stack

ViralVidVault runs on PHP 8.3, SQLite, and LiteSpeed. No heavy database server, no message queue — the simplicity is deliberate. Docker's job is to wrap this into something portable and predictable.

The containerization goals:

One command to spin up the full environment locally
Identical behavior between dev laptop and production hosting
SQLite data survives container rebuilds

Multi-Stage Dockerfile

Keep build tools out of the production image:

# Stage 1: Build
FROM php:8.3-cli AS builder

RUN apt-get update && apt-get install -y \
    libsqlite3-dev libcurl4-openssl-dev libzip-dev \
    && docker-php-ext-install pdo_sqlite curl zip opcache

WORKDIR /app
COPY composer.json composer.lock ./
RUN curl -sS https://getcomposer.org/installer | php \
    && php composer.phar install --no-dev --optimize-autoloader

# Stage 2: Runtime
FROM litespeedtech/openlitespeed:1.7.19-lsphp83

COPY --from=builder /usr/local/lib/php/extensions/ \
     /usr/local/lsws/lsphp83/lib/php/extensions/
COPY --from=builder /app/vendor /var/www/html/vendor
COPY . /var/www/html/

RUN mkdir -p /var/www/html/data \
    && chown -R nobody:nogroup /var/www/html/data

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost/health || exit 1

EXPOSE 80
CMD ["/usr/local/lsws/bin/lswsctrl", "start"]

The builder stage handles Composer dependencies and PHP extension compilation. The runtime stage copies only the artifacts it needs. This cuts the image from over 1GB to roughly 400MB.

Docker Compose with SQLite Volumes

SQLite needs careful volume management. Mount the entire data directory, not individual .db files — SQLite creates -wal and -shm companion files that must live in the same directory:

# docker-compose.yml
version: '3.8'

services:
  viralvidvault:
    build: .
    ports:
      - "8080:80"
    volumes:
      - app_data:/var/www/html/data
    environment:
      - APP_ENV=production
      - SQLITE_JOURNAL_MODE=WAL
      - FETCH_REGIONS=US,GB,PL,NL,SE,NO,AT
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 512M

volumes:
  app_data:
    driver: local

The FETCH_REGIONS environment variable drives which European regions the cron fetcher targets. Different from other sites in the family — ViralVidVault focuses on European content.

LiteSpeed Virtual Host Config

OpenLiteSpeed uses XML config files. Override the default virtual host:

<!-- conf/vhosts/app/vhconf.xml -->
<virtualHost>
  <docRoot>/var/www/html/public</docRoot>
  <index useServer="0">
    <indexFiles>index.php</indexFiles>
  </index>
  <rewrite>
    <enable>1</enable>
    <rules>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?url=$1 [QSA,L]
    </rules>
  </rewrite>
  <phpIniOverride>
php_value opcache.validate_timestamps 0
php_value opcache.memory_consumption 128
  </phpIniOverride>
</virtualHost>

Setting opcache.validate_timestamps to 0 in production is safe inside containers — files don't change at runtime, so skipping stat calls gives a measurable performance boost.

Development Override

For local development, add live code mounting and debugging tools:

# docker-compose.dev.yml
services:
  viralvidvault:
    volumes:
      - .:/var/www/html
      - app_data:/var/www/html/data
    environment:
      - APP_ENV=development
      - DISPLAY_ERRORS=1
    ports:
      - "8080:80"
      - "9003:9003"  # Xdebug

Run both with docker compose -f docker-compose.yml -f docker-compose.dev.yml up. The bind mount overlays the built image with your local source, so edits appear instantly without rebuilding.

Handling SQLite Locking in Containers

SQLite's biggest gotcha in Docker: file locking. WAL mode is mandatory for any concurrent read/write scenario:

// Ensure WAL mode on every connection
$db = new PDO('sqlite:/var/www/html/data/videos.db');
$db->exec('PRAGMA journal_mode=WAL');
$db->exec('PRAGMA busy_timeout=5000'); // Wait up to 5s for locks
$db->exec('PRAGMA synchronous=NORMAL'); // Good balance of safety and speed

Without busy_timeout, concurrent requests during a cron fetch will get SQLITE_BUSY errors. Five seconds is generous but prevents any realistic timeout scenario.

What I Learned

Named volumes, not bind mounts for production data. Bind mounts to host directories have permission headaches across different Docker hosts.
OPcache preloading inside containers is free performance. Precompile your autoloader and router.
Don't run cron inside the app container. Use a separate container or host-level cron that hits the app's task endpoint.

The container setup took a day to get right. It saves that time back on every deploy, every new developer onboarding, and every "it works on my machine" conversation that no longer happens.

This article is part of the Building ViralVidVault series.

Redis Caching Strategies for Video Content Platforms

ahmet gedik — Fri, 17 Apr 2026 02:00:01 +0000

Trending video data is read-heavy: thousands of page views for every one database write. TopVideoHub covers 9 Asia-Pacific regions, and each region's trending list changes only every few hours. Redis turns that pattern into a performance advantage.

This article covers the cache layers, Redis data structures, and invalidation strategies we use.

Why Redis on Top of PHP File Cache?

The current stack uses a PHP file-based cache (data/pagecache/*.html). That works fine for a single server. Redis becomes valuable when:

Multiple PHP-FPM workers need shared cache state
You want sub-millisecond reads with O(1) lookup
You need pub/sub for cache invalidation events
You want TTL management without file system overhead

The architecture targets a Redis instance as a middle tier between PHP and SQLite.

Data Structure Choices

Category Metadata → Redis Hashes

<?php

class CategoryCache
{
    private const TTL_CATEGORIES = 86400; // 24 hours

    public function setAll(array $categories): void
    {
        $pipe = $this->redis->pipeline();

        foreach ($categories as $cat) {
            // Hash per category — individual field reads are O(1)
            $key = "category:{$cat['slug']}";
            $pipe->hMSet($key, [
                'id'          => $cat['id'],
                'name'        => $cat['name'],
                'slug'        => $cat['slug'],
                'video_count' => $cat['video_count'],
                'updated_at'  => $cat['updated_at'],
            ]);
            $pipe->expire($key, self::TTL_CATEGORIES);
        }

        // Also store the sorted category index
        $pipe->del('categories:index');
        foreach ($categories as $rank => $cat) {
            $pipe->zAdd('categories:index', $cat['video_count'], $cat['slug']);
        }
        $pipe->expire('categories:index', self::TTL_CATEGORIES);

        $pipe->execute();
    }

    public function getTopN(int $n = 15): array
    {
        // ZREVRANGE: top N by video count
        $slugs = $this->redis->zRevRange('categories:index', 0, $n - 1);
        if (empty($slugs)) {
            return [];
        }

        $pipe = $this->redis->pipeline();
        foreach ($slugs as $slug) {
            $pipe->hGetAll("category:{$slug}");
        }
        return $pipe->execute();
    }
}

Search Results → Redis Strings with Prefix Keys

<?php

class SearchCache
{
    private const TTL_SEARCH = 21600; // 6 hours

    public function get(string $query, string $region): ?array
    {
        $key = $this->key($query, $region);
        $data = $this->redis->get($key);
        return $data ? json_decode($data, true) : null;
    }

    public function set(string $query, string $region, array $results): void
    {
        $key = $this->key($query, $region);
        $this->redis->setEx($key, self::TTL_SEARCH, json_encode($results));
    }

    private function key(string $query, string $region): string
    {
        // Normalize: lowercase, trim, collapse spaces
        $normalized = strtolower(trim(preg_replace('/\s+/', ' ', $query)));
        return 'search:' . $region . ':' . md5($normalized);
    }

    public function invalidateRegion(string $region): int
    {
        // Use SCAN to find and delete all search keys for a region
        $deleted = 0;
        $cursor = null;
        do {
            [$cursor, $keys] = $this->redis->scan(
                $cursor,
                ['match' => "search:{$region}:*", 'count' => 100]
            );
            if ($keys) {
                $deleted += $this->redis->del($keys);
            }
        } while ($cursor !== 0);

        return $deleted;
    }
}

Cache Invalidation on Cron Fetch

The cron job runs every 4 hours for TopVideoHub. After fetching, invalidation is surgical, not a full flush:

<?php

class CronFetcher
{
    public function run(): void
    {
        foreach (FETCH_REGIONS as $region) {
            $videos = $this->fetchTrending($region);

            if ($this->hasChanged($region, $videos)) {
                // Update SQLite
                $this->db->upsertVideos($videos, $region);

                // Invalidate only this region's cache
                $this->videoCache->invalidateRegion($region);
                $this->searchCache->invalidateRegion($region);

                // Repopulate immediately so next request hits cache
                $this->videoCache->setTrending($region, $videos);

                echo "[{$region}] refreshed: " . count($videos) . " videos\n";
            } else {
                // Extend TTL without repopulating
                $this->videoCache->touchTrending($region);
                echo "[{$region}] unchanged, TTL extended\n";
            }
        }

        // Category counts change after any region update
        $this->categoryCache->rebuild();
    }

    private function hasChanged(string $region, array $newVideos): bool
    {
        $existing = $this->videoCache->getTrending($region, 1);
        if ($existing === null) {
            return true; // Cache miss → assume changed
        }
        return $existing[0]['id'] !== $newVideos[0]['id'];
    }
}

Regional TTL Strategy

Different Asia-Pacific regions update at different rates. Tailor TTLs accordingly:

<?php

const REGION_TTL = [
    // High-frequency regions (major markets)
    'JP' => 7200,   // 2h — Japan trends fast
    'KR' => 7200,   // 2h — Korea K-pop events
    'US' => 10800,  // 3h — standard
    'GB' => 10800,  // 3h — standard

    // Medium-frequency regions
    'TW' => 10800,  // 3h
    'SG' => 14400,  // 4h
    'HK' => 14400,  // 4h

    // Lower-frequency regions
    'VN' => 21600,  // 6h
    'TH' => 21600,  // 6h
];

Connection Pooling

<?php

class RedisPool
{
    private static ?Redis $instance = null;

    public static function get(): Redis
    {
        if (self::$instance === null) {
            $redis = new Redis();
            $redis->pconnect(
                host: getenv('REDIS_HOST') ?: '127.0.0.1',
                port: (int)(getenv('REDIS_PORT') ?: 6379),
                timeout: 1.0,
            );
            $redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_NONE);
            $redis->setOption(Redis::OPT_PREFIX, 'tvh:');
            self::$instance = $redis;
        }
        return self::$instance;
    }
}

Memory Sizing

For 9 regions × 50 videos, with each JSON video object ~800 bytes:

Trending lists: 9 × 50 × 800B ≈ 360KB
Category hashes: ~5KB
Search cache (peak): ~500 entries × 3KB ≈ 1.5MB

A 32MB Redis instance handles TopVideoHub traffic comfortably with room to grow.

Read-Through Pattern

<?php

function getTrending(string $region): array
{
    // 1. Redis (sub-millisecond)
    $cached = RedisPool::get()->lRange("tvh:trending:{$region}", 0, 19);
    if (!empty($cached)) {
        return array_map(fn($v) => json_decode($v, true), $cached);
    }

    // 2. SQLite (single-digit milliseconds with WAL mode)
    $videos = Database::getInstance()->getTrending($region, 20);

    // 3. Populate Redis for next request
    if (!empty($videos)) {
        $pipe = RedisPool::get()->pipeline();
        $pipe->del("tvh:trending:{$region}");
        foreach ($videos as $v) {
            $pipe->rPush("tvh:trending:{$region}", json_encode($v));
        }
        $pipe->expire("tvh:trending:{$region}", REGION_TTL[$region] ?? 10800);
        $pipe->execute();
    }

    return $videos;
}

This three-layer approach keeps TopVideoHub responsive for K-pop trend spikes from Korea and gaming surges from Japan without hammering SQLite on every request.

This is part of the "Building TopVideoHub" series, documenting the architecture behind a video discovery platform covering 9 Asia-Pacific regions.

Dockerizing a Video Platform: From Development to Production

ahmet gedik — Thu, 16 Apr 2026 14:00:01 +0000

Running a video discovery platform across multiple environments gets messy fast. Different PHP versions, missing extensions, inconsistent configs — the usual headaches. Here's how I containerized DailyWatch using Docker, going from a bare-metal setup to a reproducible, deployable container image.

Why Docker for a PHP + SQLite Stack?

DailyWatch aggregates trending video content from 8+ regions. The stack is intentionally simple: PHP 8.3, SQLite, and LiteSpeed. No PostgreSQL cluster, no Redis dependency in production. That simplicity is a strength when containerizing — fewer moving parts means fewer things to break.

The main goals were:

Identical environments across dev and production
Easy onboarding (one command to spin up)
Predictable deployments with no "works on my machine" surprises

Multi-Stage Dockerfile

A single-stage build bloats the image with build tools you never need at runtime. Multi-stage keeps it lean:

# Stage 1: Build dependencies
FROM php:8.3-cli AS builder

RUN apt-get update && apt-get install -y \
    libsqlite3-dev \
    libcurl4-openssl-dev \
    libzip-dev \
    && docker-php-ext-install pdo_sqlite curl zip opcache

COPY composer.json composer.lock /app/
WORKDIR /app
RUN curl -sS https://getcomposer.org/installer | php && \
    php composer.phar install --no-dev --optimize-autoloader

# Stage 2: Production image
FROM litespeedtech/openlitespeed:1.7.19-lsphp83

COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lsws/lsphp83/lib/php/extensions/
COPY --from=builder /app/vendor /var/www/html/vendor
COPY . /var/www/html/

# SQLite database directory
RUN mkdir -p /var/www/html/data && \
    chown -R nobody:nogroup /var/www/html/data

EXPOSE 80 443
CMD ["/usr/local/lsws/bin/lswsctrl", "start"]

The builder stage compiles extensions and installs Composer packages. The production stage starts from the official OpenLiteSpeed image and copies only what's needed.

Volume Mounts for SQLite Persistence

SQLite files live on disk, so you need volumes to survive container restarts. This is the part most tutorials skip:

# docker-compose.yml
version: '3.8'

services:
  web:
    build: .
    ports:
      - "8080:80"
    volumes:
      - sqlite_data:/var/www/html/data
      - page_cache:/var/www/html/data/pagecache
    environment:
      - APP_ENV=production
      - SQLITE_JOURNAL_MODE=WAL
    restart: unless-stopped

volumes:
  sqlite_data:
    driver: local
  page_cache:
    driver: local

Critical detail: SQLite in WAL mode needs the -wal and -shm files to live alongside the main .db file. Mount the entire data/ directory, not individual files.

LiteSpeed Configuration Inside Docker

OpenLiteSpeed uses XML-based virtual host configs. Override the default one:

<!-- conf/vhosts/videoplatform/vhconf.xml -->
<virtualHost>
  <docRoot>/var/www/html/public</docRoot>
  <index useServer="0">
    <indexFiles>index.php</indexFiles>
  </index>
  <rewrite>
    <enable>1</enable>
    <rules>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?url=$1 [QSA,L]
    </rules>
  </rewrite>
  <cache>
    <enableCache>1</enableCache>
    <cacheStorePath>/tmp/lscache/</cacheStorePath>
  </cache>
</virtualHost>

The cache store path points to /tmp inside the container so it doesn't pollute the persistent volume.

Development vs Production Compose Files

For local development, override the production compose with hot-reload mounts:

# docker-compose.dev.yml
services:
  web:
    build:
      context: .
      target: builder  # Use the builder stage for dev tools
    volumes:
      - .:/var/www/html  # Live code reload
      - sqlite_data:/var/www/html/data
    environment:
      - APP_ENV=development
      - DISPLAY_ERRORS=1

Run with docker compose -f docker-compose.yml -f docker-compose.dev.yml up. Changes to PHP files reflect immediately without rebuilding.

Health Checks

Don't skip this. A container that starts isn't necessarily a container that works:

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost/health || exit 1

On DailyWatch, the /health endpoint checks PHP, SQLite connectivity, and disk space on the data volume.

Lessons Learned

SQLite locking: Use WAL mode and keep write operations short. Long-running imports should use a separate connection with busy timeout set.
OPcache in containers: Set opcache.validate_timestamps=0 in production — files don't change inside a running container, so skip the stat calls.
Image size: The multi-stage approach brought the image from 1.2GB down to 380MB.

Containerizing a simple stack like PHP + SQLite is one of those things that sounds trivial until you hit the edge cases. Volume ownership, SQLite journal files, and LiteSpeed's config format all needed attention. But once it works, every deploy is just docker compose up -d.

This article is part of the Building DailyWatch series.