For hosting providers

The same WordPress sites.
1.3 to 1.5 times the pages per second.

BookPress is software you run on your own infrastructure: a native implementation of WordPress core that serves the sites already on your platform, with the same themes, the same /wp-admin and the same URLs they use today. We sell the software, and we leave the hosting to you.

What changes on your fleet

The PHP stack leaves the request path. A tuned WordPress stack holds a PHP-FPM pool, a database server and an object cache in memory. Under full load on the same 4-vCPU server, BookPress uses 434 MB of memory and WordPress uses 748 MB. BookPress renders the site's WooCommerce and Elementor pages faster than that tuned WordPress does. A site with no plugins renders in about 0.18 ms against WordPress's 42 ms. We measured speed on Google Cloud c2-standard-4 and c4a-standard-4 machines and memory on the c2-standard-4, against WordPress running its own PHP with opcode JIT, Redis and MariaDB, on pages a cache cannot serve. Every figure and the method are on the speed and density pages.

BookPress sets its number of workers from the machine's processors and memory when the service starts. A number you set in /etc/bookpress/bookpress.conf wins. It loads plugin code once and shares it between workers, so one more worker costs about 88 MB. It compiles a site's PHP files when it starts and when a file changes, so the first visitor does not wait for that. A worker that has had no request for 30 seconds gives memory back to the system. We are measuring how many sites one machine carries.

What your customers keep

Their themes, their admin, their URLs, their content. A migrated site is the same site: the same wp_posts rows, the same permalinks, the same /wp-admin. The person who owns the site sees nothing change, which is the only version of this a support desk can survive.

What does not work yet

Most vendors leave this part out, so it goes first. Multisite is not supported. The Customizer and the Site Editor work in part: the Customizer previews by reloading the page, and the Site Editor has no template revisions and no style variations. Both need a WordPress install on disk beside BookPress. Plugins and themes install from wordpress.org in wp-admin; themes have no update flow yet. Image editing covers crop, rotate by quarter turns, flip and scale, for JPEG and PNG. Plugin support is real and partial: plugins run as PHP on our own engine, and we certify, limit or refuse each one before it can activate.

That last point is worth more than it sounds. We check every plugin on a site before it runs, and a plugin that would fail comes back named, with the file and the line it would fail on. WordPress installs anything and the site finds out at request time, on a white screen. You will know which of a customer's plugins work before you move them.

Install it

curl -fsSL https://bookpress.io/install.sh | sudo sh

The installer detects apt or dnf, asks for your customer id and access token, installs the signed package and starts the service. The manual steps per distribution are on your account's install page.

The installer asks for the address visitors use. Behind nginx, Caddy or a load balancer on the same machine, BookPress serves https links with no extra setting. If HTTPS ends on another machine, name that machine with --trusted-proxy; forwarded headers from anywhere else are ignored. For scripted installs, --site-url sets the address and --yes skips the questions.

BookPress updates itself. Releases install unattended by default, and a major version waits for your consent. After each update it checks that the site still answers and goes back to the previous version if not. Tools → Site Health shows the installed version and the last result. UPDATER=off in /etc/bookpress/updater.conf switches the updater off.

Getting sites in, and out

One command each way. Our package installs its own wp beside the server. Each command asks once before it writes anything; --yes skips the prompt in scripts.

The commands work straight after install, on a host with WP-CLI and on one without; the program behind them is bookpress-wp, and bookpress-wp import and bookpress-wp export are the short forms.

In

$ wp bookpress import --dir=<wp-root> --path=/var/lib/bookpress
BookPress import from the WordPress at <wp-root>
Import <home-url> (<n> tables, <size> uploads) into BookPress at <bookpress-root>? [Y/n] y
...
Success: Import complete. The source WordPress at <wp-root> and its MySQL database were not modified; `wp bookpress export --dir=<wp-root>` takes the site back.

Import runs the site's own WP-CLI for the dump, so BookPress never handles the database password, and it leaves the source WordPress and its MySQL database untouched. It records how to reverse itself: table prefix, table definitions, renamed keys, which tables and options are ours, home and site URL, a file manifest. It ends with a verdict for every plugin, which may say limited or refused.

Out

$ wp bookpress export --dir=<wp-root>
  backup: <wp-root>/../bookpress-backups/bookpress-backup-20260927T131258Z.sql (94.1 KB, verified)
Are you sure you want to overwrite the contents of your MySQL database? We stored a backup of it in <wp-root>/../bookpress-backups/bookpress-backup-20260927T131258Z.sql. [y/N] y
...
Success: Export complete. WordPress at <wp-root> now holds the BookPress site. The backup of what was there is <wp-root>/../bookpress-backups/bookpress-backup-20260927T131258Z.sql.

Export uses that record. A site that goes in and straight back out is byte-identical in the database and in wp-content; a test suite checks that against a real WordPress on MariaDB. Export writes the backup outside the web root. We would rather you could leave than have you decline to start.

How it works →