Origin infrastructure

SiteBox WordPress Hosting is a robust platform designed to provide high-performance, secure, and predictable environments for WordPress applications. Virtualization is a big idea in online systems. Big companies like AWS, Microsoft Azure, and Google Cloud Platform have made it popular. Instead of buying all the equipment, businesses can rent just what they need. SiteBox uses this idea with Kubernetes hosted within powerful AWS EC2 computing instances. This means each WordPress site gets its own space and doesn't interfere with others.

• Every environment is effectively a Kubernetes pod, in other words it's like a separate room in a bigger space,
• Each environment has its own MySQL database, which is attached dynamically at the application layer,
• Media files are stored separately to improve their availability, but linked to the environment automatically,
• environment are spread out over many EC2 machines for best use.
• These EC2 machines are managed in a bigger group called a Kubernetes cluster.
• This cluster resides in a safe space called a VPC.
• VPC connects to Cloudflare through a secure tunnel to show content to visitors. This is the only way to connect with our network from the Internet.

This approach enables us to orchestrate websites in a more flexible manner compared to other WordPress hosting platforms:

• In the event of high traffic volumes, we have the capability to replicate your existing website and distribute traffic across different instances,
• If an unexpected surge in traffic occurs, we can dynamically relocate the application to different server instances without any downtime, seamlessly incorporating the increased traffic while maintaining optimal performance.

Philosophy

SiteBox WordPress Hosting has been designed to serve as an immutable hosting solution for WordPress-based applications. Leveraging the power of Docker containerization and Kubernetes orchestration, applications hosted on SiteBox exhibit exceptional portability. The ability to seamlessly switch between cloud service providers, data centers, servers, environments, or even local machines while maintaining the exact same state allows for unparalleled flexibility. To make this work, our team has introduced a release-based way of working. This means every set of changes is like a package that can be moved and used anywhere. This way, we make sure we meet customer needs while saving time and money. Moreover, it mitigates the negative impact often associated with WordPress deployment strategies, which can be notoriously unpredictable.

Immutability

Immutability, in the context of computing and web servers, refers to the concept where state cannot be changed after it's created. For webhosting, this has many benefits:

• Predictability and Consistency – we assume, no changes are made in the runtime to servers after they are deployed, therefore websites run the same way every time.
• Reliability and Easy Scaling – If more visitors come, just add more copies of the server. If there's a problem, go back to an older version.
• Security Immutable servers enhance security. Since changes to the running servers are not allowed, the attack surface is reduced as attackers cannot install malicious software or make changes to exploit vulnerabilities.

SiteBox's approach to managing WordPress hosting integrates the concept of immutability wherever feasible.

Environment components

Every website on SiteBox WordPress Hosting has three main components: Codebase, Media Library, and MySQL database.

Codebase

Codebase is shipped using a base container. Each deployment creates another distinct build of a base container with a code sourced from either git respository or CI service. On top of bundled codebase, base container empowers a website with an nginx server and php-fpm. The approach is designed to improve development flow by:

• Reduce a risk of accidental file override (like in sFTP file transfer),
• Reduce a risk of hiding exploits within a codebase, each code change is tracked through git,
• Improves visibility of changes applied over the time and helps to manage errors

Apart from the uploads directory, handled by a separate instance, we adhere strictly to the principle of immutability. All files are preserved in their original state throughout the entire lifetime of an instance. Necessary modifications are handled through the initiation of a new deployment, effectively creating another instance of a webserver. This approach enhances the reliability and consistency of all environments, supporting seamless operation, stability and ability to move environment across different nodes or even data centers.

Media library

The Media Library is where all the media files (like pictures and videos) are kept in WordPress instance (technically, these files are located in wp-content/uploads). Due to its dynamic nature, it's separate from the base container but linked to it during the deployment process. When a new deployment occurs, the Media Library is detached from the previous Docker container and subsequently mounted onto the new one, maintaining seamless continuity of content.

The contents of the Media Library are served through a dedicated server specifically configured to host static files. This static server does not expose the php-fpm service, ensuring that dynamic files not managed by the repository are prevented from execution.

In addition, to expedite response times and bring content closer to the visitors, all items within the Media Library are dynamically cached indefinitely at edge nodes within the Cloudflare network. This strategy promotes rapid delivery of static content, significantly enhancing the user experience globally.

Media items in the library can be managed as usually through the WordPress UI, or uploaded via a custom backup, providing flexibility of data management for administrators, editors and developers.

MySQL database

The MySQL database is the heart of the WordPress site – it stores data of all pages, posts, attachements. It resides in a separate cluster, distributed across multiple replicas on different nodes and availability zones for improved robustness and load-balancing. The MySQL instance is linked to the base container dynamically during the deployment process.

Considered as the crown jewel of the WordPress instance, the database can be accessed directly in the local environment for comprehensive control. It can also be uploaded to the hosting environment via a custom backup, offering additional flexibility for data management and recovery.

Nginx configuration

Origin uses Nginx as static content server and reverse proxy with cache layer for php code processor. Server fully cooperates with SiteBox Cache layer which allows to customize static and dynamic content caching rules. By default proxy cache can store up to 2GB of data. Proxy cache is automatically flushed when of below events occur:

• content of website has been changed (eg. user has added a new post or page),
• new release/deployment has been performed.

It can also be flushed directly from Wordpress admin panel with use of SiteBox cache plugin.

PHP configuration

To process PHP code origin is using dynamic PHP-FPM module with Opcache and Object Cache enabled. Object Cache is using two active layers:

• Small in memory cache – 32MB for most frequent objects,
• External Application Cache – for all cacheable objects. It is stored in Amazon ElastiCache service.

Both layers are flushed together when flush events occur.

Max execution time

The default max_execution_time for scripts in SiteBox is set to 60 seconds. If a task is expected to take longer than this time frame to complete, it is recommended to break it into smaller segments and execute it in batches. This approach ensures that tasks can be completed successfully within the defined time constraints, preventing script timeouts and potential disruptions to your operations. By breaking down longer tasks into manageable batches, you can optimize resource utilization and maintain the reliability of your processes.

Blocked functions

Here is a list of functions that are disabled by default on each origin server for enhanced security. These functions are disabled or restricted by default to minimize security risks and protect your origin server from potential vulnerabilities and attacks.

• exec
• shell_exec
• passthru
• system
• proc_open
• popen
• show_source
• posix_kill
• posix_mkfifo
• posix_setpgid
• posix_setsid
• posix_setuid
• posix_getpwuid
• posix_uname
• pclose
• dl
• disk_free_space
• diskfreespace
• disk_total_space
• proc_close
• proc_get_status
• proc_nice
• proc_terminate
• symlink
• link
• escapeshellarg
• escapeshellcmd
• highlight_file
• lchgrp
• lchown
• prog_get_status
• getmypid
• getmyuid
• getmygid
• getrusage
• getmyinode
• get_current_user
• libxml_disable_entity_loader
• pcntl_alarm
• pcntl_fork
• pcntl_waitpid
• pcntl_wait
• pcntl_wifexited
• pcntl_wifstopped
• pcntl_wifsignaled
• pcntl_wifcontinued
• pcntl_wexitstatus
• pcntl_wtermsig
• pcntl_wstopsig
• pcntl_signal
• pcntl_signal_dispatch
• pcntl_get_last_error
• pcntl_strerror
• pcntl_sigprocmask
• pcntl_sigwaitinfo
• pcntl_sigtimedwait
• pcntl_exec
• pcntl_getpriority
• pcntl_setpriority
• putenv
• opcache_get_configuration
• opcache_get_status