Ever watched your staging server just die? Mine did. Both CPUs at 100%, memory maxed, totally frozen.

The culprit? Laravel's scheduler running heavy jobs from production. Price exports, syncs, data crunches just hammering a tiny 2 vCPU droplet.

The fix: split your schedule() by environment. Run heavy jobs once daily on staging instead of hourly. Keep only essentials.

Result? CPU dropped from 100% to 20%. Staging responsive, production untouched.

Don't copy production schedules blindly.

dev.to/tegos/dont-let-your-staging-server-die-separate-task-scheduling-in-laravel-420o

Don't Let Your Staging Server Die: Separate Task Scheduling in Laravel

From: dev.to

Ever inherited a production app still chilling on Ubuntu 20.04 in late 2025? 😅 Yeah, me neither... until last week.

Direct jump to 24.04 LTS? Nope, Ubuntu says no. Security updates long gone, heart racing every time I ssh in.

The trick: snapshots + temp droplet + step-by-step upgrade path (20.04 → 22.10 → 23.04 → 23.10 → 24.04 + Nginx 1.28).
Takes about an hour, mostly waiting for reboots and downloading packages. App never blinked.

If you're stuck on ancient Ubuntu, this method works. Full commands and details here: dev.to/tegos/from-20-to-24-lts-safe-way-to-upgrade-ubuntu-on-digitalocean-4gb

From 20 to 24 LTS: Safe Way to Upgrade Ubuntu on DigitalOcean

From: dev.to

Ever assumed Laravel's after() method runs after validation passes?

Plot twist: it runs after validation completes - even when it fails 😅

Found this out when DB queries were hitting on invalid requests. Worse - got 500 errors when callbacks tried processing bad data.

Quick fix? Check if validator has errors first and bail early.

But real talk - DB queries don't belong in Form Requests. Keep validation fast, move heavy stuff to services.
dev.to/tegos/laravel-validation-after-after-what-exactly-28fa

Laravel Validation after() - After What, Exactly?

From: dev.to

🔧 Fixed Laravel Bug (and Got My PR Merged!)

Tried to delete 500 rows with batch... Laravel deleted 500,000+ at once 😅

Turns out, DELETE queries with JOIN + LIMIT/ORDER BY were dropping those clauses - wiping out way more than intended.

I patched it so Laravel now keeps the full query and lets MySQL handle errors properly.
Merged into Laravel 13.x 🎉

✅ No more silent mass deletions
🙌 Open source wins again

dev.to/tegos/battling-laravels-sneaky-deletes-how-i-got-order-by-and-limit-to-play-nice-with-joins-ng9

Battling Laravel's Sneaky DELETEs: How I Got ORDER BY and LIMIT to Play Nice with Joins

From: dev.to

Laravel Performance Tip 🚀
Stop hitting the cache twice! Many devs do `Cache::has()` before `Cache::get()` - but that doubles the work for the same key.
Benchmarks say it all:
- ⏱ Execution: 14ms → 6ms
- 🧠 Memory: 47MB → 43MB
- 🔑 Cache calls: 2 → 1
✅ Fix: skip `has()`, just `get()` and check for null:

$value = Cache::get($key);
if ($value !== null) return $value;

Laravel Cache Tip: Avoid Redundant has/missing Calls

From: dev.to