Forem: Antonios Thanasis

How We Fixed a Puppeteer Memory Leak in a Laravel IoT App

Antonios Thanasis — Tue, 03 Mar 2026 10:02:25 +0000

We were running a Laravel IoT application on an Azure D2s_v3 VM (2 vCPUs, 8GB RAM) and kept hitting a frustrating problem — randomly, Docker commands would hang or fail entirely. No obvious reason. Just… dead.

After digging, we found the culprit: a Puppeteer scraper silently leaking Chromium processes every time it ran multiple scrapes.

🔍 Investigation

First thing we checked was memory:

ps aux --sort=-%mem | head -20

We spotted multiple orphaned Chromium processes, each eating ~90MB:

green  10374  0.1  1.1  /usr/lib/chromium/chrome --type=renderer --headless ...
green  10367  0.1  1.1  /usr/lib/chromium/chrome --type=renderer --headless ...
green  10347  0.9  1.0  /usr/lib/chromium/chrome --headless --enable-automation ...

Docker stats confirmed the problem:

sudo docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}"

scraper_1       320.5MiB / 7.772GiB  ← 🚨
app_1           143.8MiB / 7.772GiB
queue_worker_1  120.5MiB / 7.772GiB

The scraper container was using much more memory than expected, and it kept growing over time.

🕵️ The Root Cause

The scraper visits router admin pages using Puppeteer to collect bandwidth data. Originally, the code launched one browser per device:

Sequential failures left Chromium processes orphaned.
Memory usage grew with each failed scrape.
Docker eventually ran out of memory or hung.

Original Problematic Pattern

// ❌ Launches a browser per URL
const browser = await puppeteer.launch();
const page = await browser.newPage();

try {
    await page.goto(url);
    // scrape logic
    await browser.close(); // only runs on success
} catch (err) {
    // may never reach browser.close()
}

Each failure left a Chromium instance alive.
With 15+ routers, these quickly stacked up.

✅ The Fix: Single Browser, Multiple Pages

Instead of launching a browser per device, we:

Launch one shared browser.
Open/close a page per URL.
Always close the browser in a finally block.

Runner (scraper logic)

const runner = async ({ url, browser }) => {
    const page = await browser.newPage();

    try {
        // Go to the router URL
        await page.goto(url, { waitUntil: 'load', timeout: 15000 });

        // Fill in login form
        await page.$eval('input[name="username"]', (el, v) => el.value = v, config.teltonika_username);
        await page.$eval('input[name="password"]', (el, v) => el.value = v, config.teltonika_password);
        await page.$eval('input[type="submit"]', btn => btn.click());

        // Wait for page to load after login
        await page.waitForTimeout(15000);

        // Scrape the values
        const sent = await page.$eval("#lb_tx_sum", el => el.textContent.trim());
        const received = await page.$eval("#lb_rx_sum", el => el.textContent.trim());
        const total_today_usage = await page.$eval("#lb_all_sum", el => el.textContent.trim());

        return { fields: { sent, received, total_today_usage } };

    } catch (err) {
        throw err; // let the caller handle errors
    } finally {
        // Always close the page to prevent leaks
        await page.close();
    }
};

Main Scraper Loop

const browser = await puppeteer.launch({
    executablePath: process.env.PUPPETEER_EXECUTABLE_PATH,
    args: ["--ignore-certificate-errors", "--no-sandbox", "--disable-dev-shm-usage"]
});

try {
    for (const dom of domains) {
        const results = await teltonika.exec({ id: dom.id, url: dom.url, browser });
        // send results to API
    }
} finally {
    await browser.close(); // ✅ guaranteed cleanup
}

📊 Results

Metric	Before	After
Scraper container memory	320.5 MiB	34.77 MiB
Orphaned Chromium processes	3+ (growing)	0 ✅
VM RAM usage	7/8 GB	Stable
Docker commands failing	Frequently	Never

That's a 10x memory reduction from a single finally block.

🧠 Key Takeaways

Use try/catch/finally with Puppeteer — ensures browser cleanup even if an error occurs.
Do not launch one browser per URL — reuse a single instance for multiple pages.
Set timeouts for goto, waitForSelector, and waitForTimeout — avoids hangs on unreachable hosts.
Scrape sequentially for many devices — parallel Chromium launches explode memory usage.
Monitor with ps aux | grep chromium — if processes accumulate, you have a leak.

🔧 Bonus: Quick Cleanup if You're Already Leaking

If you're in this situation right now and need to free memory immediately:

# Kill all orphaned Chromium
pkill -f chromium

# Free OS cache (safe)
sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

# Add swap as a safety net
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

This approach ensures Puppeteer scrapers are robust, memory-efficient, and production-safe, even when scraping dozens of devices sequentially.

Deploy Your Laravel Demo for Free — Domain, MySQL & Hosting at $0

Antonios Thanasis — Sun, 22 Feb 2026 14:02:11 +0000

If you've built a Laravel project and need a live demo link — for a portfolio, a client presentation, or just to share with friends — spinning up a VPS just to host a demo feels like overkill.

InfinityFree gives you:

🌐 A free subdomain (yourapp.great-site.net or .epizy.com)
🗄️ A free MySQL database
☁️ PHP hosting

All for $0.

The catch? It's not a typical shared host. There are real restrictions that break a standard Laravel deployment out of the box. This post documents exactly what breaks and how to fix every single one of them — based on a real deployment I did for a Laravel social media app.

⚠️ Know the Limitations First

Before you start, understand what you're working with:

Feature	Available?
Free subdomain	✅ Yes
Free MySQL database	✅ Yes
PHP support	✅ Yes
File Manager (browser-based)	✅ Yes
SSH access	❌ No
`php artisan` commands	❌ No
Symlinks (`storage:link`)	❌ No
`open_basedir` restriction	❌ PHP only reads inside `htdocs/`
Composer on server	❌ No

🔴 The open_basedir restriction is the biggest gotcha. PHP will refuse to read any file outside of htdocs/ — which completely breaks Laravel's default folder structure.

Step 1 — Prepare Your Project Locally

Set your .env for production

APP_NAME=YourApp
APP_ENV=production
APP_KEY=base64:YOUR_32_CHAR_KEY_HERE==
APP_DEBUG=true   # temporarily true to see errors
APP_URL=http://yourapp.great-site.net

DB_HOST=sql123.epizy.com   # from your cPanel
DB_DATABASE=epiz_xxxxx_dbname
DB_USERNAME=epiz_xxxxx_user
DB_PASSWORD=yourpassword

💡 You can't run php artisan key:generate on InfinityFree. Generate your APP_KEY locally and paste it in. It must start with base64:.

Package your files into two ZIPs

The vendor/ folder is typically 30–50MB which exceeds the File Manager upload limit. Split it:

# ZIP 1 — everything except vendor/
zip -r project.zip . --exclude="vendor/*" --exclude=".git/*"

# ZIP 2 — vendor/ folder only
zip -r vendor.zip vendor/

Step 2 — Upload via File Manager

FTP may not connect reliably on InfinityFree's free tier. Use the built-in File Manager in your cPanel instead:

Log in to InfinityFree → open File Manager
Navigate to htdocs/
Upload project.zip → right-click → Extract
Upload vendor.zip → extract into the same folder
Upload your .env file into the project root

✅ Everything — and I mean everything — must be inside htdocs/. Due to open_basedir, PHP cannot access any path above it.

Your final directory structure should look like this:

htdocs/
├── index.php        ← moved from public/
├── .htaccess        ← moved from public/
├── storage/
│   └── avatars/     ← manually created for uploads
├── app/
├── bootstrap/
├── config/
├── database/
├── resources/
├── routes/
├── vendor/
├── .env
└── ...

Step 3 — Fix index.php

Laravel's default public/index.php references ../vendor and ../bootstrap — paths that go outside htdocs/. Since everything is now flat inside htdocs/, you need to remove the ../.

Here's the full corrected index.php:

<?php

// Temporary — remove once everything works
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

define('LARAVEL_START', microtime(true));

// ✅ No more ../ — everything is in htdocs/
require __DIR__.'/vendor/autoload.php';

$app = require_once __DIR__.'/bootstrap/app.php';

$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

$response->send();

$kernel->terminate($request, $response);

The only change from the default: __DIR__.'/../vendor' → __DIR__.'/vendor' (same for bootstrap).

Step 4 — Fix File Uploads (No storage:link)

php artisan storage:link creates a symlink from public/storage to storage/app/public. Symlinks don't work on InfinityFree.

The fix is to bypass Laravel's storage system for uploads and write directly to the web-accessible folder using $_SERVER['DOCUMENT_ROOT'].

// ❌ Default Laravel — breaks on InfinityFree
$attributes['avatar'] = request('avatar')->store('avatars', 'public');

// ✅ InfinityFree-compatible
if (request('avatar')) {
    $file     = request('avatar');
    $filename = time().'.'.$file->getClientOriginalExtension();
    $dest     = $_SERVER['DOCUMENT_ROOT'].'/storage/avatars';

    $file->move($dest, $filename);
    $attributes['avatar'] = 'avatars/' . $filename;
}

Files saved this way are immediately accessible at:

yourapp.great-site.net/storage/avatars/filename.jpg

✅ Make sure the htdocs/storage/avatars/ folder exists before uploading. Create it manually in File Manager.

Step 5 — Set Up the Database

Since there's no SSH, you can't run php artisan migrate. Export your schema locally and import it via phpMyAdmin:

# Export locally
mysqldump -u root -p your_local_db --no-data > schema.sql

Then in InfinityFree cPanel:

Go to MySQL Databases → create a database and user
Open phpMyAdmin
Select your new database → click Import → upload your .sql file

Errors You'll Hit & How to Fix Them

Error	Cause	Fix
`403 Forbidden`	No `index.php` found in `htdocs/`	Move `public/` contents into `htdocs/`
`HTTP 500`	Missing `APP_KEY` in `.env`	Set `APP_KEY` manually starting with `base64:`
`open_basedir restriction`	Files placed outside `htdocs/`	Move everything inside `htdocs/`, fix `index.php` paths
Images not loading	`storage:link` not supported	Use `DOCUMENT_ROOT` to write uploads directly to `htdocs/storage/`

✅ Deployment Checklist

Before going live, run through this:

[ ] APP_KEY set in .env (starts with base64:...)
[ ] All files inside htdocs/ — nothing outside
[ ] index.php uses __DIR__.'/vendor' not __DIR__.'/../vendor'
[ ] .htaccess moved from public/ to htdocs/
[ ] vendor/ folder uploaded and extracted
[ ] Database schema imported via phpMyAdmin
[ ] htdocs/storage/avatars/ folder created manually
[ ] File upload controller uses $_SERVER['DOCUMENT_ROOT']
[ ] APP_DEBUG set to false when done ✅

Final Thoughts

InfinityFree is not for production. There's no SSH, no queue workers, no scheduler, and performance is limited. But for demo projects, portfolios, and proof-of-concept apps it does exactly what it promises — gets your Laravel app live with a real URL, a real database, and zero cost.

If you outgrow it, the same codebase deploys cleanly to any proper VPS — just reverse the index.php paths and re-run php artisan storage:link.

Built and deployed a Laravel project on InfinityFree? Drop your experience in the comments — especially if you hit an error not covered here! 👇

Queue Runs in Sync Mode Despite QUEUE_CONNECTION=database in .env

Antonios Thanasis — Fri, 13 Feb 2026 14:03:42 +0000

Queue Runs in Sync Mode Despite `QUEUE_CONNECTION=database` in `.env`

Sometimes after switching your queue connection from sync to database, jobs still run synchronously — or nothing works as expected.

The culprit is usually Laravel's configuration cache.

Even if your .env is correct:

QUEUE_CONNECTION=database

Laravel may still be reading a stale cached config.

✅ Fix

Run these two commands:

php artisan config:clear
php artisan queue:restart

config:clear — removes the cached configuration so Laravel reads your .env fresh
queue:restart — signals running queue workers to restart and pick up the new config

After that, your queue should correctly use the database driver. 🚀

Happy coding!