{"id":991738,"date":"2025-05-12T04:18:44","date_gmt":"2025-05-12T04:18:44","guid":{"rendered":"https:\/\/mynavitechtus.com\/?p=991738"},"modified":"2025-07-25T03:32:51","modified_gmt":"2025-07-25T03:32:51","slug":"when-env-is-no-longer-env-tricks-from-the-runtime-environment","status":"publish","type":"post","link":"https:\/\/mynavitechtus.com\/ja\/when-env-is-no-longer-env-tricks-from-the-runtime-environment\/","title":{"rendered":"When ENV is no longer ENV – Tricks from the runtime environment"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Last week, my old team (all members who used to work on SDK API projects) suddenly reunited… not to reminisce about the old days, but because they were all hitting <\/span>the same “weird” dotenv bug<\/b> while deploying a new project with Laravel.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

A peculiar situation with Larave<\/b><\/h2>

Th\u00e0nh (Back-end Engineer) ran into a bug: the first request could read values via <\/span>env()<\/span>, but the second request… just failed.<\/span><\/p>

H\u00f9ng (Front-end Engineer) noticed a similar issue after deployment: his config values didn’t match what he had locally.<\/span><\/p>

After some head-scratching and debugging, it turned out both issues were <\/span>deeply related<\/span><\/i>.<\/span><\/p>

Laravel, dotenv, and the trickery called <\/b>config:cache<\/b><\/span><\/h2>

Here’s the root of the problem:<\/span><\/p>

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

    Th\u00e0nh\u2019s bug<\/b>:<\/span>
    <\/span> He called <\/span>env()<\/span> during runtime, not in the initial config \u2192 so on the second request, the value was gone.<\/span><\/p>

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

    Switching gears to AWS Lambda and NodeJS…<\/b><\/h2>

    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 <\/span>timezone bug<\/b>:<\/span><\/p>

    We expected it to print in Japan time (JST) \u2192 It printed in UTC.<\/span><\/p>

    After investigation, here’s what we found:<\/span><\/p>

    • The app used <\/span>process.env.TZ = ‘Asia\/Tokyo’<\/span> inside the code – before initializing the app.<\/span><\/li>
    • But this didn\u2019t work anymore.<\/span><\/li><\/ul>

      Turns out, this was a <\/span>trap<\/b>:<\/span><\/p>

      In NodeJS, once <\/span>new Date()<\/span> is called, the timezone is cached based on the <\/span>TZ<\/span> environment variable.<\/span><\/p>

      In Lambda, AWS might call <\/span>new Date() <\/span>before<\/span><\/i> your code runs (e.g., for logging or internal init) \u2192 meaning your late-assigned <\/span>TZ<\/span> doesn\u2019t work.<\/span><\/p>

      Fix<\/b>: Set <\/span>TZ<\/span> directly in Lambda\u2019s environment settings, not in your code.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

      \n\t\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      Key Lessons<\/b><\/h2>

      No matter what framework you use – Laravel, NodeJS, or anything else – how you handle ENV affects the <\/span>stability and predictability<\/b> of your app.<\/span><\/p>

      Golden rules:<\/b><\/p>

      • Read ENV variables <\/span>only once<\/b>, as early as possible (ideally before the app starts).<\/span><\/li>
      • Never scatter <\/span>env()<\/span> calls throughout your code. Centralize them in config files or constants.<\/span><\/li>
      • If your framework supports config caching (like Laravel with <\/span>config:cache<\/span>), <\/span>always use it in production<\/b>.<\/span><\/li>
      • Avoid using dotenv in production – even the library author says so in the README.<\/span><\/li><\/ul>

        Small things that cause big headaches: options & config<\/b><\/h2>

        A lot of bugs don’t come from the core logic itself, but rather from not fully understanding the config or simply not reading the documentation carefully enough.<\/span><\/p>

        On StackOverflow, you see tons of correct answers that are literally just adding one line of config.<\/span><\/p>

        “A friend once told me: seasoned folks really like to dive into the source code of libraries.”<\/span><\/p>

        My simple thought is that they just don’t completely trust the ReadMe anymore \ud83d\ude02<\/span><\/p>

        One last \u201cRed Flag\u201d\u2026<\/b><\/h2>

        One day, our project team found a nasty bug: AWS SDK for Greengrass IoT <\/span>automatically reset<\/b> the <\/span>NODE_TLS_REJECT_UNAUTHORIZED<\/span> variable. So even if we set it to skip TLS checks, it silently reverted.<\/span><\/p>

        Lesson<\/b>: ENV vars aren’t always immutable. Libraries can override them <\/span>behind your back<\/span><\/i>.<\/span><\/p>

        \u7d50\u8ad6<\/b><\/h2>

        If you’re working in backend, <\/span>don\u2019t underestimate your environment variables<\/b>.<\/span><\/p>

        Understand your runtime – whether it\u2019s Laravel, NodeJS, or AWS Lambda – because each one handles ENV differently.<\/span><\/p>

        ENV isn\u2019t just config. It\u2019s <\/span>a hidden power<\/b> that can shape your app\u2019s behavior in surprising ways.<\/span><\/p>

        Credit: Ton That Bach\uff08Mynavi TechTus Vietnam\u306e\u30c6\u30af\u30cb\u30ab\u30eb\u30ea\u30fc\u30c0\u30fc\uff09<\/span><\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

        \n\t\t\t\t\t
        \n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

        Last week, my old team (all members who used to work on SDK API projects) suddenly reunited… not to reminisce about the old days, but because they were all hitting the same “weird” dotenv bug while deploying a new project with Laravel. A peculiar situation with Larave Th\u00e0nh (Back-end Engineer) ran into a bug: the first request could read values via env(), but the second request… just failed. H\u00f9ng (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…<\/p>","protected":false},"author":1,"featured_media":991730,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[75],"tags":[105,102,103],"class_list":["post-991738","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blogs","tag-dotenv","tag-env","tag-laravel"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/posts\/991738","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/comments?post=991738"}],"version-history":[{"count":11,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/posts\/991738\/revisions"}],"predecessor-version":[{"id":991925,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/posts\/991738\/revisions\/991925"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/media\/991730"}],"wp:attachment":[{"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/media?parent=991738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/categories?post=991738"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mynavitechtus.com\/ja\/wp-json\/wp\/v2\/tags?post=991738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}