Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.bunny.net/llms.txt

Use this file to discover all available pages before exploring further.

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:
VariableValue
WORDPRESS_DB_HOST127.0.0.1
WORDPRESS_DB_USERwordpress
WORDPRESS_DB_PASSWORDa strong password
WORDPRESS_DB_NAMEwordpress
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:
VariableValue
MARIADB_ROOT_PASSWORDa strong root password
MARIADB_USERwordpress
MARIADB_PASSWORDsame password as WORDPRESS_DB_PASSWORD
MARIADB_DATABASEwordpress
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:
VariableValue
WP_HOMEyour WordPress endpoint URL
WP_SITEURLsame 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:
VariableDescription
WORDPRESS_DB_HOSTDatabase host (use 127.0.0.1 for multi-container)
WORDPRESS_DB_USERDatabase username
WORDPRESS_DB_PASSWORDDatabase password
WORDPRESS_DB_NAMEDatabase name
WORDPRESS_TABLE_PREFIXTable prefix (default: wp_)
WORDPRESS_DEBUGEnable debug mode (1 or 0)
WP_HOMEFull URL of the site (e.g. https://mc-xxx.bunny.run)
WP_SITEURLFull 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:
VolumeMount pathPurpose
wp-content/var/www/html/wp-contentThemes, plugins, and uploads
mariadb-data/var/lib/mysqlDatabase 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:
VariableValue
FB_PORT8085
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.