Tour website
The website of a US tour company, where travellers browse tours, dates and availability. It runs on WordPress on AWS. We took it over from the previous developer in 2026 and have run the theme, the servers and the databases since.
- Industry
- Tourism
- Client
- A US tour company, not named
- Our role
- Took over the site and its AWS setup in 2026 and have run it since
- Runs on
- WordPress on AWS
Live, and behind on its upkeep.
The site is where travellers find the company's tours, and when it reached us it worked. Nobody was looking after what it ran on. Every week or two the staging server reset itself and lost its recent work. The databases were on a MySQL version old enough that AWS charged extra to keep supporting it. Staging ran an operating system and a PHP version past their support dates. Everyone who touched the servers shared the same SSH keys, no backups ran on a schedule and nothing was watching the disk.
The client needed someone to own all of it: keep the site up, bring the servers up to date without taking it down, and keep building the pages travellers use.
off the monthly AWS bill, by upgrading the databases
staging resets since the fix, after one every week or two
to cut staging over to a new operating system and PHP 8.3
What we fixed and added.
Databases, upgraded and cheaper
Staging and production moved from MySQL 8.0 to 8.4, each with a snapshot taken first to roll back to. The old version carried an extended support charge that had grown to almost half of the monthly AWS bill. The upgrade removed it and cut the bill by 44%.
Staging, rebuilt on a current stack
Staging went from Ubuntu 20.04 and PHP 7.4 to Ubuntu 22.04 and PHP 8.3. We built a new server image and swapped it in through the auto scaling group. The cutover took under a minute, and every step had a way back. Staging now has no SSH access at all and accepts traffic only from its load balancer.
Access, backups and updates
Server access moved from shared SSH keys to AWS Systems Manager, so nobody holds a key that can leak. Both servers get an automatic snapshot every day, and we take one more before every change. WordPress and its plugins are kept current, tested on staging before production.
Tour dates and availability, redesigned
We redesigned the block that shows each tour's dates and availability. Tour data is moving from a legacy feed to a new booking system, so the block reads both. It was released to a small set of users first, so a problem would show before every visitor saw it.
What broke, and what we changed.
The disk filled up and tour dates disappeared.
A full disk stopped tour dates from showing on the site. We restored the data the same day, then fixed the causes: a debug log that had been left on, and 12 GB of old data copies, now kept under 500 MB. The tour data sync swaps in a complete, checked file or changes nothing, and an alarm watches the disk. Usage has stayed around 55% since.
Staging kept wiping itself.
Every week or two, staging lost its recent work. Nobody was doing it. An auto scaling policy kept replacing the server with one built from a 2023 image. We removed the policy, built a fresh image from the current server and added an alarm that fires if staging ever launches a new server unexpectedly. It has not reset since.
A critical PHP vulnerability on production.
A critical remote code execution flaw in PHP was published, the kind that lets a stranger run their own code on your server. We took a snapshot of production, backed up its configuration and patched it within hours of the fix being released. Staging was locked down the same night.
What it runs on
WordPress with a custom PHP theme on nginx and PHP-FPM 8.3, on Ubuntu 22.04. On AWS: EC2 in auto scaling groups behind a load balancer, RDS MySQL 8.4, S3, SES for email, CloudWatch and SNS for alarms, Data Lifecycle Manager for daily snapshots, and Systems Manager for access. Cloudflare in front. Tour data comes from a legacy XML feed, with its replacement already running on staging.
Taken over in 2026. Still ours to run.