Stabilising an inherited Laravel platform nobody dared to restart
A half-finished Typo3-to-Laravel migration, a 15 GB repository and a production server nobody dared to reboot. Audit first — then backups, security fixes, Docker and ~500 tests.
Two travel websites ran on a Laravel platform inherited from a previous vendor. The rewrite from Typo3 CMS had never been finished, and the 15 GB repository held two separate Laravel projects, CMS leftovers and years of junk files — even cloning it was a challenge.
The challenge
The audit we ran in the first two weeks read like a list of business risks rather than technical ones:
- The server ran an outdated operating system and packages, with a pending restart nobody dared to trigger — no one knew if production would come back up.
- There was no reliable backup strategy: a serious incident would have meant data loss and a long recovery.
- Credentials and secrets lived inside the repository.
- Endpoints and files that should have been private were publicly reachable — including forgotten development routes and roles that could modify data.
- The repository was too heavy for sane CI/CD, and there were no automated tests at all.
What we did
We started the way we always start — with a written audit of what actually threatens the business (the same exercise we sell as a System Risk Check). Then we worked down the risk list:
- Backups first, before changing anything: automated MySQL dumps and daily EC2 snapshots on the existing setup.
- Moved secrets out of the repository into environment-based configuration.
- The overdue server upgrade: rehearsed on a cloned server, written as a step-by-step runbook, protected by a snapshot for rollback, and executed in a low-traffic window. The restart everyone feared was a non-event — because it had already happened once, on the clone.
- Closed the security gaps: public routes and files made private, forgotten development endpoints removed, data-changing permissions tightened, staging put behind a password. Nobody had exploited them — but with automated scanning everywhere, finding an open door is only a matter of time.
- Slimmed the repository: media moved to Amazon S3, runtime artifacts, cached views, dead code and unneeded packages removed — from 15 GB towards a size where CI/CD is realistic.
- Added a Docker-based local setup — any developer can launch the project with a couple of commands — plus health checks and roughly 500 unit tests on a codebase that had none, as groundwork for safe refactoring.
- Set up CloudWatch monitoring for CPU and memory. It caught load spikes; the logs showed scanner bots probing for
.envfiles and WordPress paths, each request spinning up PHP-FPM. We blocked them with rate limiting at the Nginx layer — before they reach PHP at all — and the load dropped. - Next on the plan: the instance is roughly twice as large as the workload needs, so a downgrade is scheduled once bot traffic stays low — alongside an AWS Savings Plan recommendation (~20% off for a 1-year commitment, up to ~40% for 3 years).
The outcome
The platform now has backups it never had, security doors closed before anyone walked through them, a repository a team can actually work with, and tests, Docker and runbooks that make changes boring — in the best possible sense. The scary restart, the risky upgrade, the unexplained load: all handled without a single disruption to the business.
This is what an application takeover looks like when it is done in the right order: understand the risks first, stabilise second, improve third.
More case studies
industry
Travel & hospitality
tech stack
Laravel, AWS (EC2, S3, CloudWatch), Docker, Nginx
service
Maintenance & Support
Want results like these for your application?
Start with a System Risk Check — a fixed-price technical audit of your application with a written, prioritised report. The report is yours, whatever you decide next.
We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.
The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. We also use third-party cookies that help us analyse how you use this website, store your preferences, and provide the content and advertisements that are relevant to you. These cookies will only be stored in your browser with your prior consent. You can choose to enable or disable some or all of these cookies but disabling some of them may affect your browsing experience.