Published: June 16, 2025 by PerfGrid
Pulse Week 25
The past month or so, we've made a bunch of changes to our services, and we'll go over them in this post.
General Grid Hosting Fixes and Improvements
We've implemented smaller fixes and improvements on our Grid Hosting platform. A few of these enhance quality of life, while others address general bugs or minor issues.
Correcting Valkey Stats
One of the minor fixes involved displaying the latest metric in Valkey stats, or in certain cases, calculating the proper average over the 12-hour period we show metrics for. This was especially apparent when first starting to use the Valkey feature.
Fixing Cron Jobs
We offer composer and wp-cli (wp) in Grid Hosting when you're using SSH. However, these binaries are stored within /usr/local/bin, which meant they weren't directly available without the full path when using cron jobs. We've since resolved this by ensuring the PATH variable is set correctly for cron jobs and have pushed this change to all cron job files that rely on anything located within /usr/local/bin.
Fixing System FTP Accounts During Provisioning
We had a bug in the system that resulted in System FTP Accounts not being provisioned correctly when created through our provisioning API. This meant the standard user for the panel would not have FTP access. This has now been resolved. We're also working on enabling FTP access for these system accounts for all existing accounts that currently don't have it enabled.
New Feature: Email Allow/Blocklist
We received a request from a customer to implement allow/blocklists for email accounts into Grid Hosting solutions.
Effectively, when emails pass through our Rspamd spam filter, they receive a score. Depending on this score, multiple actions can be taken, such as accepting the email, marking it as spam and sending it to the spam folder, greylisting, or outright rejecting emails.
While we generally have low false positives, there are cases where you want to absolutely ensure emails are either always accepted or always blocked. So, we implemented this into the panel.
Per-recipient allow/blocklists aren't actually something that Rspamd offers out of the box, so we needed to come up with a solution that works well for many email accounts while also being flexible enough.
Our implementation involved custom Lua code in Rspamd, where we register the recipient(s). We then query our API to gather allow/blocklist information and store this in a temporary cache on each of our inbound filter servers.
In Rspamd, we can then make these decisions by checking the sender (both MIME and SMTP) and applying the action based on the user's preference.
The interface allows you to allow or block individual senders, such as user@example.com, or entire domains, such as example.com.
When we receive an email on the spam filter servers, we assign a priority. If two rules match (e.g., block example.com but allow allow@example.com), then because allow@example.com is more specific, it takes priority over the example.com rule.
New Feature: Valkey Data Persistence
We've implemented a smaller feature into our Valkey Manager: you can now decide whether you want to persist data on an interval or not.
Generally, we see most people use Valkey as a caching mechanism for WordPress, so persisting the cache to disk usually doesn't make much sense since it's considered transient data and losing it causes no harm. Therefore, we also don't persist data by default. However, if you're using Valkey to store data that needs to persist, you can now control this flag directly from within the panel.
This feature was also implemented to make a small performance improvement by not persisting data by default.
Temporary Domains Have Been Improved
Our prior temporary domain implementation relied on rewriting data on the fly. While this made it easy to use, it also caused interesting issues when used in combination with WordPress.
For example, if you were to save certain settings in WordPress, we would inadvertently rewrite the database entries to contain the temporary domain, which could cause strange side effects for websites using these temporary domains.
As such, we decided to change how the system works. Instead, when you activate a temporary domain, we add this domain as a separate virtual host within the web server, pointing to the same directory as the domain it's created for.
This allows for much better handling within WordPress as well.
We will expand on this feature in the coming weeks by adding a capability to our 1-click WordPress installer that can update the database entries between the temporary domain and the real domain, allowing for easy testing during migrations. We'll discuss this in more detail as it becomes available.
Additionally, we've now added the possibility to deactivate temporary domains, and we've extended the feature to subdomains, which wasn't possible before.
Bonding of Network Interfaces on All Servers
When we initially moved data centers back in December, we transitioned to a setup where all our servers are connected to two TOR (Top-of-Rack) switches, providing additional redundancy at the physical network level.
While the physical cables were connected during migration, it also required a software/configuration change on all servers. We completed this configuration change over the weekend (Friday → Sunday), so now all servers are connected to dual 10-gigabit links, providing a total of 20 gigabits of connectivity per server. This change affected servers NLCP01 through NLCP08, as well as NLSH04. NLSH05 and NLSH06 already had the bonding in place from their initial configuration.
During our initial server configuration on Friday, we did encounter an issue that caused approximately 18 minutes of downtime on NLCP01 due to a firewall configuration setting that was not visible in our testing environment. Once the issue was discovered, changes were implemented across our servers prior to migrating, meaning the remaining servers were migrated to the bonded setup with downtime in the 20-60 second range.
This change also allows us to update our switches independently without affecting server availability when we perform software upgrades.
