The answers, before you have to ask.

OpenCart 3.x. Nitro is built against OpenCart 3's file layout, controller naming and template engine, so it does not load on 2.x or 4.x — those are different enough that it would be a different extension, not a compatibility flag.

OpenCart 4: if there is enough demand, a version built for 4.x may follow. If you run 4.x and want it, tell us — that demand is what decides whether it gets built.

OpenCart 2.x and 1.5: not supported, and not planned. We would only look at an individual case in exceptional circumstances, by arrangement.

The newest one your host offers that your store and its other extensions are happy on. Moving up a PHP major version usually buys more than any single extension can, and Nitro is faster on a modern PHP too. Nitro's Diagnostics tab shows the version you are running and tells you when moving up is worth it. Enabling OPcache matters at least as much — Nitro prints a ready-made PHP settings block, OPcache included, to paste into your host's PHP configuration.

No ionCube, and nothing to compile or install. Nitro uses what an ordinary PHP already has: GD for images, zlib for gzip, cURL for the cache warmer, and fastcgi_finish_request for background refreshes where it exists. Each of those is checked on the Diagnostics tab and each is optional — the WebP option simply does nothing without GD's WebP support, and background refresh falls back to the cron warmer without fastcgi_finish_request.

Yes. Set Client IP Source to Cloudflare (CF-Connecting-IP), or True-Client-IP on Enterprise, so the firewall log and the failed-login lockout key on the real visitor rather than on Cloudflare's edge — the wrong choice there can lock out everybody at once. If TLS terminates at the proxy, turn on Trust Forwarded HTTPS so cached pages and Nitro's own cookies use the right scheme. There is nothing to whitelist and nothing to purge at the edge: Nitro sends cached HTML as Cache-Control: private, max-age=0, must-revalidate with an ETag, so Cloudflare will not hold your pages — the page caching happens on your own server, before OpenCart boots.

Yes, and a fair amount of the code exists because of it. The cron lock is kept inside the store's own storage directory, because shared hosts often put the system temp directory outside open_basedir and a lock nobody can open would kill every run. The Cron tab detects the right PHP CLI binary from the Plesk, cPanel, CloudLinux and Webuzo layouts rather than assuming /usr/bin/php. The warmer pauses while the server's load average is high so it does not compete with real visitors — raise its ceiling if the load on your box never drops far enough for warming to start.

Nitro caches and rewrites the HTML your theme produces; it never edits your theme's own files. It does write generated files beside them — a minified .nitro.css next to each stylesheet, and a nitro/ directory per theme for bundles — all of which uninstalling removes. The rewrites that can genuinely upset a theme (bundling JavaScript, deferring scripts, content-visibility, moving Journal3's CSS out of the page) are off in the Recommended profile, and CSS and JS bundling are separate switches so a theme that trips on one can keep the other. If something looks wrong after you turn one on, turn that one off — nothing else changes with it.

Yes. Nitro's one line in the storefront index.php has to run before OpenCart boots, and on a VQMod store the usual anchors in that file are renamed and the startup require is wrapped — so Nitro looks for VQMod's own bootstrap and inserts itself above that instead. If your index.php has been customised past recognition, Nitro refuses to guess: it reports that it could not write the hook and gives you the exact line to paste in yourself.