The answers, before you have to ask.

Nitro's runtime settings file — system/storage/nitro/config.json — is what the pre-framework engine reads on every request, and it is missing or out of step with what the admin has saved. Click Re-apply Settings to rewrite it. If the warning comes back, system/storage/nitro either does not exist or is not writable by PHP; the Diagnostics tab's Cache dir writable row shows the exact path it is trying. Nothing is broken meanwhile — an unreadable settings file makes every feature read as off, so the store runs as plain OpenCart rather than failing.

The page cache and the firewall run before OpenCart boots, and that needs one line in your storefront index.php. Nitro adds it automatically when you save settings; this warning means the file was not writable. Make it writable and save again, or add the line yourself immediately above // Startup:

if (is_file(DIR_SYSTEM . 'library/nitro/boot.php')) { require_once DIR_SYSTEM . 'library/nitro/boot.php'; }

The Diagnostics tab's index.php hook row is where to confirm it took — worth checking right after installing, because the install step writes the hook without reporting a failure.

The build you installed is sealed to a different hostname, so on this one every feature stays off and the store serves as stock OpenCart. You can still open and save settings; they simply will not take effect. This is what you see after moving to a new domain, or after installing a build meant for another shop. Get in touch with the hostname the store is actually served on and we will issue a build for it.

Installing the module grants access and modify on extension/module/nitro to the user group of whoever pressed Install, and to nobody else. Add both permissions to the other group under System → Users → User Groups. Without access, the admin header widget and the settings page stay hidden entirely; without modify, the page is visible but every action — saving, clearing the cache, purging a URL, exporting settings — is refused.

That is Nitro's firewall, not OpenCart. Ten failed admin logins from one IP within fifteen minutes lock that IP out of the login page for fifteen minutes with an HTTP 429, and a successful login clears the tally immediately. Wait it out, or delete your IP's lock file under system/storage/cache/nitro/admin_lock/. It only ever counts failures — it never bans an IP permanently, and it does not touch the storefront.

Turn the master switch off and save: Nitro then does nothing at all and OpenCart runs normally, which tells you in seconds whether it is the cause. To narrow it down without switching anything off, use Start Bypass — it opens the storefront with the page cache, query cache and asset rewriting all skipped, for your browsing session only, so you can compare a raw page against the optimized one. If it turns out to be an asset option, switching the profile to Safe leaves full-page caching and the riskier HTML rewrites off. Errors inside Nitro never take the store down by design — it falls through to stock OpenCart instead.

Four things. system/storage/nitro/ holds the settings file and runtime state; system/storage/cache/ holds cached pages and query results; the storefront index.php needs to be writable once, so Nitro can add its pre-framework line; and your theme's asset directories under catalog/view/theme/ need to be writable if you want minified or bundled CSS and JS, since those are written beside the originals. The Diagnostics tab checks the first three and names the exact paths it is using.

Large source images are the usual cause: OpenCart resamples straight from the full-size file, and on a big photo that can hit the PHP execution timeout and leave a half-written or missing thumbnail. Nitro's Fast Image Resize shrinks the source in one cheap step first, so the quality resample works on something small — the same result for a heavy downscale, far less work. It is on in every profile, but it is an ocmod patch, so it does nothing until you have pressed Refresh under Extensions → Modifications.