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

​
Goal

Attach the right domain without leaving WordPress and StackShift out of sync.

​
Prerequisites

  • A deployed or planned WordPress stack

​
Workflow

1
Decide on the public domain as early as possible.
2
Attach or configure the domain in StackShift.
3
Verify the public site and /wp-admin on the final hostname.

​
Why WordPress is different from a plain app

WordPress stores its own site URL and home URL in the database and bakes them into links, redirects, and asset paths. So a custom domain is not only a routing change at the edge — the WordPress site URL has to match the hostname it is actually served on.

​
Attaching the domain

  • Decide the public domain as early as possible — ideally before first boot.
  • Attach the domain to the WordPress project in StackShift so routing and TLS are issued for it.
  • Verify both the public site and /wp-admin on the final hostname.

​
Keeping URLs in sync

If the site was first deployed on a generated hostname, resync the WordPress URLs after attaching the domain — a redeploy or the update site URL action rewrites the stored URLs. Skipping this is the usual cause of redirect loops, mixed-content warnings, or an admin that bounces back to the old hostname.

​
Expected result

Routing and WordPress site URLs line up with fewer surprises after launch.

​
Common failures

  • The WordPress site URL still points at the generated hostname, causing redirect loops or mixed content.
  • The domain is routed at the edge but WordPress was never resynced to it.

Deploy WordPress on StackShift

Launch single-site WordPress as a template-backed stack with bundled MariaDB and persistent storage.

WordPress Control Surface

A first-class operational surface for direct WordPress projects: overview, narrow safe actions, diagnostics, and recent history.