Within just two to three months, they resolved issues that previously seemed unresolvable.
Tim Johnson
CTO
Magento
infrastructure audit
Your stack meets the requirements. That tells you it will run, not that it's right. We audit how your server, cache, database and search are actually configured.
Adobe Commerce gold partner
#1 Adobe Commerce partner worldwide
Hyvä Platinum Partner
40+ projects delivered
ISO certification
9001 & 27001
Most certified Hyvä agency worldwide
200+ Adobe Commerce Certifications
Magento Association
Platinum Partner
Trusted by brands globally
Meeting the minimum requirements is the floor
Every host publishes the same list. Match it and Magento runs. It can't tell you whether a 4 GB buffer pool suits a 31 GB database, or whether you have headroom for Black Friday.
How Magento infrastructure quietly underperforms
None of these produce an error. They produce a slower store, a bigger bill, or a worse Black Friday.
- 1
A stack sized once, three years ago
Traffic doubled, the catalog tripled, the configuration never changed. Sizing is a decision with a shelf life.
- 2
Caching that looks enabled and isn't working
Varnish is running, Redis is connected, and the hit rate is 60% because the VCL is stock or the cache never warms after deploy.
- 3
Services fighting for the same memory
PHP-FPM sized for peak, a buffer pool sized for the dataset and a search heap, on a box that can't give all three what it promised.
- 4
One Redis doing three jobs
Cache, sessions and full-page cache in one instance, so a flush logs your customers out and an eviction storm takes sessions with it.
- 5
Background work that collides
Cron groups, indexers and queue consumers overlapping, so reindexing runs during your busiest European morning.
- 6
Cost with no relationship to load
Over-provisioned steady state, no autoscaling for the peaks that matter. Paying for capacity you don't use, and lacking it when you do.
What we check, layer by layer
Twelve layers, each measured against your catalog, traffic and roadmap, not a vendor's minimum.
Runtime and PHP
Version and support status, OPcache sizing and eviction rate, realpath cache, memory limits, and PHP-FPM sized against your real concurrency.
- Version support status
- OPcache size and eviction rate
- PHP-FPM process manager settings
- Memory limits per worker
Database
Version, InnoDB buffer pool against actual dataset size, log sizing, connection limits, temp table behaviour, and the slow query log's contents.
- Buffer pool vs dataset size
- Slow query log analysis
- Connection limits vs PHP workers
- Whether read replicas would help
Cache layers
Varnish version and VCL, hit rate measured rather than assumed, grace mode, purge and warming. Redis or Valkey instance separation, eviction policy and sizing.
- Varnish hit rate, measured
- VCL against Magento's reference
- Separate cache, session and FPC instances
- Purge and warm strategy
Search
OpenSearch or Elasticsearch version against your Magento version, heap sizing, shard and replica configuration, cluster health and network exposure.
- Version compatibility
- Heap sizing against node memory
- Shard and replica configuration
- Index rebuild behaviour
Web server and delivery
Nginx against Magento's own reference, worker and keepalive tuning, compression, HTTP/2 and 3, static asset handling and CDN rules.
- Nginx config vs reference
- Compression and asset handling
- HTTP/2 and HTTP/3 support
- CDN rules and origin shielding
Background processing
Cron group configuration and overlap, indexer mode and reindex duration, queue consumers, and whether anything has been failing silently for months.
- Cron group overlap
- Indexer mode and duration
- Queue consumer health
- Silent failures in the log
Storage and multi-node
Media storage strategy, shared storage performance across nodes, session storage, and whether the setup can scale horizontally or only vertically.
- Media storage strategy
- Shared storage performance
- Session storage across nodes
- Horizontal scaling readiness
Cloud, scaling and capacity
Headroom against measured peaks, autoscaling or its absence, instance right-sizing, and on Adobe Commerce Cloud, environment sizing and Fastly configuration.
- Headroom against measured peak
- Autoscaling configuration
- Instance right-sizing
- Fastly and environment sizing
Environments and deployment
Staging parity with production, the deployment pipeline, rollback capability, and whether cache warming and static content deployment are handled or hoped for.
- Staging parity with production
- Deployment pipeline and rollback
- Static content deployment
- Cache warming after deploy
Backup and recovery
What's protected, retention, whether backups sit somewhere an attacker on your server can reach, geographic redundancy, and whether a restore has ever been performed.
- Coverage and retention
- Off-server, off-region storage
- Attacker reachability
- Whether a restore was ever run
Monitoring and observability
Application performance monitoring, infrastructure metrics, log retention adequate for investigation, alert thresholds, and who is actually paged at 3 AM.
- APM and infrastructure metrics
- Log retention for investigation
- Alert thresholds
- Who gets paged, and when
Cost
Spend against utilisation, reserved capacity opportunities, and the over-provisioning that quietly funds itself.
- Spend against utilisation
- Reserved capacity opportunities
- Right-sizing per service
- Peak versus steady-state shape
Are you on a version that's still supported
Half of what we find is a stack that was current when it was built. The requirements move, and security support moves with them.
Version currency isn't a checkbox
An unsupported PHP or database means you stop receiving security fixes entirely. The audit says which upgrades are urgent, and what each one requires.
Valkey, the Linux Foundation fork of Redis, is now recommended for new setups. Existing Redis installations keep working, and we'll tell you if moving is worth it.
The failures are usually in the joins
Every service can be individually correct and the stack still slow. Magento's performance lives in how the layers interact, which is what a checklist misses.
- Magento → Varnish
Cache invalidation across layers
When Magento purges and Varnish misses it, stale prices stay live.
- Sessions → Cache
Sessions and cache share Redis
Fine until an eviction storm logs customers out mid-checkout.
- Indexers → Traffic
Reindexing during peak hours
Reindexing during your peak is a setting, not a fact of life.
- Deploy → Warm-up
Deploy versus cache warm
A deploy that empties every cache serves cold pages to real traffic.
- PHP-FPM → Database
Workers against connections
More PHP workers than database connections means peak errors.
- Autoscale → Cache
Autoscaling against warm cache
New nodes that arrive cold under peak load make a surge worse.
Sized for you, not for a template
The audit's core question is fit. Three answers, and we'll tell you which one you are.
Paying for capacity that never gets used
Quiet, and usually worth more in savings than the audit costs.
Fine at steady state, one campaign from a bad day
Load behaviour tells us before Black Friday does.
Enough total resource, distributed wrongly
Memory where you need IO, or vertical scaling on a stack that can't scale out.
AI reads the configuration. Engineers decide what it means
Hundreds of settings across a dozen services is machine work. Judging what a change is worth against the risk of making it isn't.
What AI does
Reads every configuration file
Not the four someone remembered, across a dozen services.
Compares hundreds of settings
Against reference values and your workload, not a template.
Parses logs and metric history at volume
Slow query logs and months of metrics, rather than a sample.
Flags infrastructure drift
Where your infrastructure-as-code and the servers disagree.
What only an engineer does
Tells a mistake from a trade-off
Non-standard is often deliberate. Someone has to know which.
Judges what a change is worth
Against the risk of making it, and the outage window it needs.
Finds the finding that unlocks the others
Rather than handing you ten that don't matter.
Signs the report
AI reads and compares. Engineers own the verdict.
- 1
Tooling
Collection
Read-only exports and history pulled from every service in the stack
- Configuration exports
- Metrics
- Logs
- Slow query log
- Traffic profile
- Cost data
- 2
AI
Analysis
Every setting compared to Magento's reference, your workload and traffic
Correlation
Configuration cross-checked with hit rates, query times, memory pressure
- 3
Engineer
Verification
Is this actually limiting you, and what would changing it be worth
Evidence gate
No finding without a captured configuration export or metric behind it
Your configuration and data stay inside our ISO 27001 practice
and are never used to train a model.
What you receive
Findings separated into performance, resilience and cost, each with the number behind it.
A walkthrough with the engineer who ran it
Not an account manager reading notes.
A diagram of what you're actually running
Which many merchants have never seen, because nobody drew it.
Findings ranked by impact, not tidiness
What limits performance, what's a risk, what costs, what can wait.
Configuration recommendations with values
The number, calculated against your dataset, with the reasoning.
A capacity verdict
Whether you survive your peak as configured, and what changes.
Cost findings
Right-sizing, because these audits frequently pay for themselves.
A prioritised roadmap
Sequenced by dependency and risk, with outage risks flagged.
What wasn't validated
Recorded explicitly, so no area is presented as healthy by omission.
Your host says everything's fine. They're describing uptime
Hosting providers check whether the server is up, not whether Magento uses what you pay for.
What we need
Everything is read-only. No changes are made to your live environment.
Access revoked when the audit ends- Restricted access, scoped and recorded
- Handled inside our ISO 27001 practice
Hosting consoleAccessUserPermission
Magebit infrastructure auditRead-only
Your teamAdmin
0 changes made to your environmentOnly configuration reads, metric queries and log reviews.
SSH, read-only
Configuration inspection, service versions, resource usage
Hosting or cloud console
Topology, instance sizing, scaling and cost data
Magento admin
Cache, indexer and cron configuration
Monitoring and APM
Traffic profile, response times, historical behaviour, where available
Database
Slow query log, dataset size, connection behaviour
Infrastructure-as-code
Drift between declared and running configuration, if you have one
When to run one
You don't need to know what's wrong with the stack. You need a reason to want it measured.
- Peak season is coming and last year hurt
- The store is slow and the bill says it shouldn't be
- You're moving to new hosting or Commerce Cloud
- Traffic or catalog has outgrown the stack
- You inherited a stack nobody can explain
- Nobody knows what happens if the database is lost
Then we fix it, and we can run it
We build and operate AWS and Adobe Commerce Cloud infrastructure for production Magento stores, so "is it the code or the server" stops being a debate between two suppliers.
Remediation, priced from real findings
Scoped after the report, with the approved estimate as the final price.
Priced from the report, not a guess
The approved estimate is the final price
Sequenced by outage risk first
Or we take the infrastructure on
Hosting, monitoring and capacity management run by the team that also knows the codebase.
24/7 monitoring and emergency response
Capacity managed against your roadmap
One team for the application and the stack
What an infrastructure audit should give you, and rarely does
Your host will tell you the servers are healthy. That is a different question from whether the stack fits the store.
What you get
Magebit audit
Typical agency
Automated tool
Configuration checked against Adobe guidance
Varies
Capacity modelled on your real traffic
Cost mapped against utilisation
Backups verified by restore, not by existing
Sometimes
Peak-season verdict with headroom stated
Varies
Vendor-neutral, no hosting to sell you
Read-only, no changes to production
What partners say about us
Magebit did a great job with the new SBS platform, now used widely across the automotive industry. I can definitely recommend them for complex digital commerce projects, their strategic approach helps us massively save on operational costs.
Kevin Hughes
European Technical Director
There is no challenge for which they can't find a solution.
Will Aubuchon
CEO
What I value most is consistency. Magebit knows our store inside out, responds fast, and keeps it running smoothly year after year.
Marian Gaidoš
CEO
Why ambitious brands choose Magebit
#1 Adobe Commerce partner worldwide
The top-ranked Adobe Commerce agency on the planet by Adobe themselves.
55+ Hyvä Certificates
The most certified Hyvä agency in the world. Confirmed by Hyvä themselves, twice.
Award-winning solutions
Innovator, World Traveler, and eCommerce Excellence awards across Meet Magento NYC and HIVE London, and more.
Hyvä Platinum Partner
The most-certified Hyvä agency worldwide and the first Hyvä Platinum Partner in the USA. 55+ certified developers and 40+ projects delivered.
ISO certified
ISO 9001 & 27001 for quality and security.
Scrum Alliance certified team
Truly agile team that moves and adapts faster than your typical agency.
Baymard and CXL certified design team
UX grounded in large-scale ecommerce research.
Magebit team at Meet Magento, #1 Adobe Commerce agency worldwide.
The world’s leading Magento agency
By certified developers, Magebit holds the number-one spot among Adobe Commerce agencies worldwide, and we’re the most certified Hyvä agency on the planet. Proof that the depth is real, not a logo on a page.
#1 Adobe agency worldwide
200+ Adobe certifications
#1 Most certified Hyvä agency
Adobe Subject Matter Expert
Learn more
Nobody drew the diagram after the third change
Most stores we look at are running a stack that was correct the day it was built, and has been quietly wrong since the catalog doubled. Tell me what you're running and we'll tell you what it should be, with the numbers behind it.
Reviewed by Kristaps Rjabovs
Co-founder of Magebit, Forbes 30 Under 30
Frequently asked questions
If you can't find the answer you're looking for, feel free to reach out to us. We're here to help.
They overlap at the edges, deliberately. The security audit asks whether the estate is exposed or already compromised. This one asks whether it's configured well: sized correctly, caching properly, scaling when it needs to, and costing what it should. Access control and patch currency appear in both, from different angles. If you're doing both, we sequence them so nothing is checked twice.
Yes, most audits we run are on someone else's hosting. The findings go to you regardless of who ends up implementing them, and we'll say plainly when your provider is doing a good job.
No. Plenty of audits end with a configuration change list for the current provider. Where a move is genuinely the answer, you'll get the reasoning and the numbers, and the findings are yours to take to any provider.
Where peak capacity is the question, yes. It's the only honest way to answer it, because steady-state metrics don't predict Black Friday.
None. Every check is a read-only configuration read, metric query or log review. Remediation only happens if you commission it separately.
Scoped on the first call against your topology, environments and hosting model, then quoted as a fixed price under our Fixed Cost Estimate Guarantee. Cost findings alone often exceed the price of the audit.
Find out what you're actually running
Your stack, your traffic, your bill. You'll get a diagram, findings ranked by impact, configuration values with reasoning, and a verdict on whether it carries your next peak.
- 1
A certified engineer replies
Not a sales script.
- 2
Findings ranked by impact
Performance, resilience and cost, separated.
- 3
No obligation
The findings are yours to keep.