Start with the network path
Before installing WordPress, decide where traffic enters and which component terminates TLS. On OCI, a public security-list rule is only one layer: the instance operating system can still reject the connection. Test port 80 and 443 from outside the VM as well as locally. We found this distinction mattered when the Oracle image’s persistent firewall rule blocked web traffic even though Nginx was healthy.
- Confirm the DNS record points at the intended host
- Check OCI ingress rules and the host firewall separately
- Verify both HTTP reachability and the final HTTPS response
Make the server reproducible
Write the operating-system setup as configuration, not as a list of remembered shell commands. Our Ansible role installs Nginx, MariaDB, PHP-FPM, WordPress extensions and Certbot, and keeps required services enabled. Secrets live in protected local or runtime configuration, not in the theme repository. A rerun should reconcile the system without rebuilding it.
Separate the layers of change
A WordPress theme deploy should not accidentally change the VCN, database account or TLS setup. Keeping Terraform, server automation and website code in separate repositories makes reviews more focused. It also means the website can be updated without granting the theme build access to infrastructure state.
Verify what a visitor receives
After a change, check the public homepage and contact path, then inspect important assets such as images, CSS and the favicon. A PHP syntax check does not tell you whether Cloudflare, WordPress rewrites or a stale asset path changes the result. The public URL is the final test.
Keep the handover useful
Record the architecture, deploy path, backup and recovery assumptions, and the exact checks that show the site is healthy. Avoid copying credentials into that documentation. The goal is a host the next engineer can understand and repair, not just a server that works today.
See the KubeInfra implementation