You know that feeling when you're carrying a tray of drinks through a crowded room and you're trying to look calm while internally screaming? That's basically what migrating a production monitoring platform to a new server feels like.
But we did it. WebMon is now running on a brand new VPS, and I'm happy to report that the number of things we broke in the process was... surprisingly manageable.
Why Move At All?
Our previous server was perfectly adequate in the way that a 15-year-old car is perfectly adequate — it gets you there, but you spend a lot of time making excuses. Here's what pushed us over the edge:
Browser Rendering Mode
This was the big one. WebMon's browser rendering feature uses headless Chrome to load pages exactly like a real browser would. It's brilliant for monitoring sites behind WAF protection, JavaScript-heavy SPAs, and those delightful pages that return a blank screen to anything that isn't a "real" browser.
The problem? Our old server couldn't run Chromium. It's like trying to run Crysis on a calculator. The new VPS has dedicated resources and Chromium installed and ready to go. Browser mode is now fully operational, which means we can finally bypass Cloudflare challenges, follow JavaScript redirects, and generally behave like a polite but persistent visitor who refuses to leave.
Faster Load Times
I'll spare you the benchmarks (nobody reads those anyway), but the short version is: everything is faster. Pages load quicker, monitoring checks process faster, and the dashboard feels snappier. The kind of improvement where you don't consciously notice it, but you'd definitely notice if it went back.
Better Security
The new server runs AlmaLinux with a properly hardened PHP configuration. We're talking strict open_basedir restrictions, locked-down file permissions, and the kind of paranoid security setup that makes you feel both safe and slightly inconvenienced. We also took the opportunity to upgrade our security headers — WebMon now scores an A grade on security header scans, up from a B. We added Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and X-XSS-Protection headers across the board.
Room to Grow
The old server was starting to feel like a studio apartment where you've been living for three years and there are books stacked on every horizontal surface. The new VPS gives us headroom for features we've got planned — more monitoring nodes, faster check intervals, and some things I'm not ready to talk about yet because I don't want to jinx them.
What Went Wrong (Because Something Always Does)
In the interest of honesty, here's the highlight reel of our migration adventures:
Redis decided to play hard to get. Turns out, when you set a password on Redis and then cache your config before adding the password to your environment file, Redis just... stops talking to you. Like a friend who found out you forgot their birthday. A quick config:cache after adding the password sorted it out, but not before a few minutes of staring at "NOAUTH" errors and questioning my life choices.
PHP's open_basedir had opinions. Lots of them. The strict path restrictions on the new server blocked our Server Info page from reading /proc/uptime (fair enough, that's a Linux thing) and prevented our Browsershot service from checking if Chrome existed via symlinks (less fair, but technically correct — the best kind of correct). We rewrote both to gracefully handle restricted environments instead of crashing like a toddler who's been told "no."
OPcache needed a talking-to. The VPS has validate_timestamps set to zero, which is great for performance but means PHP literally ignores file changes until you restart the service. Picture deploying code, refreshing the page, seeing nothing change, and wondering if Git is gaslighting you. It's PHP-FPM. It always is.
What You Get Out of This
As a WebMon user, here's what the migration means for you:
- Browser Rendering is live — Toggle it on in the Redirect Checker, Content Checker, and Security Scanner to handle WAF-protected sites
- Faster everything — Quicker page loads, faster monitoring checks, snappier dashboard
- Better security posture — A-grade security headers protecting your session
- Website Analyzer in Tools menu — Quick access to scan any site's SSL, headers, and tech stack
- More reliability — Dedicated server resources mean no more sharing with noisy neighbours
The Website Analyzer
While we were at it, we made the Website Analyzer more accessible — it's now in the Tools dropdown menu for all logged-in users. It scans any URL and gives you a breakdown of SSL certificates, security headers, technology stack, CDN detection, and server software. It's free to use and doesn't require an account for basic scans.
We also fixed a bug where the technology stack would show your web server twice (once as "Server Software" and once in the tech stack list). If you've ever wondered why "nginx" was listed twice, wonder no more.
What's Next
With the infrastructure upgrade done, we can focus on the fun stuff. Browser rendering opens up monitoring possibilities that weren't feasible before, and the extra server capacity means we can start exploring some features that have been on the roadmap for a while.
But first, I need to go double-check that OPcache setting. Old habits die hard.
If you notice anything weird after the migration, let us know. We tested thoroughly, but there's always that one edge case hiding in the corner, waiting for its moment.