Step 8: Go live

Go live in small, reversible steps, and check each one on the real site.

1. Harden the renderer before it is public

• No diagnostics endpoints; health routes return no configuration.
• Errors never include keys or secrets.
• npm audit at zero.
• FLX_RENDER_AUTH_MODE=enforce in production.

2. Isolate the WordPress site on the server

Give the site its own PHP-FPM pool and system user, so a problem in another site on the same server can't read this one. Remove backup or migration plugins that leave archives in the web root (Twenty Twenty-Five's demo had Duplicator). Script server changes with a check-only mode, automatic rollback and a verification at the end; a script that silently stops half-way is worse than none.

3. Deploy the renderer

Vercel project, environment variables, domain and DNS (Flx Render). Then check from outside: /health gives 200, and an unsigned render request gives 401.

4. Turn Flx on

Write the signing key into wp-config.php, set the same pair on the renderer, then save the Render URL and activate the plugin. Install only after the renderer passes the checks above.

5. Verify on the live site

From the server, against the origin (so CDN caches are not involved):

• each route returns the expected status, is served by Flx, and has private, no-store;
• no Set-Cookie, and feeds still native;
• the page includes the theme CSS (not just the renderer's stylesheet);
• the menu and footer look right;
• through the CDN, the HTML is not cached (cf-cache-status: DYNAMIC on Cloudflare).

6. Keep the rollback one command away

Deactivating the plugin returns every visitor to normal WordPress at once. Write the command down before you go live.

After go-live

Each later improvement (a template, a block) is a small change through the same loop: branch → CI (fidelity gate + eligibility) → pull request → merge → automatic deploy → live check. For Twenty Twenty-Five, the whole style pass (steps 4–6) took one day of a three-day timebox.