The Professional WordPress Workflow: Local, Git, Staging, Live

This is the way many agencies work, and FlyNode has the pieces for it. Code changes travel in Git. Content and settings travel with Push to Production. Every step to the live site has a backup or an automatic way back.

The steps

1. Build locally. Keep each custom theme or plugin in its own private repository and work on a branch on your own computer.
2. Push to the staging branch (for example develop). With a webhook set up, your staging site updates by itself. See Git Sync for WordPress Themes and Plugins.
3. Check it on staging. Staging is a full copy of the live site with its own database, so you can test with real content. Create it on the Staging tab (see Staging and Push to Production).
4. Merge to the live branch (for example main). Then press Deploy to live, or let a push to the live branch deploy by itself if you chose that.
5. FlyNode protects the live site. It puts the site into maintenance mode for a moment, replaces the theme or plugin, checks the site, and puts the old version back if the check fails.
6. Undo if you need to. Previous version brings back what was there before the last deploy.

Which tool for which change

What changed	Use
Code of your own theme or plugin	Git sync (this workflow)
Posts, pages, settings, WooCommerce data, third-party plugins	Push to Production from staging
Updates to WordPress, plugins and themes from wordpress.org	Updates with backup and rollback

Tips

• Use read-only keys, one per repository, as FlyNode creates them. Never give the key write access.
• Protect your live branch in your Git host so only reviewed changes reach it.
• Keep secrets out of the repository. Put them in wp-config.php or in the site's settings.
• Before a big release, run Push to Production or a backup first so the database has a restore point as well.