WordPress

Deploy WordPress to Magic Containers

This guide walks you through deploying WordPress with MariaDB to Magic Containers. You can deploy using a one-click template or configure the containers manually.

This is a starter guide intended to show how quickly a real workload can run on Magic Containers. It’s aimed at developers comfortable customising Docker images, working with environment variables and volumes, and making changes to a WordPress install at the file level. A production-grade WordPress deployment will need additional hardening, image tuning, backup, and caching decisions beyond what’s covered here.

Don’t have a bunny.net account yet? Sign up and enable Magic Containers to get started.

Deploy with a template

The fastest way to get WordPress running is to use the built-in template, which pre-configures WordPress and MariaDB with persistent volumes.

1. Open the WordPress template

   In the bunny.net dashboard, go to Magic Containers and open the WordPress template.

2. Name your app

   Give your application a name.

3. Configure environment variables

   The template includes pre-configured environment variables for WordPress and MariaDB. Review and update passwords as needed before deploying.

4. Choose a region

   Select the region where you want to deploy your application.

   WordPress with MariaDB should use single region deployment with a single instance. Each pod gets its own dedicated volume with no data replication — this applies both across regions and within the same region.

5. Deploy

   Click Deploy to launch your WordPress site.

Once deployed, open the endpoint URL to complete the WordPress installation wizard.

Deploy manually

If you prefer to configure everything yourself, follow these steps.

1. Create a new app

   Go to the bunny.net dashboard, select Magic Containers, and click Add App. Select Single region deployment.

   WordPress with a database should use single region deployment with a single instance. Each pod gets its own dedicated volume with no data replication — scaling to multiple pods or regions would result in separate, isolated databases each with their own data.

2. Add the WordPress container

   Click Add Container and configure the image:

   • Registry: Docker Hub
   • Image: library/wordpress
   • Tag: apache

   Configure the following environment variables:

   Variable	Value
   WORDPRESS_DB_HOST	127.0.0.1
   WORDPRESS_DB_USER	wordpress
   WORDPRESS_DB_PASSWORD	a strong password
   WORDPRESS_DB_NAME	wordpress

3. Add a volume for WordPress content

   In the Volumes section of the WordPress container, add a volume:

   • Name: wp-content
   • Mount path: /var/www/html/wp-content

   This persists your themes, plugins, and uploads across restarts.

4. Add the MariaDB container

   Click Add Container and configure a second container:

   • Registry: Docker Hub
   • Image: library/mariadb
   • Tag: latest

   Configure the following environment variables:

   Variable	Value
   MARIADB_ROOT_PASSWORD	a strong root password
   MARIADB_USER	wordpress
   MARIADB_PASSWORD	same password as WORDPRESS_DB_PASSWORD
   MARIADB_DATABASE	wordpress

5. Add a volume for MariaDB

   In the Volumes section of the MariaDB container, add a volume:

   • Name: mariadb-data
   • Mount path: /var/lib/mysql

   This ensures your database files persist across restarts and redeployments.

6. Add an endpoint

   Go to the Endpoints tab, click Add New Endpoint, and set the container port to 80. Select the WordPress container.

7. Deploy

   Review your settings and click Confirm and Create.

8. Set the site URL

   After deploying, copy the WordPress endpoint URL from the Endpoints tab (e.g. https://mc-xxx.bunny.run). Go to the WordPress container’s Environment Variables and add:

   Variable	Value
   WP_HOME	your WordPress endpoint URL
   WP_SITEURL	same as WP_HOME

   This prevents WordPress from auto-detecting the wrong URL, which can happen in multi-container setups where multiple endpoints exist. Redeploy after adding these variables.

Complete the installation

If you plan to use a custom domain, add it to your WordPress endpoint and update WP_HOME and WP_SITEURL before running the installation wizard. WordPress stores the site URL during installation, and completing setup on the default mc-xxx.bunny.run URL means you’ll need to update it later. See Add a custom hostname for details.

Once your app is running, open the WordPress endpoint URL in your browser. WordPress will display the installation wizard where you can:

1. Select your language
2. Set the site title
3. Create an admin account
4. Complete the installation

After setup, your WordPress site is live and accessible at the endpoint URL.

Environment variables

The WordPress container supports these key environment variables:

Variable	Description
WORDPRESS_DB_HOST	Database host (use 127.0.0.1 for multi-container)
WORDPRESS_DB_USER	Database username
WORDPRESS_DB_PASSWORD	Database password
WORDPRESS_DB_NAME	Database name
WORDPRESS_TABLE_PREFIX	Table prefix (default: wp_)
WORDPRESS_DEBUG	Enable debug mode (1 or 0)
WP_HOME	Full URL of the site (e.g. https://mc-xxx.bunny.run)
WP_SITEURL	Full URL where WordPress is installed (usually same as WP_HOME)

Use 127.0.0.1 instead of localhost for the database host. Some clients interpret localhost as a Unix socket connection, which will fail in a container environment. Using 127.0.0.1 forces a TCP connection.

Persistent volumes

The WordPress template uses two persistent volumes:

Volume	Mount path	Purpose
wp-content	/var/www/html/wp-content	Themes, plugins, and uploads
mariadb-data	/var/lib/mysql	Database files

Without these volumes, all data is lost when containers restart. See persistent volumes for more details.

Always set strong passwords for database credentials, even if the database is not exposed externally. Other containers in the same pod can access the network, and a password protects against accidental or unauthorized access.

Manage files with File Browser

Since Magic Containers don’t yet provide SSH access, you can temporarily add File Browser as a sidecar container when you need to inspect files, copy something out, or run a manual procedure that can’t be done from WordPress admin (for example, editing wp-config.php, removing a broken plugin directory, or uploading a file that exceeds the WordPress upload limit).

Treat File Browser as a short-lived tool. The filebrowser/filebrowser image doesn’t accept credentials through environment variables, and on first boot it generates a random password that is printed once to the container logs and not stored anywhere you can retrieve later. Use it for the task at hand, then remove the endpoint and container. For anything you do regularly, do it through WordPress admin instead.

1. Add the File Browser container

   In your app settings, click Add Container and configure:

   • Registry: Docker Hub
   • Image: filebrowser/filebrowser
   • Tag: latest

   Since WordPress already uses port 80, configure File Browser to listen on a different port by setting the following environment variable:

   Variable	Value
   FB_PORT	8085

2. Mount the wp-content volume

   In the Volumes section, mount the same wp-content volume used by the WordPress container:

   • Name: wp-content
   • Mount path: /srv

   File Browser serves files from /srv by default, so this gives it access to your WordPress themes, plugins, and uploads.

3. Add an endpoint

   Go to the Endpoints tab and add a new endpoint for the File Browser container on port 8085.

4. Capture the generated password from the logs

   Open your app and go to the Logs tab as it deploys. On first boot, File Browser prints a line similar to:

   User 'admin' initialized with randomly generated password: <random-password>
   

   The password is shown once. If you miss it, redeploy the container to generate a new one.

5. Log in

   Open the File Browser endpoint URL in your browser and sign in:

   • Username: admin
   • Password: the value you copied from the logs

   Do your file work, then move on to the cleanup step below.

6. Remove File Browser when you're done

   Once you’ve finished, remove the File Browser endpoint and container from your app and redeploy. This closes off the publicly reachable login page and avoids leaving a long-lived tool exposed alongside your site.

Anyone with the endpoint URL can reach the File Browser login page.

Add a custom hostname

To use your own domain with WordPress:

1. Go to your app’s Endpoints tab
2. Add a custom hostname to your CDN endpoint
3. Update the WP_HOME and WP_SITEURL environment variables to your custom domain (e.g. https://example.com)

If you installed WordPress using the default mc-xxx.bunny.run URL, you must update WP_HOME and WP_SITEURL to match your custom domain. Without this, WordPress will continue redirecting to the old URL for login, admin pages, and internal links.

See endpoints for more details on configuring custom hostnames.