We Manage Blog

WordPress at Scale: How We Run FCBinside

2026-05-16T00:00:00+02:00

If you've ever tried to run a WordPress installation under real load, you know: most tutorials end about where it gets interesting. "Just turn on caching" is a nice start. But when 30,000 people click the same push notification within minutes because a Bundesliga player might or might not be moving to FC Bayern, that's not enough.

FCBinside.de is one of Germany's largest portals covering FC Bayern Munich. Up to 5 million monthly visitors, news, transfer rumors, player ratings, comments, an in-house app with an ad-free subscription model – all running on WordPress. We've been running the infrastructure at We Manage for a while now. In this article, I'll walk through what a WordPress high-performance hosting setup like that looks like, where the real high-load bottlenecks are, and why 24/7 support on a project like this isn't a marketing line but an operating requirement.

By the way: I also had Vjeko Keskic, the founder of ballnews media and the person behind FCBinside, on episode 89 of my podcast Happy Bootstrapping (in German) – we talked about the path from hobby blog to a multi-person team, reach, the app, and ad sales. If you're curious about the story behind the portal, it's worth a listen.

The real problem isn't the match itself

You'd think the critical moments for a football portal are match days. Those are actually quite predictable – kick-off, half-time, full-time, post-game coverage, press reactions, all in a known rhythm. The hard peaks look different: ad-hoc, no warning, concentrated into a few minutes. A Fabrizio Romano tweet, a Bild story at 1:30 in the morning, a press conference someone records, a player who limps off the pitch unexpectedly. When FCBinside is the first German portal to publish a solid news piece about it, traffic climbs within minutes.

This ad-hoc characteristic is what makes hosting different here than for classical WordPress sites. An online shop knows its Black Friday dates. An event site knows when its ticket sale starts. A news portal about FC Bayern doesn't know in the morning whether today is the day a 100-million-euro transfer leaks. The infrastructure doesn't have to be sized for a predictable peak; it has to be sized for unannounced peaks, around the clock.

On top of that: FCBinside has its own app with a subscription, where fans can read content ad-free. That app pulls content through the WordPress REST API. Technically elegant, because the same data backs web and app – but it also means every push notification from the app doesn't just produce browser traffic on the website; it produces parallel API requests from the app itself. Both paths have to hold up.

The architecture: intentionally simple, intentionally generous

FCBinside.de runs on a single, generously sized Hetzner Cloud Server. No cluster, no hot-standby read replicas, no Kubernetes playground. In front sits Cloudflare as the CDN. Analytics runs on a separate server so tracking and CMS don't get in each other's way.

This is a deliberate choice. A single strong server with plenty of headroom is often the better option in this constellation than a distributed setup that leaves 80 percent of its capacity unused under normal operation – and delivers exactly the complexity you don't want to debug at three in the morning when load hits.

App integration via the REST API means we can't apply the typical WordPress caching tricks for the website one-to-one to the API. A fully cached HTML page is served by the front-end without PHP. A REST API request doesn't strictly need to be fresh, but it has to stay authenticatable, deliver JSON, and react to updates. The cache strategy here is finer-grained – shorter TTLs, object cache for the database, targeted invalidation on new articles.

Cloudflare, cache plugins and nginx: three layers, one strategy

Cloudflare doesn't automatically solve problems. Cloudflare solves the problems you actively let it solve. Default settings are made for a generic marketing site – not for a news portal with a high update frequency. Cache rules per URL pattern, page rules for API endpoints, granular bypass for logged-in users and comment endpoints – that's configuration work you do once cleanly and then revisit regularly.

Behind Cloudflare sits a second cache layer: a WordPress cache plugin that interlocks with nginx. Which plugin fits best isn't a matter of religion – we re-evaluate new versions and alternatives regularly and look concretely at how they affect web vitals: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. A plugin that halves TTFB but tears the layout apart through wrong critical-CSS optimization is not an improvement.

Important: the cache plugin alone is not enough. It has to integrate cleanly with nginx so cached pages are served straight from the web server, without PHP ever starting up. A "cache hit" rendered by PHP is still a PHP process burning CPU.

Headroom alone isn't enough – the unspectacular details decide

The WordPress server has plenty of headroom by design. That helps against unexpected peaks – but it doesn't protect against every class of problem. A slow query that doesn't matter under normal load can block the entire MySQL pool under high load. A plugin update that produces additional AJAX requests per pageview shifts the load profile. A new ad partner with a synchronous script embed can slow down the user journey even though the server itself is in great shape.

So the setup involves more than "big server plus CDN":

OPcache cleanly configured, with enough memory and matching validation intervals so PHP code isn't recompiled on every request
Redis as the WordPress object cache so repeated database queries (options, term lookups, transients) come from RAM
MySQL tuning with adjusted buffer pool, slow-query logging, and regular fragmentation checks
nginx with FastCGI cache as an additional cache layer so cached pages go out without a PHP round-trip
Kernel and system parameters tuned for high concurrent connections, correct file-descriptor limits, a properly sized TCP stack

None of this is spectacular. But every single one of these is a potential breaking point if you overlook it.

Load tests, before it gets serious

One thing missing from most WordPress tuning articles: load tests. We test before major rebuilds, before plugin swaps, before new PHP versions, and especially when we change the cache configuration. Not \"quickly hammer 100 requests with ab,\" but realistic scenarios – a mix of cached articles, REST API calls from the app, ad-server endpoints, comment pages.

What we measure: throughput per second, response times at the 95th and 99th percentiles, PHP-FPM pool saturation under load, MySQL connections, cache hit ratio on the nginx and Cloudflare layers. And – almost more important – how the system behaves after load ends. A site that hurts under load but recovers cleanly afterwards is okay. One that keeps stumbling after the peak has a different problem (often in connection handling or cache warm-up).

Load tests also tell you whether a new caching plugin actually delivers what its marketing page promises. Spoiler: surprisingly often it does not.

Monitoring: you want to know before, not after

For FCBinside.de we run the same monitoring stack as for all our customers: Icinga2 for checks, Telegraf for metrics, Grafana for visualization, VictoriaMetrics as the time-series database, plus centralized log management. What matters here is not the tools, but the right metrics: PHP-FPM pool saturation, MySQL slow queries, Redis hit rate, Cloudflare cache hit ratio, app/API response times.

The most useful alerts aren't the "server down" ones, but the "something is shifting unusually" ones. When API latency rises by 80 percent within ten minutes, that's often the first sign of an incoming wave – before any classic threshold limit is hit.

Hands-on support: phone, Slack, short paths

For a portal like FCBinside, 24/7 availability isn't a nice extra; it's a precondition. When a transfer rumor lights up on Saturday at 11:30 pm and the app push notification sends 50,000 devices at once to the website, the question isn't whether someone will respond – it's who, and how fast.

For us, that means: small team, short paths, direct contact. No ticket system that escalates in three steps. We are reachable by phone – and just as much on Slack, in a shared channel with the customer. It works both ways: we ping when we see something unusual; the customer pings when they see something we might have missed. Short message, fast reply, no escalation tiers.

This only works because we deliberately don't try to serve hundreds of customers with the same staffing. We serve a manageable number of platforms and really know them.

What's left to say

WordPress can carry very large, very lively sites – if the infrastructure fits. That is less a question of the CMS and more a question of how seriously you take the unspectacular details: OPcache, MySQL buffer, CDN rules, plugin choice with a web-vitals lens, load tests, monitoring thresholds. And of who steps in when things catch fire.

At FCBinside.de the setup works because the architecture is deliberately simple, the components sit in the right places, and the operator knows whom to call or ping on Slack. If you want more background on this specific project: the FCBinside case study sums up the architecture, results, and key numbers in one place.

Got similar problems? Get in touch

Do you have a WordPress site that buckles under peak load — Black Friday, a sudden TV mention, a viral campaign? Outages, slow REST API calls, broken cache layers? If that sounds familiar, we might be the right partner for you.

At We Manage, we run a number of WordPress installations under serious load – news portals, community platforms, event sites – on top of our Managed Cloud Server. If you have similar requirements – high traffic spikes, app integration via the REST API, 24/7 reliability with a real contact person – reach out. We'll take a look at your setup and tell you honestly what works and what doesn't.

Successful Cloud Exit: How We Helped Everysize Leave AWS and Save 80% of Their Costs

2025-05-27T00:00:00+02:00

When Eugen Falkenstein, co-founder of sneaker search engine Everysize, approached us a few years ago, his company faced a classic problem that many growing startups encounter: exploding AWS cloud costs and diminishing flexibility. What followed was one of the most successful cloud migrations we've facilitated at We Manage – with 80% cost savings and significantly improved performance.

The Starting Point: Trapped in the AWS Cost Spiral

Everysize is the only search engine in the German web that finds sneakers at the best prices in the desired shoe size. Like many others, the seven-person team had chosen what seemed like the straightforward path: "We were with Amazon AWS from the start because that's what everyone does," recalls Eugen Falkenstein.

However, what initially seemed like a pragmatic decision increasingly became a problem. "Increasingly complicated pricing models followed. Eventually, we were paying AWS a five-figure amount per month, twice as much as in the beginning – with almost constant resource requirements," reports Falkenstein. Monthly AWS costs had risen to over €4,000, while agility simultaneously decreased due to complex dependencies.

Why Everysize Came to Us

When we first met Eugen – incidentally through a private connection, "Our wives knew each other" – it quickly became clear that more was needed than just another service provider. Falkenstein was looking for a genuine partner: "For that, you need someone who really understands your business model and contributes their own ideas to implement that on a technical infrastructure, without vendor lock-in."

His requirements were clearly defined: 24/7 service, technical competence, and the balance between professional service and partnership at eye level. "I don't see myself just as a customer, but also as a partner and colleague. I like to spontaneously throw ideas across the table. That only works with teammates who maintain the balance between service and being on equal footing."

Our Analysis: Where AWS Was Overdimensioned

When analyzing the existing infrastructure, it quickly became apparent why costs had exploded. Everysize used only a fraction of AWS functions but needed predictable backend routines for 80% of their computing capacity: product data management, feed import, BI data preparation. "Compute-intensive, but everything well calculable," as Falkenstein puts it.

For this type of workload, the hyperscaler's flexibility advantages were simply overdimensioned and disproportionately expensive.

The Migration: Developing Tailored Solutions

After a successful trial project, we gradually took over the operation and optimization of Everysize's Elasticsearch installation. The migration to Hetzner Cloud extended over eighteen months – deliberately cautious and without risk to ongoing operations.

"The migration from hyperscaler to classic hoster doesn't always go one-to-one," Falkenstein admits. This is exactly where we could apply our expertise: We developed tailored solutions for a powerful MySQL cluster on the new infrastructure and migrated complex components like the URL shortener for social media marketing.

It was important to us not just to migrate, but to optimize. We automated most IT processes to guarantee 24/7 availability and implemented proactive monitoring and alerting.

The Collaboration: DevOps Reimagined

Particularly successful was the close integration with development agency Intradesys, which is simultaneously rewriting the complete search engine code. "Thomas and I develop the prototypes, for which Andy then designs and builds the optimal IT infrastructure," describes Falkenstein's working method.

This agile, asynchronous collaboration via Slack and email made it possible to respond quickly to new requirements without getting lost in lengthy coordination processes. "Through asynchronicity, we get more focus, calm, and consideration," says Falkenstein.

The Results: More Than Just Cost Savings

The numbers speak for themselves: annual server costs dropped from €50,000 to just under €10,000 – a savings of 80%. But the qualitative improvements were at least equally important:

Higher Reliability: "In emergencies, I no longer have to activate my service providers. Today Andy proactively notifies me and has usually already solved the problem, even at night or on weekends," reports Falkenstein.

Regained Agility: "We implement new ideas within a few weeks today. We've regained our nimbleness and can fully leverage our strengths as a small digital company in the market again."

Current Projects and Future Plans

Everysize is already using their newly gained technical sovereignty for ambitious future projects. We're supporting them in modernizing their content management system and building their own marketplace for sneakers. "We might want to internationalize our business in the next step," considers Falkenstein.

All these initiatives are only possible because the IT infrastructure functions again as a strategic enabler rather than a cost factor.

What Other Companies Can Learn

The Everysize case exemplifies that a cloud exit can be more than pure cost reduction. It's about regaining technical sovereignty and entrepreneurial flexibility.

"As an online entrepreneur, we don't print a finished book. We spell out our business strategy in technology. For that, you must constantly optimize and develop your IT processes," Falkenstein summarizes the philosophy.

For us at We Manage, this project was particularly satisfying because it shows what becomes possible when technical expertise meets genuine partnership. As Falkenstein puts it: We are "the professional sysadmin I would need in-house, but who would have too little to do with me" – just externally and with the full flexibility of a partnership.

Conclusion

Our collaboration with Everysize proves that with the right analysis, tailored solutions, and genuine partnership, even complex cloud dependencies can be successfully resolved. The result is not only drastically reduced costs but, above all, the recovery of technical flexibility that is vital for innovative companies.

Concretely, we run the entire operation for Everysize — on top of our Managed Cloud Servers, with CDN integration via Cloudflare and ongoing Cloud Consulting on provider choice, migration, and architecture. You can find more details on the setup in our Everysize case study.

Interested in similar optimizations for your company? We'd be happy to discuss how we can help you achieve greater technical sovereignty and optimized costs as well.

Welcome to our new website!

2025-03-13T00:00:00+01:00

What we do for you

At "We Manage," we take the technical burden off your shoulders so you can focus on what you do best: advancing your core business. Our services include:

Managed Server & Cloud Solutions: Optimized infrastructure without the overhead
Hosting Solutions for Laravel, Symfony, PostGIS, GitLab and much more
CDN Implementation & Consulting: Lightning-fast content delivery worldwide
Proactive Monitoring: We identify issues before they lead to outages
Reliable Backup Strategies: Your data is in safe hands with us
We also help with Performance Analysis, High-Load Scenarios, and when GDPR and Sovereign Solutions are required
We're available 24/7 for you upon request

Hands-on Collaboration

What makes us special? We don't just work for you, but with you. Through Slack Shared Channels, we're practically part of your team – always accessible, always responsive. No tickets disappearing into nowhere, but direct communication and quick solutions.

Technology that works

In today's tech landscape, stability isn't a luxury, but a necessity. Our experience in the DevOps field enables us to implement customized solutions that grow when you grow.

We look forward to getting to know you and your project and shaping the next chapter of your technical infrastructure together! Feel free to reach out to us about this.

We would like to express our sincere gratitude to the team at Stella Projects, who implemented our website using the powerful Statamic CMS

Your "We Manage" Team