The brief
KubeInfra needed a site whose infrastructure, server configuration and theme could be maintained separately. Routine website changes should reach production through a reviewed source change, while credentials and server-specific settings stay outside the repository.
The architecture
The site runs WordPress on an Oracle Cloud Ubuntu Arm VM in Tokyo. Terraform describes the network, compute and Cloudflare DNS configuration. Ansible installs and configures Nginx, MariaDB, PHP-FPM and WordPress. Cloudflare serves the public domain with HTTPS. The WordPress theme lives in its own repository.
- Oracle Cloud VM and network defined in Terraform
- Server packages and web configuration managed with Ansible
- Theme source and infrastructure source kept in separate repositories
- Cloudflare DNS and HTTPS at the public edge
The release path
A push to the theme repository’s production branch starts GitHub Actions. The workflow checks PHP syntax, uploads a release through a protected SSH path, activates the theme and requests public pages to verify that the deployed site still responds. The runtime configuration is supplied by protected deployment settings rather than committed with the theme.
How we verify a releaseWhat we can show
The public site, its HTTPS response, the published sitemap and the versioned theme assets are visible outcomes of this build. We have not attached uptime, traffic, conversion or cost-savings figures here because this example is about the architecture and delivery method, not an invented business result.
What we learned
A deployment can succeed while a user-visible asset is still wrong. The site favicon exposed exactly that problem: the root icon URL pointed to WordPress’s default image even though the theme referenced the KubeInfra mark. Correcting the root asset, deploying it from source and checking the public response closed the gap between the repository and what search engines could fetch.