[Blog](https://deploywithox.com/blog) [Guides](https://deploywithox.com/blog#c-guides)

# How to self-host WordPress without Docker on your own VPS

Run WordPress 7.1.3 on your own Ubuntu server with ox: FrankenPHP, MariaDB, a WP-Cron timer and an admin made on deploy, from the config that ran.

Saurav Sharma Oct 17, 2026 10 min read

On this page

- [What you need](https://deploywithox.com/blog/self-host-wordpress#what-you-need)
- [The steps](https://deploywithox.com/blog/self-host-wordpress#steps)
- [The ox.toml, line by line](https://deploywithox.com/blog/self-host-wordpress#config)
- [MariaDB and WP-Cron](https://deploywithox.com/blog/self-host-wordpress#services)
- [Updates and backups](https://deploywithox.com/blog/self-host-wordpress#updates)
- [Frequently asked questions](https://deploywithox.com/blog/self-host-wordpress#faq)

To self-host WordPress you need an Ubuntu server, a fork of the WordPress repo with an `ox.toml` and two small PHP files added, and four variables. In our run the first deploy took about 2 minutes, and ox set up MariaDB for the site and a timer for WordPress's scheduled tasks.

**How we tested** On Oct 17, 2026, ox deployed WordPress 7.1.3 from commit [`fc9832be`](https://github.com/WordPress/WordPress/commit/fc9832bef919c2a08541248db23af90d14ffb082) on a fresh DigitalOcean server with 8 vCPUs and 16 GB of memory. The run then redeployed it, backed it up and rebooted the server. Then a separate test agent, one that did not write the config, signed in, published a post and saw it on the blog's home page after a reload, and checked the app's services and its backup.

[WordPress](https://github.com/WordPress/WordPress) is free publishing software for blogs and websites, written in PHP and released under the GPL, version 2 or later. You write in a block editor under `/wp-admin/`, and visitors read the front of the site. Content, users and settings live in a MySQL-compatible database, and uploaded files go to `wp-content/uploads`. The commit the run deployed is labelled `Tag 7.1.3` and says it was built from that tag in WordPress's own Subversion repository.

ox deployed WordPress 7.1.3 (commit fc9832be) on Oct 17, 2026 on a fresh DigitalOcean server with 8 vCPUs and 16 GB of memory; the first deploy took 2 minutes and a redeploy took 31 seconds.

- **First deploy:** 2 minutes, from adding the project until the app passed the run's first checks.
- **Redeploy of the same commit:** 31 seconds, until the app passed the checks again.
- **Server:** DigitalOcean, 8 vCPUs and 16 GB of memory (`s-8vcpu-16gb`), with this app alone on it. Every one of the 85 apps we deployed ran on this one size, so it was not picked for this app.
- **Memory in use after the reboot:** 996 MB of 15986 MB, for the whole server: Ubuntu, the app and its staging copy, its services, Caddy and the ox agent. On a server with no apps, ox's tests on real servers hold the agent to 40 MB or less and Caddy to 50 MB or less.
- **Services ox runs for it:** `mysql`.
- **Scheduled jobs:** `wpcron`.
- **Source:** [github.com/WordPress/WordPress](https://github.com/WordPress/WordPress) at 7.1.3, commit [`fc9832be`](https://github.com/WordPress/WordPress/commit/fc9832bef919c2a08541248db23af90d14ffb082).

The new WordPress site's blog page

The WordPress dashboard after logging in as admin

The blog showing the post written in the browser

## What you need

- An Ubuntu LTS server. The run used the size in the facts above and measured the memory there. WordPress's readme asks for PHP 7.4 and MySQL 5.5.5, each or newer, and names PHP 8.3 or newer and MySQL 8.0 or MariaDB 10.11 or newer as the versions it prefers. ox serves PHP apps with FrankenPHP, which carries PHP 8.5, and its mysql service is MariaDB 11.8.
- A GitHub account to fork `WordPress/WordPress`, and an ox account, which you open by signing in with GitHub.
- A site title, plus a name, an email address such as `admin@example.com` and a password for the first administrator. The run set up no mail, and sending mail was not tested.

## The steps

Open Servers in the ox dashboard and press Add server. It shows a one-time install command. Run it as root on your Ubuntu server. It sets up the ox agent and Caddy, and the server then appears in your account.

Fork `WordPress/WordPress` on GitHub and check out commit `fc9832be`, the one the run deployed. Add `ox.toml`, `wp-config.php` and `ox-install.php` at the root of your fork, as shown below, then commit and push. Next write a file named `wordpress.env` on your laptop with one `KEY=value` line for each of the four variables listed below. The config does not mark them as required, so fill in all four before the review. With the [ox CLI](https://deploywithox.com/docs/cli) signed in (`ox login`), run:

Shell

```bash
ox new <you>/WordPress
ox review wordpress --from-file wordpress.env --wait
```

ox lowercases the repo name for the project, so the project is `wordpress`. The review saves your values and starts the first deploy, and `--wait` follows the run until it ends. The console has the same two steps, and the [quickstart](https://deploywithox.com/docs/quickstart) walks through them.

When the deploy is green, open the https address ox shows for the project and go to `/wp-login.php`. Sign in with `WP_ADMIN_USER` and `WP_ADMIN_PASSWORD`, and the dashboard opens at `/wp-admin/`. The first time the block editor opens, a welcome tip may need closing. To try it, open Posts, press Add New, write a line, and press Publish, then confirm: the post shows on the blog's home page. The run served WordPress on that preview address only, so a domain of your own was not part of it. The [domains page](https://deploywithox.com/docs/operate/domains) covers how ox adds one.

## The ox.toml, line by line

TOML

```toml
# WordPress 7.1.3 (PHP, MySQL), as its operator would write it: ox detects
# FrankenPHP. The overlay adds wp-config.php (reads ox's MYSQL_URL) and an
# installer that does what wp-cli's core install does.

[build]
# Creates the tables and the admin account on the first deploy, and runs the
# database upgrade after a new release. frankenphp has PHP built in, so no
# separate php-cli is needed.
migrate = "frankenphp php-cli ox-install.php"

[services]
mysql = {}

[storage]
# Uploads are the only folder WordPress writes at run time.
keep = ["wp-content/uploads"]

[cron]
# WP-Cron runs when a page loads, which a quiet site never does.
wpcron = { schedule = "*/5 * * * *", run = "frankenphp php-cli wp-cron.php" }
```

There is no `[app]` section. ox finds `wp-load.php` and `wp-includes/version.php`, knows the repo is WordPress, and starts FrankenPHP with the repo root as the web root.

- `migrate` runs `ox-install.php` on every deploy, after the build and before traffic switches. FrankenPHP has PHP built in, and `php-cli` is its way to run a script, so the server needs no PHP package of its own.
- `mysql = {}` under `[services]` asks for a MariaDB that belongs to this project alone. It runs as a systemd unit under the project's user, with a password ox generates, and gives the app one variable, `MYSQL_URL`.
- `keep = ["wp-content/uploads"]` names the one folder WordPress writes while it runs. A PHP release is read-only, so ox links that folder to the project's data directory, which stays writable and survives deploys.
- The `wpcron` job runs `wp-cron.php` every five minutes, in UTC. WordPress's header in that file says it normally runs when someone visits, and that a site with few visits can call it from a server cron. A quiet site gets no visits, so the timer keeps scheduled tasks running.

`ox-install.php`

Code

```
<?php
// Run by the deploy only: the web root is the repository, so a request for
// this file does nothing.
if ( PHP_SAPI !== 'cli' ) {
	http_response_code( 404 );
	exit;
}
// The first run installs WordPress; later runs apply a database upgrade.
define( 'WP_INSTALLING', true );
require __DIR__ . '/wp-load.php';
require_once ABSPATH . 'wp-admin/includes/upgrade.php';

if ( ! is_blog_installed() ) {
	$result = wp_install(
		getenv( 'WP_SITE_TITLE' ),
		getenv( 'WP_ADMIN_USER' ),
		getenv( 'WP_ADMIN_EMAIL' ),
		true,
		'',
		getenv( 'WP_ADMIN_PASSWORD' )
	);
	echo "installed WordPress, admin id " . $result['user_id'] . "\n";
} else {
	global $wp_db_version;
	if ( (int) get_option( 'db_version' ) !== (int) $wp_db_version ) {
		wp_upgrade();
	}
	echo "WordPress already installed\n";
}
```

`wp-config.php`

Code

```
<?php
// ox gives a mysql service one variable, MYSQL_URL (mysql://user:password@host:port/name).
$db = parse_url(getenv('MYSQL_URL') ?: '');
define( 'DB_NAME', ltrim($db['path'] ?? '', '/') );
define( 'DB_USER', $db['user'] ?? '' );
define( 'DB_PASSWORD', $db['pass'] ?? '' );
define( 'DB_HOST', ($db['host'] ?? '127.0.0.1') . ':' . ($db['port'] ?? 3306) );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

// The salts derive from the database password, which ox generates per project.
foreach ( array( 'AUTH_KEY', 'SECURE_AUTH_KEY', 'LOGGED_IN_KEY', 'NONCE_KEY', 'AUTH_SALT', 'SECURE_AUTH_SALT', 'LOGGED_IN_SALT', 'NONCE_SALT' ) as $name ) {
	define( $name, hash_hmac('sha256', $name, DB_PASSWORD) );
}

$table_prefix = 'wp_';

// A release is read-only while it runs: no theme, plugin or core edits from the dashboard.
define( 'DISALLOW_FILE_MODS', true );
define( 'WP_DEBUG', false );

// Caddy terminates TLS in front of the app.
if ( ($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}
if ( getenv('PUBLIC_URL') ) {
	define( 'WP_HOME', getenv('PUBLIC_URL') );
	define( 'WP_SITEURL', getenv('PUBLIC_URL') );
}

if ( ! defined('ABSPATH') ) {
	define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';
```

`wp-config.php` is the file WordPress reads its settings from. The repo ships only `wp-config-sample.php`, so you add this one. It takes the database host, port, name, user and password from `MYSQL_URL`. The eight security keys and salts WordPress uses for login cookies and nonces are an HMAC of each name with the database password, which ox generates for the project, so no secret sits in git. `DISALLOW_FILE_MODS` is on because the release is read-only, so the dashboard cannot edit files, install anything or update core. Caddy ends TLS in front of the app, so when it forwards `X-Forwarded-Proto: https` the file tells WordPress the request was secure. `WP_HOME` and `WP_SITEURL` come from `PUBLIC_URL`, the address ox gives the project.

`ox-install.php` is run by the deploy and nothing else: a request for it over the web gets a 404. If WordPress is not installed yet, it calls `wp_install` with the site title and the admin's name, email and password, and makes the site visible to search engines. That also creates WordPress's sample post and page, as the first screenshot shows. On a site that is installed, it runs the database upgrade when the database's version differs from the code's. It prints which case it found, which makes it safe on every deploy.

Shell

```bash
WP_SITE_TITLE
WP_ADMIN_USER
WP_ADMIN_EMAIL
WP_ADMIN_PASSWORD
```

`WP_SITE_TITLE` is the site's name. `WP_ADMIN_USER`, `WP_ADMIN_EMAIL` and `WP_ADMIN_PASSWORD` make the first administrator. `ox-install.php` reads all four only while WordPress is not installed, so changing one later changes nothing. You do not set `MYSQL_URL` or `PUBLIC_URL`, because ox provides both. The [variables page](https://deploywithox.com/docs/operate/variables) explains how ox stores and shows values.

## MariaDB and WP-Cron

The run also deployed a staging copy beside production, with a second MariaDB and its own cron timer, and the memory figure above counts both. The test agent saw each timer run to success. `wp-cron.php` prints nothing when it works, so a clean exit is the sign.

## Updates and backups

A push to your fork, or `ox deploy wordpress --wait`, deploys again. The run redeployed the same commit in the time shown above. Moving to a newer WordPress release was not tested, though the migrate step is written to run the database upgrade when the versions differ. The dashboard cannot change files, so updating WordPress means updating the repo your fork deploys.

The run's backup was the `mysql` one. `ox backups wordpress` lists backups, and `ox backups wordpress now mysql` makes one, as Back up now does on the Backups tab. Restoring a backup was not tested, and neither was whether a backup includes the uploads folder. The [backups page](https://deploywithox.com/docs/operate/backups) describes what ox keeps. More apps are on the [self-hosting page](https://deploywithox.com/self-hosting).

## Frequently asked questions

### Do I need Docker to self-host WordPress?

No. ox serves WordPress with FrankenPHP, a PHP server that carries its own PHP, and runs MariaDB as a systemd service beside it. Nothing is pulled as an image. The run used a fork of WordPress's repo with an ox.toml and two small PHP files added, and the site came up from that.

### Which database does self-hosted WordPress need?

MySQL 5.5.5 or newer, or MariaDB, according to WordPress's readme, which also prefers MySQL 8.0 or newer, or MariaDB 10.11 or newer. ox's mysql service is MariaDB 11.8, private to the project. It gives the app one MYSQL_URL, and the wp-config.php in this guide reads it, so you never type a database password.

### How do I create the first WordPress admin without the setup screen?

Put WP_ADMIN_USER, WP_ADMIN_EMAIL and WP_ADMIN_PASSWORD, plus WP_SITE_TITLE, in the env file before the first deploy. The migrate step runs ox-install.php, which installs WordPress and creates that administrator, so the setup screen never appears. Then sign in at /wp-login.php. Changing the values later changes nothing, because the script skips an installed site.

### Can I install plugins and themes from the WordPress dashboard?

Not on this setup. The release is read-only while it runs, and wp-config.php sets DISALLOW_FILE_MODS, so installing or updating plugins, themes and core from the admin does not work. Uploading media and adding a plugin through your repo were not tested, though wp-content/uploads is a kept folder.

### How much memory does self-hosted WordPress use?

The whole server used the memory shown in the facts after the reboot. That figure counts WordPress, its staging copy, two MariaDB instances, Caddy and the ox agent. The run did not measure memory under real traffic. ox works on any server from 1 GB up and tells you when memory is why an app stopped.

New to running apps on your own server? [How ox self-hosts your apps](https://deploywithox.com/self-hosting) shows what ox sets up on your server.

On this page

- [What you need](https://deploywithox.com/blog/self-host-wordpress#what-you-need)
- [The steps](https://deploywithox.com/blog/self-host-wordpress#steps)
- [The ox.toml, line by line](https://deploywithox.com/blog/self-host-wordpress#config)
- [MariaDB and WP-Cron](https://deploywithox.com/blog/self-host-wordpress#services)
- [Updates and backups](https://deploywithox.com/blog/self-host-wordpress#updates)
- [Frequently asked questions](https://deploywithox.com/blog/self-host-wordpress#faq)
- [Do I need Docker to self-host WordPress?](https://deploywithox.com/blog/self-host-wordpress#faq-docker)
- [Which database does self-hosted WordPress need?](https://deploywithox.com/blog/self-host-wordpress#faq-database)
- [How do I create the first WordPress admin without the setup screen?](https://deploywithox.com/blog/self-host-wordpress#faq-admin)
- [Can I install plugins and themes from the WordPress dashboard?](https://deploywithox.com/blog/self-host-wordpress#faq-plugins)
- [How much memory does self-hosted WordPress use?](https://deploywithox.com/blog/self-host-wordpress#faq-memory)

Written by Saurav Sharma

Builds ox. Writes about running apps on servers you own, without Docker and without a platform bill.

[Older post How to Self-Host Web Apps on Your Own VPS (2026 Guide)](https://deploywithox.com/blog/self-host-web-apps-on-your-own-vps) [Newer post How to self-host wallabag on your own VPS, without Docker](https://deploywithox.com/blog/self-host-wallabag)

## Keep reading

- Guides [Self-Hosted Open-Source Apps Deployed with ox: All 85](https://deploywithox.com/blog/self-hosted-open-source-apps-deployed-with-ox) ox deployed 85 open-source apps from pinned commits on fresh servers, with no Docker. The stacks, services, deploy times and a table of every app. Saurav Sharma Oct 17, 2026 16 min read
- Guides [How to self-host AFFiNE on your own VPS without Docker](https://deploywithox.com/blog/self-host-affine) Run AFFiNE v0.27.4 on your own Ubuntu server with ox: Postgres with pgvector, Redis, a Rust and Node build, and an admin made from two variables. Saurav Sharma Oct 17, 2026 12 min read
- Guides [How to self-host Akaunting on your own VPS without Docker](https://deploywithox.com/blog/self-host-akaunting) Run Akaunting 3.2.4 on your own Ubuntu server with ox: PHP, MariaDB, a scheduler and the first company and admin made on deploy, from the config that ran. Saurav Sharma Oct 17, 2026 10 min read

## Deploy to a server you own

ox sets up systemd, Caddy and PostgreSQL on your Ubuntu server and deploys on every push. Free for your first project.

[Sign up with GitHub](https://deploywithox.com/login/github) [Read the docs](https://deploywithox.com/docs)