F5 & NGINX Application Delivery
The load balancer is the one device every request passes through, and it is usually the one nobody has touched since the person who configured it left. We run F5 BIG-IP and NGINX as a managed service — the iRules, the WAF policies, the certificates, the failover you hope never gets tested — and we migrate estates off hardware when that is the better answer.
What we actually do on an F5 estate
Four areas, and most engagements start in one of them and spread into the others within a quarter.
BIG-IP lifecycle management
Full lifecycle of appliances and virtual editions: iRules and iApps, SSL profiles and certificate rotation, health monitors that test the application rather than the port, and HA pairs whose failover has actually been exercised. Version upgrades planned around your maintenance windows instead of deferred until a CVE forces one.
Load balancing & traffic shaping
L4 and L7 balancing, SSL offload, session persistence that survives a node going away, and GSLB across datacentres or regions. Connection rate limiting and QoS where a noisy client would otherwise take the pool down — the traffic policy is where most availability is won or lost, long before the application sees a request.
WAF policy that is actually enforcing
F5 Advanced WAF and NGINX App Protect: policy configuration, custom rule tuning and bot defence against the OWASP Top 10. The real work is getting a policy out of transparent mode without breaking the application — profiling live traffic, building a defensible exception set, and moving policies into blocking one at a time.
NGINX, and migration off hardware
Production NGINX and NGINX Plus configuration, reverse proxy and TLS tuning, and zero-downtime migration from legacy BIG-IP to software or cloud-native load balancers. We also say when not to migrate: an estate leaning on iRules for real application logic is a rewrite, not a lift, and it is cheaper to know that first.
How an engagement runs
The order matters more here than on most infrastructure, because every step is in the path of live traffic.
Inventory what the config actually does
Virtual servers, pools, monitors, persistence profiles, SSL profiles and every iRule, read and written down. This step is slow and it is the one that makes the rest safe: on an estate more than a few years old, a meaningful share of the rules encode behaviour that is in no runbook and no ticket, and some of it is load-bearing for an application nobody associates with the load balancer.
Fix what is quietly broken
Health monitors that only check that a port answers, so a pool member serving errors stays in rotation. Certificates with no owner and no renewal path. HA pairs that have never failed over outside a vendor demo. Persistence that breaks the moment a node is drained. These are the findings that recur across estates, and they are usually cheap to fix once they are visible.
Put the config under version control
Declarative configuration — AS3 or equivalent — reviewed in a merge request and applied from a pipeline, so a change is a diff someone approved rather than an afternoon in the GUI. This is also what makes the estate handoverable, which matters whether or not we are the ones holding it a year from now.
Then operate, or then migrate
Either we hold it — monitoring, WAF rule review, certificate rotation, upgrades, incident response — or we move it, per virtual server, old and new running in parallel with a cutover and rollback defined for each. Migration is deliberately the last step: moving a configuration nobody has finished understanding is how a migration becomes an outage.
Tools & technologies
What turns up in this work, on the appliance and around it.
Common questions
Do you work on physical BIG-IP appliances or only virtual editions?
Both. Physical BIG-IP in a rack, VE on a hypervisor, and a cloud marketplace image are the same control plane with different failure modes around them. The hardware cases differ mainly in what happens during maintenance windows and licence moves, which is planning rather than configuration.
Can you migrate us off F5 to NGINX, or to a cloud load balancer?
Yes, and it is one of the more common reasons people call. The work is rarely the new config — it is discovering what the old one actually does. iRules accumulate behaviour nobody documented, and the migration is only safe once each rule has been traced to a real requirement or retired deliberately. We run old and new in parallel and cut over per virtual server rather than all at once.
We have a WAF but it is in transparent mode because blocking broke the app. Can you help?
That is the usual state of a WAF switched on under deadline, and getting out of it is a tuning exercise rather than a toggle. Profile real traffic, build an exception set for the false positives that matter, then move policies into blocking one at a time with a rollback path for each — instead of flipping the whole policy and waiting for the support tickets.
Is this only for companies that already own F5?
No. A good share of the work is deciding whether you need BIG-IP at all. Plenty of estates running an appliance pair would be better served by NGINX or a cloud load balancer, and plenty of teams who moved to a cloud load balancer found out too late that it does not do what their iRules did. Either way the honest answer comes before the engagement, not after.
Who holds the credentials and the config?
You do. The work lives in your accounts and your repositories, as code, documented — the same arrangement as every other engagement we run. Leaving should always be easy, which is exactly why clients stay.
Related services
Send us the iRules. We'll tell you what they're doing.
A review of your delivery tier — config, monitors, certificates, WAF posture — and an honest answer on whether to keep the estate, tune it, or move off it.
Get F5 Managed Support