A Primer on InstaWP Live: Managed Hosting Optimized for WordPress

InstaWP Live is the flagship Managed WordPress Hosting service by InstaWP. 

If you’ve heard about InstaWP Live, you’ve probably been curious about what makes our managed hosting service tick. We’ve heard you loud and clear.

In this post, we’re taking you on a journey through InstaWP Live’s intricate workings. From its cutting-edge server infrastructure to advanced caching mechanisms and robust security features, you’ll get an insider’s look at why InstaWP Live stands out in the crowded world of hosting services.

How InstaWP Live Hosts Your Site?

At InstaWP Live, we leverage the power of Linux kernel namespaces and cgroups to ensure that each site operates in a secure and high-performance environment. By isolating sites in this manner, we can guarantee that all customer code runs within these dedicated boundaries, safely encapsulated inside a chroot environment.

To further enhance security, we utilize Docker containers exclusively for executing SSH commands, providing an additional layer of protection against potential threats.

Each InstaWP Live site is assigned to a pool of primary servers, ensuring consistent performance and reliability. For optimal global reach and redundancy, secondary servers are strategically located across various geo-locations, as detailed below. 

Where do our Servers reside?

The primary locations for the servers are :

• Amsterdam, Netherlands
• Ashburn, VA
• Los Angeles, CA
• Dallas, TX

By enabling our edge caching feature, you can take advantage of our network of 27 edge data centers, significantly boosting your site’s speed and performance for users around the world.

Server Infrastructure

As of January 2024, InstaWP Live’s server specifications include state-of-the-art configurations designed to ensure optimal performance and reliability.

• Servers: NGINX
• CPU: mostly AMD EPYC Rome CPUs (64 core/128 thread), moving to AMD EPYC Milan CPUs (64 core/128 thread)
• PHP / CPU: Default of 10 PHP Workers / CPU threads. Depending on client settings and availability, it can spike/burst up to 110 total if needed.
• Network: Redundant 25Gbit network connectivity per server.
• Storage: NVMe SSDs
• Scaling: active/passive server setup on bare metal, allowing us to scale up to a hundred+ CPU cores (110 in bursts) while maintaining a real-time replica in a different region with automatic failover.  Vertical scaling instead of horizontal scaling.
• Origin data centers: 4 origin centers
• Edge / CDN: 27 global data centers serve as a CDN and edge cache for your content. 
• Intermediate Image Offloading: Photon Subsizes can dynamically generate intermedia subsizes/thumbnails, optimizing and serving images without counting against storage quotas.
• Memory: 512MB for each PHP worker/process.
• Caching: Page Cache (Batcache, Memcached), Query Cache (WordPress Persistent Object Caching, via Memcached), Edge Cache (page and static asset caching at edge), OPcache.

PHP Configuration

As of January 24, 2024, sites have the following configuration:

memory_limit:	512 MB
post_max_size:	2 GB
max_execution_time:	1200
max_input_vars:	6144
cURL version:	7.86.0 or higher
MySQL version:	MariaDB
Max upload size:	2 GB
SUHOSIN installed:	❌
ionCube installed:	❌
ImageMagick installed:	❌
Sodium installed:	✅
Default timezone is UTC:	✅
PDO_MYSQL installed:	✅
GD installed:	✅
fsockopen/cURL:	✅
SoapClient:	✅
DOMDocument:	✅
GZip:	✅
Multibyte String:	✅
Remote Post:	✅
Remote Get:	✅

PHP Modules

apcu	fileinfo	libxml	pdo_mysql	sodium	xmlwriter
bcmath	filter	mbstring	pdo_sqlite	SPL	xsl
calendar	gd	mcrypt	Phar	sqlite3	Zend OPcache
cgi-fcgi	gmagick	memcache	posix	standard	zip
Core	gmp	mysqli	Reflection	sysvsem
ctype	hash	mysqlnd	session	sysvshm
curl	iconv	openssl	shmop	timezonedb
date	imap	pcntl	SimpleXML	tokenizer
dom	intl	pcre	soap	xml
exif	json	PDO	sockets	xmlreader

Origin and Edge Servers

Origin Servers

A site’s origin serves as the definitive “source of truth” for its current settings and content.

We maintain several origin data centers worldwide where end-user WordPress environments are hosted. A site’s origin location may be set during the site creation process.

If the edge cache has already cached a response for the request, that cached response will be returned.

If the request meets specific criteria to skip the page cache (for example, a unique request or one with no-cache headers), it will be sent to the origin server. The origin server will then generate a new response. If possible, the response gets cached at the edge for future requests.

Edge Servers

Our CDN is a global network of edge cache servers, each used to store content closest to an end user. If appropriate, origin servers may serve as edge servers for sites hosted in another location.

Each edge data center has a load balancer that accepts the request and then determines whether to route the traffic to the origin data center or, if the edge cache is enabled, serve the content directly from the edge. If an uncached request is made, edge servers connect the user directly to our origin servers as needed, reducing hops.

Geo-affinity

You can select the server location while creating the site. After a site is created, it is impossible to change its origin server, but it is possible to clone it to a new origin location. A site’s origin server location may temporarily change during automatic failover.

Server Locations

City	Abbreviation
Amsterdam (Origin)	AMS (Origin)
Ashburn (Origin)	DCA (Origin)
Atlanta	ATL
Chicago	MDW
Dallas (Origin)	DFW (Origin)
Denver	DEN
Frankfurt	HHN
Hong Kong	HKG
Johannesburg	JNB
London	LHR
Los Angeles (Origin)	BUR (Origin)
Madrid	MAD
Miami	MIA
Milan	MXP
Mumbai	BOM
New Jersey	EWR
New York	JFK
Osaka	KIX
Paris	CDG
San Jose	SJC
Sao Paulo	GRU
Seattle	SEA
Singapore	SIN
Stockholm	ARN
Sydney	SYD
Tokyo	NRT
Toronto	YYZ
Vienna	VIE

PHP& WordPress Versions

Last Updated: January 30, 2025

PHP: We support PHP versions starting from 8.1. You can select the PHP version while creating the site.

WordPress: We always recommend using the latest version of WordPress, but we also keep a recent version available if you’re migrating from an older system. New releases are available within 24 hours of the announcement.

Caching

Page Cache (Batcache)

We offer page caching to all sites. Currently, this is powered by Batcache, which leverages Memcached. Batcache is symlinked as advanced-cache.php in the wp-content folder on every site, which stores and serves rendered pages.

Managing Page Cache

Batcache is enabled by default and cannot be disabled at the platform or client level.

Batcache may be purged via wp cache flush. When leveraging this command via a management interface, it is recommended to skip potential conflicts. E.g., wp –skip-plugins –skip-themes cache flush.

If Edge Cache is enabled, additional purging may be necessary.

Default Caching

If not already served by edge cache, a page that receives two origin server hits within two minutes will store a cached version. This cached version of the page is stored and served for five minutes. This is the default configuration, which can be extended site-by-site.

Common Scenarios that Prevent Caching

Some configurations and issues may disable or break Batcache and Edge Cache. If logged in as an admin, the edge cache feature will not work for you.

The following examples may prevent optimal caching or break caching altogether.

Best Practices and Plugin Compatibilities

If you’re using the “pre-cached” pages option in WP Rocket, then it might result into 429 error as it sends unusual amount of page requests in a short time. The object caching part is handled by InstaWP. So, the object caching feature would be ignored from WP Rocket.

You may consider additional plugins for better performance that support lazy loading of images, helps you remove unused CSS, adds height and width parameters and vice versa. The Perfmatters plugin is also a good option to help you improve the performance of your site.

Cookies

Specific plugins may attempt to set cookies on each page load, especially those that leverage server-side cookies. This will prevent the Batcache and Edge Cache from storing and serving the cache.

• PHPSESSID server-side cookie, AKA the “session cookie”, leverages PHP to store session IDs on the server side. Initiated via the session_start() function.
• Other set-cookie implementations that attempt to set a cookie on every request. Initiated via the setcookie() function.
• Cookies prefixed with wp_ or wordpress_
• eCommerce cart and checkout cookies

Custom Cache Headers

Plugins and custom code may attempt to modify cache response headers. The following examples, when set, will prevent caching.

• pragma: no-cache
• cache-control: no-cache
• cache-control: max-age=0

Other Functions & Snippets

The following are additional code examples that can prevent Batcache and Edge Cache from working as expected.

• batcache_cancel()
• $batcache->max_age = 0;
• $batcache[‘max_age’] = 0;
• session_start()
• nocache
• nocache_headers()
• wp_cache_flush()

On problematic sites where conflict tests aren’t optimal, one might search for some code of these codes within the site’s file system. E.g.,

ag -RQ batcache_cancel –php plugins/ themes/

Edge Cache

Last Updated: July 1, 2024

Our CDN is a global network of edge cache servers, each used to store content closest to an end user. If appropriate, origin servers may serve as an edge server for sites hosted in another location.

Each edge data center has a load balancer that accepts the request and then determines if it needs to route the traffic to the origin data center or, if the edge cache is enabled, serve the content directly from the edge. If an uncached request is made, edge servers connect the user directly to our origin servers as needed, reducing hops.

Backups

We automatically create file system and database backups for user sites.

As part of the Automatic Failover system, the platform also stores a separate shadow copy of the site, updated in sync, within another region. Suppose a primary data center pool encounters any issues. In that case, this automatically fails over to the secondary data center pool for the site, keeping the site online with the site and backup safe.

Backup Schedule

File systems and databases are backed up on separate schedules.

File System: daily at 00:00 UTC — regardless of file changes
Daily: We retain and provide the last 7 days of daily backups.
Weekly: Beyond the last 7 days, backups are reduced to 1 per week. The current platform retention period for these backups is 30 days, but you may find 60-90 day backups.
Database: hourly — as changes are detected. We retain nearly every hour going back 90 days in most cases.

On-Demand Backups

You can also generate backups for your site at any time. But this is limited to one backup as other backups are available for every hour of changes. The older ones must be deleted to create a new manual backup.

Restoring the Backups

It is possible to restore the backup on demand, which overwrites the original site for which it was backed up.

SSH and SFTP Access

The process for using the SSH and SFTP is the same. Before using the service, you need to authenticate your device with a public key. There are the following limitations-

1. Each connection is valid for 8 hours. So, after every 8 hours, you need to log in again.
2. You might see that the data is transferring through a proxy tunnel. This is normal, as we have multiple servers, IP pools, and a failover mechanism.
3. No session can use more than 1gb of RAM.
4. No session is allowed to run more than 25 processes at a time. For instance, a bash script that does something like wp command | grep something | cut -f1 | sort | uniq is 8 processes: one for your login shell, one for the bash script, one for wp (assuming it does not spawn more processes), one for grep, another for cut, another for sort, and finally one for uniq. The purpose of this is to prevent both resource denial and also inadvertently recursive code.
5. Once a session is disconnected, all of its processes are killed. This is true regardless of the method used such as nohup, etc. So, there is no support for background processes. A connection must stay active to finish running a process.
6. End user connections to a given site are limited to 10. The username, in this case, is irrelevant. Ten connections from a single username are just the same as one connection from ten usernames.

SMTP and Email Delivery

InstaWP Live sites support the php_mail() function for sites that want to send system and contact form emails. By default, this mail is routed through InstaWP Live servers.

Mail sent via these servers is routed from a local SMTP server to the InstaWP Live servers for delivery, where DKIM signing is done. InstaWP’s mail servers sign emails from the primary domain of sites hosted on the platform.

End users may install an SMTP plugin instead to route mail through an email service they choose.

Sending Limits

The limit is 200 emails per hour; anything beyond this is rejected and must be resent. This only applies to sites using our default mailer (transactional e-mails) and not those using their own SMTP.

Basic Email Delivery Troubleshooting

If emails sent from a site are not being delivered as expected, you might begin the troubleshooting process with some or all of the following:

• Ensure that all emails sent by the site, including emails sent by plugins, are sent from email addresses that match the primary domain name of the site. For example, if the primary domain name is example.com, you should ensure that all emails come from orders@example.com instead of orders@gmail.com.
• If the emails not being delivered come from a specific plugin, check the documentation for that plugin or contact the developer directly for insight. For example, WooCommerce has a guide that covers several email settings.
• Check whether the deliverability issues are restricted to only one email address or a specific email provider. Many universities have strict email filtering, for example. 
• Ensure that you have checked your spam folders. Occasionally, emails sent from a WordPress site can be mislabeled as spam. 
• Install an email logging plugin to gather more information and aid in continued troubleshooting. Some examples of logging plugins include Email Log and WP Mail Logging.
• You may also consider using an SMTP plugin to improve email deliverability, mainly if your site generates a high volume of email traffic or has consistent issues with email bouncing/being flagged as spam.

Consider Using the SMTP Plugin

• If you need more than 4 sender emails on your site.
• You get a lot of traffic and might hit more than 100/200 transactional messages an hour, which is our throttle.
• If you send transactional emails using something like AutomateWoo, they might hit more than 100/200 emails an hour.
• You need a more robust email server that allows more than 500 daily emails, monitoring, analytics, etc.
• In cases where you keep having failed emails.

Rate Limiting

If the robots from your uptime monitoring, Ahrefs, Semrush, etc., exceed the 1 request per second threshold, they will see a rate-limited message and get a 429 error. Please adjust the crawling rate when you configure these tools.

Users may also see a 429 error if the site exceeds the burst limit of 110 PHP connection/worker limit.

Plugins, external requests, poorly optimized code, and other issues can simultaneously lead to a site having too many open PHP connections. These can also cause a 429 error. Until such request is complete or times out, the 429 error will persist.

DoS Mitigations

Our advanced traffic classification, rate limiting, and edge cache are very effective against (D)DoS attacks.

Additionally, all inbound requests route through an Anycast range of IPs, connecting the visitor to the closest edge data center and limiting exposure of web server IPs.

Each edge server has an NGINX load balancer that determines if the request should route to a core data center or — if enabled — serve edge cache. This also provides a layer of traffic protection and can dynamically route traffic differently based on incoming demand.

By default, most sites can easily withstand a large influx of traffic or even a DDoS attack without our specialized rate limiting and edge cache. However, these added layers greatly enhance the platform’s ability to mitigate such attacks. InstaWP also leverages a dedicated team that actively monitors the network, addresses alerts, and ensures we’re deploying optimal resources and DDoS mitigations to prevent unnecessary resource utilization.

To get the most out of InstaWP Live, site administrators should consider using edge cache and avoid proxying via services like Cloudflare.

Frequently Asked Questions

Does data live outside of the selected data center?

We respect EU law regarding properly handling data being transferred elsewhere and may store data on US and EU servers. Due to our automated failover technology, It is not possible to restrict the data associated with your site to a single geographic location.

Why doesn’t my domain’s DNS IP reflect the designated origin server location?

DNS IP locations and edge server locations do not reflect the physical location of their origin server or the server’s IP.

All inbound requests route through an Anycast range of IPs to which clients can point their domain names. The Anycast configuration determines the closest origin or edge data center to the requester.

Can I access .htaccess?

InstaWP Live uses NGINX. So there is no .htacess file. 

Can I make changes to the NGINX configuration?

It is not possible to modify the NGINX configuration at this time.

Can I make changes to php.ini?

It is not possible to modify php.ini settings at this time.

How can I increase the allowed memory size?

The PHP settings on sites hosted on InstaWP infrastructure cannot be changed and are globally fixed for all sites. We regularly review memory utilization to determine current trends and needs to ensure the set allowed memory size best fits all ranges of sites.

In general, memory exhaustion issues on a site are caused by plugins or themes not functioning correctly, not by a lack of memory. To solve memory problems, it may be necessary to perform plugin/theme/code snippet conflict checks, analyze databases, and deploy general troubleshooting practices.

Is Brotli and GZip compression supported?

By default, we enable Brotli compression at the server level. GZIP compression is the fallback for browsers that do not support Brotli or are blocked for some reason.

Can I use ionCube Loader or ZendGuard Loader?

As of January 2024, InstaWP Live does not support or install the ionCube or ZendGuard Loader extensions.

Is Imagick available?

Imagick is not available as of January 2024.