Configurator Hosting

Configurator hosting for stores where every option is a request.

A configurator turns browsing into a conversation with the server. Nothing about that conversation can be cached, and every step of it renders an image.

Option endpoints isolatedPreviews built off the request pathFree migration
Uncached configuratorBackground image compositingMemoised pricingDaily backupsFree SSL24/7 support
Built to order

Everything a configurator asks of a host.

A normal product page is one cacheable request. A configured product is dozens, each one different.

Option changes, isolated

Every selection is a request that has to be computed. Those endpoints bypass the cache and carry their own rate limit, so one shopper exploring every combination cannot starve the storefront.

Never cachedRate-limited separately

Previews built off the critical path

Compositing a preview per option change on the request path is the slowest thing a store can do. Images are generated in a background queue and cached at the edge by option signature.

Pricing computed once per combination

Combination pricing is the same arithmetic repeated for every shopper who picks the same options, so the results are held in the object cache rather than recalculated.

The configuration travels with the cart

A configured product that loses its options between cart and checkout becomes an order nobody can fulfil. The configuration is stored against the cart item, and the cart is never cached.

Memory sized for compositing

Layering several images at print resolution is a memory spike rather than a CPU one, and it is the limit configurator stores hit first.

Operations

See what people are building.

The useful signal on a configurator store is which combinations get built and which get abandoned halfway, and that is not a page-view number.

  • Configurator completion and abandonment
  • Preview queue depth
  • One-click admin login
  • Restore any daily backup from the dashboard
Configurator endpoint
Cache bypassed
isolated
Preview queue
Drained
0 pending
Price cache
Memoised
94% hit
Nightly backup
Replicated offsite
running
Performance

The fourth option change in a row.

Nobody configures a product once. The experience is judged on the tenth interaction, by which point a slow endpoint has been slow ten times.

Queued
image compositing
Memoised
combination pricing
NVMe
storage on every plan
MagicWP150 ms
Compositing on the request path1240 ms
No price memoisation520 ms

Illustrative comparison of an option-change request with and without background compositing. Your numbers depend on layer count and image resolution.

Configuration

What we change for a configurator store

These differ from a standard WooCommerce site on the same plan, and each follows from the product not existing until somebody builds it.

SettingWhat we doWhy
Configurator endpointsUncached and isolated with their own rate limitEvery option change is a distinct request, and caching them serves one shopper another shopper's build.
Preview imagesComposited in a background queue and cached at the edge by option signatureRendering a preview per option change on the request path is the single slowest thing a store of this shape can do.
Combination pricingComputed server-side and memoised in the object cacheThe same arithmetic is repeated for every shopper who selects the same options, which makes it the most repeated query on the site.
CartNever cached, with the full configuration stored against the line itemA configured product that loses its options between cart and checkout produces an order nobody can actually fulfil.
PHP memory limitRaised specifically for the compositing workersLayering several images at print resolution is a memory spike rather than a CPU one, and it is what these stores hit before anything else.
Plans

Simple, transparent pricing.

Every plan includes free migration, daily backups, SSL and 24/7 support.

MonthlyYearly 2 months free
Starter
For personal sites, blogs, and portfolios.
$20/mo
  • 1 WordPress site
  • 10 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Support tickets
Start free trial
Pro★ Most popular
For growing businesses and busy stores.
$80/mo
  • 5 WordPress sites
  • 50 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Priority support tickets
Start free trial
Enterprise
For agencies and high-traffic platforms.
$250/mo
  • 20 WordPress sites
  • 200 GB NVMe disk
  • Free SSL
  • Daily backups
  • One-click deployment
  • Dedicated support
Start free trial
FAQ

Questions, answered.

Why can a configurator not be cached?
Because each option change produces a different page for a different shopper. Anything that appears to cache those responses is showing somebody else's build, which is worse than being slow.
How do you keep preview images fast?
By generating them off the request path. Compositing happens in a background queue and the result is cached at the edge against the option signature, so the second person to build that combination gets it instantly.
What happens if a shopper picks an unusual combination?
It composites once and is then cached like any other. The first request for a genuinely new combination is the slow one, and that is unavoidable — what matters is that it happens once rather than every time.
Can a configured product lose its options?
Not if the configuration is stored against the cart item, which is how we set it up. A configuration held only in the session is how stores end up with orders nobody can fulfil.
Why raise memory rather than CPU?
Because compositing layers at print resolution loads whole images into memory. Configurator stores hit the memory ceiling long before they hit a processing one.

Move your configurator to a host that expects the interaction.

Free migration, previews built off the request path, and pricing computed once per combination.