A peculiar situation with Larave

Thành (Back-end Engineer) ran into a bug: the first request could read values via env(), but the second request… just failed.

Hùng (Front-end Engineer) noticed a similar issue after deployment: his config values didn’t match what he had locally.

After some head-scratching and debugging, it turned out both issues were deeply related.

Laravel, dotenv, and the trickery called config:cache

Here’s the root of the problem:

• Laravel doesn’t recommend calling env() directly in your app logic after the app has booted.
• In production, Laravel strongly recommends (and practically requires) running php artisan config:cache, which compiles a static config file for faster performance.
• After running config:cache, direct env() calls won’t work reliably anymore. You might get null or inconsistent results, especially under concurrent requests.

Thành’s bug:
He called env() during runtime, not in the initial config → so on the second request, the value was gone.

Why Laravel behaves this way:
Laravel wants you to freeze all config values at deploy time using config:cache, so the app doesn’t rely on ENV at runtime.

Switching gears to AWS Lambda and NodeJS…

Flashback to a project from a year ago using AWS Lambda (NodeJS). AWS deprecated Node v6 and suggested upgrading to v8. Sounds simple, but after the upgrade, we hit a timezone bug:

We expected it to print in Japan time (JST) → It printed in UTC.

After investigation, here’s what we found:

• The app used process.env.TZ = ‘Asia/Tokyo’ inside the code – before initializing the app.
• But this didn’t work anymore.

Turns out, this was a trap:

In NodeJS, once new Date() is called, the timezone is cached based on the TZ environment variable.

In Lambda, AWS might call new Date() before your code runs (e.g., for logging or internal init) → meaning your late-assigned TZ doesn’t work.

Fix: Set TZ directly in Lambda’s environment settings, not in your code.