Stores are hosted on Google Cloud Compute and managed by Kubernetes.
Currently available datacenters are in the US (Iowa), EU (Netherlands) and Asia (Singapore). More are available on request.
Data is stored on SSD storage.
Dedicated PHP 7.4 FPM workers with OPcache enabled.
Load balancer, which guarantees that the store does not go offline, or in the worst-case scenario, visitors see Scheduled Maintenance message.
WooCommerce optimized database based on MariaDB with automatic adjustment of query search cache and InnoDB pools parameters, among others. More than 32 total parameters are automatically deducted based on load.
Full-page caching where data is stored in RAM instead of SSD storage.
The frontend is served by HTTP2 Nginx web server.
Automatic smushing of source images using pngquant or Jpegoptim. It is done outside of PHP workers during a time when the store is not under load.
Web Application Firewall (WAF) that blocks common attack vectors, like SQL injections, plugin injections, etc.
WooCommerce product metadata is stored in Redis for faster access.
SSL provided by Let's Encrypt for all stores.
CDN and Image Optimization
CDN runs on Bunny.net.
The image is served based on the user agent and the visitor's device.
Servers use Google's PageSpeed module by default.
The image format, compression, and resolution are done with WebP. The best fit for the user's device is chosen automatically and cached using CDN. The typical result is WebP images served from the nearest CDN datacenter.
Inserted prefetch, preload, and push headers so that the server and CDN can optimize the delivery of the font, JS, and CSS assets.
Domain sharding to optimize the delivery of the assets in case of a saturated network connection. For example, when PageSpeed determines that the image would be faster served from the main domain and not CDN.
Optional automatic critical CSS optimization.
CDN is configured to run in pull mode, so there is no need to purge CDN asset change.
The staging environment is a replica of a production environment, including resources.
Syncing is done by partially fetching the data from the production database and applying it to the staging database, where we take all tables and metadata that are associated with WooCommerce. The benefit is that even if something breaks on staging, the production is never affected.
Publishing of the staging environment essentially replaces the production environment. The advantage is that you can revert back with one click to the exact version of the previous production environment (database and files).
Troubleshooting and Monitoring
Error Logs are parsed, and useful data is extracted (context, variables, function names, source code) so that you can easily reproduce the issue locally. Similar errors are grouped for simpler review.
Search and inspect Traffic Logs in real-time with standard information (response time, user agent, IP address, request ID). Use request ID from the Traffic Logs to correlate with errors. The request ID is shown to the visitor when the error happens.
Easily track memory, CPU, and storage usage correlated to plugin and theme upgrades and downgrades.
Integrated WP-CLI console that is isolated from the server, so even if the server is down, you can still manage WordPress.
Powered by Google Cloud DNS.
Manage all records manually but also automatically managed for Addons. For example, SendGrid SPF and DKIM records are automatically added on enable.
Daily backups are done automatically and are downloadable.
Use an automatic or manual backup to create a staging environment with one click.
When doing destructive actions system makes automatic backups so you can always revert to the previous state. For example, when publishing staging or reverting staging.
Backups are stored in Google Cloud Storage, which is separate from Google Cloud Compute and in multiple locations.