WordPress Self-Hosting: LAMP, Docker, or Managed RunxBuild

WordPress self-hosting is one of three options: LAMP on a VM (the classic, full control), Docker (the official wordpress image + a database container), or a managed service (RunxBuild, Cloudways, Pressable - the team pays for ops, gets a working WordPress). The right pick: managed if you have a budget and want zero ops, Docker if you want reproducible deploys and don’t mind the container layer, LAMP if you have an existing server and want to keep things simple.

LAMP on a VM (the classic)
Docker (the reproducible path)
Managed WordPress (the no-ops path)
The right pick by scenario
Migrating from wordpress.com to self-hosted
How this fits the rest of the stack
FAQ

LAMP on a VM (the classic)

LAMP = Linux + Apache + MySQL + PHP. The stack:

Ubuntu 22.04 or 24.04 (the L)
Apache 2.4 or Nginx (the A, sort of)
MySQL 8 or MariaDB 10 (the M)
PHP 8.x with the WordPress-recommended extensions (the P)

Install:


sudo apt install apache2 mysql-server php php-mysql php-xml php-mbstring php-curl php-gd php-zip

sudo systemctl enable --now apache2 mysql

Then download WordPress, configure Apache to serve it, create a MySQL database and user, run the WordPress installer. The team that has done this once has a checklist; the team that does it for the first time follows the Ubuntu tutorial for WordPress line by line.

Pros: full control, no container layer, easy to debug. Cons: ops burden (security updates, MySQL backups, PHP version upgrades).

Docker (the reproducible path)


docker run -d --name wordpress_db -e MYSQL_ROOT_PASSWORD=secret -e MYSQL_DATABASE=wordpress mysql:8

docker run -d --name wordpress --link wordpress_db:mysql -p 8080:80 -v wordpress_data:/var/www/html wordpress:latest

Two containers: the official wordpress image and a MySQL/MariaDB image. The -v wordpress_data:/var/www/html mounts a named volume so the wp-content directory persists across container restarts.

For production, use Docker Compose:


version: '3'

services:

  db:

    image: mysql:8

    environment:

      MYSQL_ROOT_PASSWORD: secret

      MYSQL_DATABASE: wordpress

    volumes:

      - db_data:/var/lib/mysql

    restart: always



  wordpress:

    image: wordpress:latest

    depends_on:

      - db

    ports:

      - 8080:80

    volumes:

      - wordpress_data:/var/www/html

    restart: always



volumes:

  db_data:

  wordpress_data:

The team that uses Docker Compose has a one-command deploy. The team that wants to upgrade WordPress changes the image tag and runs docker compose pull && docker compose up -d.

Managed WordPress (the no-ops path)

Options:

RunxBuild - the team’s platform, designed for self-hosted apps including WordPress. One-click install, automatic backups, scaling.
Cloudways - managed Vultr, DigitalOcean, Linode, AWS. Daily backups, server monitoring, free SSL.
Pressable - managed WordPress hosting by Automattic (the company behind WordPress.com). White-label, agency-friendly.
WordPress.com Business / eCommerce - the hosted version of WordPress, no server to manage.
Kinsta - managed Google Cloud WordPress hosting.

Pros: zero ops, automatic backups, automatic scaling. Cons: cost (managed is $25-100+/month for a small site), less control, vendor lock-in.

The team that has more than 3 WordPress sites to manage picks a managed service. The team that has 1 site that they want full control over picks LAMP or Docker.

The right pick by scenario

Single site, full control, existing server: LAMP. The team that has a $5/month VPS and is comfortable with apt install uses LAMP.

Multiple sites, reproducible deploys, container-native: Docker Compose. The team that already uses containers for other apps uses Docker for WordPress.

Zero ops, scaling, agency with many clients: managed (Cloudways, Pressable, RunxBuild). The team that has more important things to do than patching WordPress uses managed.

Development environment: Docker. Spin up a WordPress instance in 30 seconds, throw it away when done. The team that develops themes or plugins uses Docker locally.

Migrating from wordpress.com to self-hosted

The team that has a wordpress.com site and wants to leave:

Export the site: wp-admin -> Tools -> Export. Get the WXR (WordPress eXtended RSS) file.
Set up the new self-hosted WordPress (LAMP, Docker, or managed).
Import: wp-admin -> Tools -> Import -> WordPress. Upload the WXR file.
Migrate media: download the wp-content/uploads directory from the old site, upload to the new one (or use a migration plugin like All-in-One WP Migration).
Update DNS: point the domain at the new host. Lower the TTL a week before the cutover so the change propagates fast.

The team that plans the migration with a 1-2 week timeline has time to test and roll back if needed.

FAQ

Can I host WordPress for free?

WordPress.com has a free tier, but the free tier uses a wordpress.com subdomain and has limitations. Truly free self-hosting requires a server (even a $5/month VPS is not free). The team that has zero budget uses wordpress.com free or static-site generators on GitHub Pages.

Do I need a database for WordPress?

Yes - WordPress stores posts, pages, comments, users, settings, and plugin/theme options in MySQL or MariaDB. The team that uses SQLite (with the SQLite Database Integration plugin) gets a single-file database, but most production WordPress uses MySQL.

How do I update WordPress?

WordPress core has automatic updates for minor versions. Major versions and plugin/theme updates are manual. The team that enables automatic updates for everything patches within hours of a CVE; the team that updates manually has a window of exposure.

Should I use Apache or Nginx for WordPress?

Both work. Nginx is faster for static content; Apache has the .htaccess model that many WordPress plugins assume. The team that uses Apache has the easiest time with WordPress plugins; the team that uses Nginx has better performance and is comfortable with the config.

How do I migrate from one host to another?

The most reliable path: a migration plugin (All-in-One WP Migration, Duplicator) that bundles the database and wp-content into a single file. The team that uses this has a 10-minute migration, not a 10-hour migration.

How this fits the rest of the stack

For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.

Useful related references: