How to Automatically Deploy WordPress from Localhost to a Live Server
Developing a WordPress website locally gives you the freedom to test changes before visitors see them. But uploading files through a hosting file manager after every update can quickly become repetitive.
If you use XAMPP and VS Code, you can automate this process. Depending on your setup, files can upload whenever you save them, or deploy after you push tested changes to Git.
This guide explains the available methods, what you need to get started, and how to handle WordPress files and database changes correctly.
Table of contents9 sections
How Does Automatic WordPress Deployment Work?
Automatic deployment connects your development workflow to your hosting server.
For example, you edit a theme’s CSS locally, check the result in XAMPP, and push the change. A configured deployment process then transfers the code to the correct folder on your server.
There are three common ways to do this:
| Method | Deployment trigger | Suitable for |
|---|---|---|
| SFTP upload on save | Saving a file in your editor | Small updates and staging development |
| GitHub Actions | Pushing to a configured GitHub branch | Repeatable deployments with version history |
| cPanel Git deployment | Pushing directly to a configured cPanel repository | Hosting accounts with cPanel Git support |
Your choice depends on the access your hosting provider offers and how much control you want over when changes become live.
What Do You Need?
Before configuring deployment, gather the following:
- Your local WordPress project folder.
- The live website’s document root.
- Server hostname and SSH port.
- Hosting username.
- SSH or SFTP access.
- Permission to write to the destination folder.
- Git and a repository if you choose Git deployment.
Hosting providers may offer these features on selected plans. For example, MilesWeb’s developer hosting page advertises SSH, SFTP, and Git access. Confirm what is enabled for your account before choosing a method.
Method 1: Upload Files Automatically from VS Code Using SFTP
SFTP transfers files through an encrypted SSH connection. A compatible VS Code extension can map a local folder to a folder on your hosting account.
For example, your local child theme might be located at:
your-project/wp-content/themes/my-child-theme/Its corresponding server folder could be:
/home/your-account/public_html/wp-content/themes/my-child-theme/These paths are examples. Your actual server location may differ, particularly for additional domains.
How to Set It Up
- Install a maintained SFTP extension that supports your authentication method.
- Configure the server hostname, SSH port, username, and authentication.
- Map your local theme or plugin folder to its server destination.
- Exclude credentials, Git files, logs, and development files.
- Test a single upload and confirm its destination.
- Enable upload on save if you want every saved change transferred automatically.
The exact configuration depends on the extension. Keep passwords and private keys out of committed configuration files.
Once configured, saving a CSS or PHP file can upload it without opening your hosting panel. cPanel also provides official SFTP connection guidance for accounts using its control panel.
When Should You Use It?
SFTP upload on save is convenient for staging websites and small changes. However, saving an unfinished file can immediately affect the destination website.
For production work, a deliberate deployment after local testing gives you more control.
Method 2: Deploy WordPress Code with GitHub Actions
GitHub Actions can connect a push to your repository with a deployment workflow.
The process looks like this:
Local XAMPP development → GitHub push → deployment workflow → hosting server
How to Set It Up
First, create a repository for the code you maintain. For many WordPress projects, this means a custom theme, child theme, or custom plugin.
Next, configure SSH authentication for deployment. Authorize the public key on the server and store the private key in GitHub Actions secrets. Configure trusted server host keys so the workflow verifies the server’s identity.
Then create a workflow that:
- Runs when changes reach your deployment branch.
- Checks out the repository.
- Runs any required checks or asset builds.
- Transfers the intended files to the server.
- Reports whether deployment succeeded.
A typical local workflow is:
git add .
git commit -m "Update homepage styles"
git push origin mainThese commands assume your repository and main branch are already configured. Review the files being staged before committing. You can also commit and push through VS Code’s Source Control interface.
Pushing to GitHub alone does not update your website. The deployment workflow must be configured first.
Git records previous code versions. Restoring the live website requires deploying the chosen version again; database changes need their own recovery process.
Method 3: Use cPanel Git Deployment
If your hosting account includes cPanel’s Git Version Control feature, you may be able to deploy directly without GitHub Actions.
According to cPanel’s Git deployment documentation, automatic deployment is supported when you push directly to a cPanel-managed repository containing a valid .cpanel.yml deployment file and meeting its deployment requirements.
That file defines the commands used to deploy your code into the website directory.
There is an important difference between two workflows:
- Direct push to cPanel: Can trigger automatic deployment when configured correctly.
- Push to GitHub with cPanel pull deployment: Requires fetching and deploying through cPanel unless separate automation is configured.
Creating a GitHub repository and connecting it to cPanel does not automatically establish continuous deployment. Keep the repository outside the public website directory and deploy only the intended application files.
Which WordPress Files Should You Deploy?
For a typical custom development project, deploy the theme or plugins you maintain.
Keep environment-specific configuration and user-generated content outside routine code deployment.
| Item | Typical handling |
|---|---|
| Custom theme or child theme | Deploy through your code workflow |
| Custom plugins | Deploy through your code workflow |
| wp-config.php | Maintain separately for each environment |
| Media uploads | Manage separately |
| Database | Use a controlled migration process |
| Backups, logs and cache files | Exclude from code deployment |
| WordPress core and third-party plugins | Use a defined update process |
Avoid synchronizing your entire local WordPress folder to production without reviewing what might be overwritten or deleted. Back up the affected code before the first deployment and confirm how you will restore it if needed.
Will Elementor Changes Also Transfer?
File deployment does not transfer database content.
Elementor layouts, posts, menus, and many WordPress settings are stored in the database. Uploading a theme folder will not copy those changes to the live website.
For selected Elementor designs, template export and import may be appropriate. Larger changes may require a staging or migration tool. Media assets and local URL references may also need attention.
Be especially careful with active stores and membership websites. Replacing the live database with an older local copy can overwrite recent orders, accounts, or enquiries.
Check the Website After Deployment
A successful file transfer does not always mean the website is working correctly.
After deploying, check the affected pages, forms, navigation, and mobile layout. Clear relevant caches if old assets are still appearing.
Also keep local and server PHP versions reasonably aligned. Code that works in XAMPP may behave differently on another PHP version or with different server extensions.
For regular WordPress development, start with a narrow deployment scope: your custom theme or plugin. Test locally, push a reviewed change, and let the configured workflow handle the upload.
