Question 1

Add Custom Nginx Rules

Accepted Answer

Use Custom Nginx config for redirects, security headers, access rules, CORS, bot blocking, and reverse proxies.

Before adding a rule

FlyingHost uses Nginx, so Apache .htaccess rules do not work.

Your custom configuration is inserted inside the site's existing Nginx server block. Do not include http {} or server {} wrappers.

Only use directives valid in a server or location context. Global directives such as map, upstream, and limitreqzone are not supported here.

Add and deploy a rule

Open the site in Cockpit.
Go to Settings → Custom Nginx config.
Select Configure Nginx.
Enter the rule or use the built-in generator.
Review the configuration.
Select Test and deploy.
Test the affected URL in a private browser window.

FlyingHost runs an Nginx syntax test before reloading the service. If the test or reload fails, the previous working configuration is restored.

A successful test confirms valid syntax. You must still check that the rule behaves as expected.

Common examples

Replace the example paths and domains before deploying.

Redirect one page

location = /old-page/ {
    return 301 /new-page/;
}

Use 302 while testing. Change it to 301 only when the redirect is permanent.

Add security headers

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Check both static and dynamic pages after deployment be

Question 2

PHP Workers Explained

Accepted Answer

PHP workers process dynamic WordPress requests. This article explains when they are used, how to recognize worker exhaustion, and when a larger plan helps.

What uses a PHP worker

One PHP worker handles one PHP request until it finishes.

Common examples include:

Uncached page views
wp-admin and login requests
WooCommerce cart, checkout, and account pages
Logged-in membership or LMS pages
REST API and AJAX requests
Webhooks
WP-Cron and background jobs

Static files and pages served from Cloudflare or full-page cache normally do not use a PHP worker.

Redis can reduce database work, but the request still uses a worker.

Workers by plan

Core: 8 workers
Growth: 18 workers
Pro: 24 workers
Scale: 36 workers

More workers allow more PHP requests to run at the same time. They do not make one slow request faster.

See FlyingHost Plans and Resource Limits for the complete CPU, RAM, storage, database, cache, and bandwidth limits.

What worker exhaustion means

Worker exhaustion happens when every worker is busy. New PHP requests must wait for one to become available.

For example, eight workers can handle traffic efficiently when requests finish quickly. If each request takes several seconds, a small burst can occupy all eight.

Possible symptoms include:

Slow uncached pages while static files remain fast
Slow wp-admin, checkout, REST, or AJAX

Question 3

How Cron Jobs Work

Accepted Answer

FlyingHost uses a managed system cron instead of WordPress's traffic-triggered cron. This makes scheduled tasks more reliable and keeps cron checks out of normal page requests.

How it works

FlyingHost sets:

define('DISABLE_WP_CRON', true);

A system cron then calls wp-cron.php locally every five minutes.

Each run includes a random delay of up to 239 seconds to spread server load. A task therefore runs during the next cron window, not necessarily at an exact minute.

The cron request:

Runs as the non-root wordpress user
Runs locally inside the site's container
Has a 120-second timeout
Uses a PHP worker while it is running

Do not remove DISABLEWPCRON or add another external cron trigger. Duplicate triggers can increase PHP and database load.

What uses WordPress cron

Typical tasks include:

Scheduled posts
Plugin update checks
Backups and security scans
Email queues
Cache cleanup or preload
WooCommerce background processing
Membership renewals and reminders
Plugin-created scheduled events

View scheduled events

Open Web Terminal in Cockpit. It starts in:

/var/www/public

List scheduled events:

wp cron event list

Show the most useful fields:

wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence

Run all currently due events:

wp cron event run --due-now

Run one specific event:

wp cron event run your_hook_name

Only run a specific hook w

Question 4

How FlyingHost’s Server Stack Works

Accepted Answer

FlyingHost runs each WordPress site in its own managed container. This article explains what each part of the stack does and what that means when configuring or troubleshooting your site.

How a request is handled

A dynamic request normally follows this path:

Visitor → Cloudflare → Nginx → PHP/WordPress → Redis or MariaDB

Cached pages and static files may be returned before PHP or WordPress is started.

Nginx

Nginx is the web server. It:

Serves images, CSS, JavaScript, fonts, and other static files
Routes WordPress permalinks
Passes PHP requests to PHP-FPM
Applies redirects, headers, and custom Nginx rules

FlyingHost does not use Apache or LiteSpeed. This means .htaccess rules do not work.

Add server-level rules from Cockpit → your site → Settings → Custom Nginx config.

PHP and PHP-FPM

PHP-FPM runs WordPress, themes, and plugins. FlyingHost supports PHP 8.3, 8.4, and 8.5; you can select the active version in Cockpit.

The managed PHP configuration includes:

512 MB PHP memory limit
120-second execution limit
100 MB upload and POST limits
OPcache enabled

Each active PHP request uses one PHP worker. Your plan controls how many requests can run at the same time.

MariaDB

MariaDB stores permanent WordPress data such as posts, users, settings, orders, and plugin tables.

FlyingHost uses MariaDB 11.8. WordPress connects to it locally inside the site's container, and the database is not exposed publicly.

Use phpMyAdmin in Cockpit f

Question 5

FlyingHost Plans and Resource Limits

Accepted Answer

FlyingHost plans are billed monthly per site. Each plan sets the CPU, memory, storage, PHP, database, and cache resources available to that site.

Core — $29 per site/month

2 vCPU
4 GB RAM
10 GB storage
8 PHP workers
512 MiB MariaDB buffer pool
128 MiB Redis memory
256 MiB OPcache memory

Growth — $49 per site/month

4 vCPU
6 GB RAM
30 GB storage
18 PHP workers
1 GB MariaDB buffer pool
256 MiB Redis memory
256 MiB OPcache memory

Pro — $99 per site/month

8 vCPU
12 GB RAM
75 GB storage
24 PHP workers
2 GB MariaDB buffer pool
512 MiB Redis memory
384 MiB OPcache memory

Scale — $199 per site/month

12 vCPU
20 GB RAM
150 GB storage
36 PHP workers
4 GB MariaDB buffer pool
1 GB Redis memory
512 MiB OPcache memory

Bandwidth

Every plan includes 100 GB of bandwidth per month.

Additional bandwidth costs $5 per 100 GB.

What these limits mean

vCPU: Processing capacity available to the site.
RAM: Memory shared by WordPress, PHP, MariaDB, Redis, and other site services.
Storage: Disk space available to the site.
PHP workers: Maximum concurrent dynamic PHP requests.
MariaDB buffer pool: Memory used to cache frequently accessed database data and indexes.
Redis memory: Memory available for WordPress object caching.
OPcache memory: Memory used to store compiled PHP code.

When choosing a plan, consider PHP concurrency, CPU and memory usage, and storage together. M

Frequently Read Articles

Browse All Categories

No categories configured.