Deploy: WordPress on your server, front end on the edge

On your machine, all of this is two folders. In production, two services talking to each other over HTTP. Let’s look at where each piece goes and — the thing everyone worries about most — why updating WordPress isn’t going to wipe your content.

The map

• WordPress: on a normal PHP host, on a private subdomain like cms.yourdomain.com. Nobody visits it except you, to edit.
• Astro front end: compiled to static HTML and deployed to the edge (Vercel, Netlify, Cloudflare Pages). It’s what the world sees.

Everyone’s fear: «will an update wipe my content?»

No. A WordPress core update only replaces wp-admin, wp-includes and the wp-*.php files. It touches neither the database (where all your content lives) nor wp-content/uploads (your media).

The real danger only shows up in containers: if you redeploy a WordPress in Docker without persistent volumes, the disk is ephemeral and comes back factory-fresh. That’s why we separate two things:

• Core (disposable): the WordPress image. Update it without fear.
• State (persistent): database and media, in volumes nobody touches.

# docker-compose.yml (summary)
services:
  wordpress:
    image: wordpress:php8.3-apache   # disposable core
  db:
    image: mysql:8.4
volumes:
  db_data:      # ← your content, untouched between updates
  wp_uploads:   # ← your media, untouched

On Hostinger, step by step (the simplest route)

If you’d rather not manage servers, a host like Hostinger is more than enough: persistence and backups come sorted out already. And to update the WordPress from your own agent, the comfiest option is its Git deployment. You set it up once:

1. Push your code folder (the mu-plugins) to a GitHub repository.
2. In hPanel: Websites → your site → Dashboard → Advanced → Git.
3. Connect the repo, pick the main branch and, as the target folder, public_html/wp-content/mu-plugins.
4. Turn on auto-deploy.

From then on, updating is a git push — the same gesture as the front end. Don’t want to set up Git? Drag the file over by SFTP with FileZilla and you’re done.

One detail: CORS

If the front end only fetches the data at build time (as it does here), the requests are server to server and CORS doesn’t even come into it. Only if you fetch from the browser will you need to open up the front end’s origin in the mu-plugin.

The publishing flow

1. You write and hit «Publish» in WordPress.
2. A webhook notifies the front-end platform.
3. Astro fetches the content again and regenerates the HTML.
4. In seconds, the change is online across the whole CDN.

You edit with the comfort of WordPress. You serve with the speed and security of a static site. And if tomorrow you swap out the whole front end, the content doesn’t even notice.

Let your agent deploy it

Set up the deploy for me following the wp-wow skill: the Astro front end
on Vercel with a deploy hook, and the WordPress on Hostinger with Git
deployment to wp-content/mu-plugins. Explain how to wire up the publish
webhook so the front end rebuilds itself when I publish.

It’s live now. Last piece: how to grow it without fear.