The .env check

Your .env file is where most launch-day failures actually live — not because the values are hard to get right, but because a wrong one gives no error, just a feature that quietly does nothing. SixPreflight reads every place your code actually asks for a setting and tells you exactly which ones are missing, wrong, or about to stop working.

Why it does not compare against .env.example

That file drifts on every real project — it carries keys removed two versions ago and misses ones added since, so "missing from the example" and "missing from what actually runs" end up being two different lists. Instead, SixPreflight reads every place in 6amMart's own code that asks for an environment value, at the moment you run the scan — which is the only list that cannot be out of date. On the current codebase that is over a thousand files, scanned in well under a second.

Four kinds of problem, not just one

Only one of these four is "a key is missing" — the other three are quieter and easier to miss by reading the file yourself.

• Absent, empty or malformed — an APP_KEY that is not a real key, an APP_URL with a trailing slash, an invalid timezone
• Duplicated — a key written twice is not an error, the last one wins, so editing the first one changes nothing and the file still looks correct
• Encoding — a stray character at the start of the file makes the first key unreadable, and Windows line endings leave an invisible character on every value that can silently fail a database or SMTP password
• Still the shipped placeholder — not the same as empty; the code sees something that looks configured, so nothing warns you, and the integration quietly behaves as though it were pointed at a test account

Credentials that are still the shipped placeholder are flagged harder than other placeholder values, because a shipped credential is effectively a public one — anyone who bought the same script has the same key.

Two problems nothing else surfaces

Keys that break the moment you cache the config. Calling for an environment value outside a config file returns nothing once you run the config-cache command — and caching the config is the first thing every deployment guide, this one included, tells you to do. A handful of keys in 6amMart are read that way with no fallback. The one that matters most is the key that tells the mobile apps how to reach the websocket server for live tracking — once the config is cached, the apps receive nothing back, and live tracking stops with no error on either side. SixPreflight names every affected key along with the exact file and line to fix it.

The distinction it makes is per call site, not per key. A key can be read correctly in one place and still be read the broken way somewhere else in the same codebase — most of 6amMart's own payment keys are fine precisely because they fall back to a value stored by the admin panel, so they are not flagged.

Keys that nothing reads. Mostly harmless clutter, except when it is a typo — a misspelled key sits in the file looking correct while the one actually being read is the one that is missing. Anything within a short edit distance of a key that is genuinely read gets flagged as a probable typo and linked to the missing key it was probably meant to be.

Where to go next

• The server and configuration guide — where every one of these keys should point
• The "What to fix" page — where every finding from this check lands with the exact line to change