
Do you run nginx -t against source files or the image you actually deploy?
nginx -t does exactly what it promises. The subtle failure mode is running a valid check against something other than the artifact that reaches production.
A pipeline can test repository files with the runner's Nginx package, then deploy an image with a different build, module set, filesystem layout, generated config, user, and network. The command is the same; the thing being tested is not.
These are the parity checks I find useful:
Binary fingerprint Capture
nginx -Vfrom the deployable image, not just the CI runner. Version numbers are not enough when configure arguments and dynamic modules differ.Rendered configuration Run the test after the normal template or
envsubststep. Testing the source template proves little if the deployed file is generated later.nginx -Tis useful for confirming the final include graph, but its output should be treated as sensitive when rendered values contain credentials.Runtime identity and filesystem Use the same UID, mounts, working prefix, read-only paths, certificates, and generated directories as the deployment. A permissive runner can hide restrictions that only exist in the container or host.
Network-dependent behavior A parser check is not a request test. Resolver behavior, service discovery, upstream failures, headers, redirects, and location selection still need representative traffic in a deployment-like network.
At minimum, I want these commands to run inside the built image after its normal rendering step:
nginx -V 2>&1
nginx -t -c /etc/nginx/nginx.conf
Disclosure: I build and maintain the Nginx Configuration plugins for JetBrains IDEs. They help with directive context, includes, references, and risky patterns while editing; this deployment boundary is deliberately outside what an IDE can prove.
I wrote up the wider validation loop here:
Do you validate the built image after rendering, or is nginx -t still running against repository files earlier in CI?