Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Deploy WordPress with the right first-boot and persistence expectations.

​
Prerequisites

  • A healthy node
  • A published WordPress template

​
Workflow

1
Open the WordPress template detail page and review its readiness notes.
2
Choose the site title, admin credentials, and bundled database credentials.
3
Deploy on either a generated StackShift hostname or the final custom domain, then redeploy later if the hostname changes.

​
What you get

  • WordPress provisioned as a managed runtime-native stack, not hand-rolled containers.
  • A bundled MariaDB database for the site, managed as part of the runtime.
  • Persistent named volumes for WordPress files and the database — these are what backups capture.

​
First boot and credentials

At deploy you set the site title, the admin username and password, and the bundled database credentials. WordPress runs its first-boot setup against those values, so choose them deliberately rather than relying on placeholders.

​
Hostname now, custom domain later

You can launch on a generated StackShift hostname and attach the final custom domain afterwards. WordPress stores its site URL internally, so if you change the hostname later you resync the URLs (redeploy or the update site URL action) to avoid redirect loops and broken assets.

​
Expected result

A template-backed WordPress stack is running with persistent WordPress and database volumes.

Connect a custom domain to WordPress

Understand how StackShift routing and WordPress site URLs interact before and after first boot.

Back up and restore a WordPress stack

Use StackShift stack backups for WordPress content and bundled MariaDB data, then validate the app after restore.