What is a Staging Environment? How to Create and Manage a Staging Site with xCloud

Learn to create a WordPress staging environment on xCloud that mirrors your production site. The tutorial covers updating plugins safely, syncing databases and uploads, and pushing changes back live using incremental transfers. Key warning: deleting production also removes its staging copy.
Chapters
Have you ever gone to your WordPress website, noticed there were some updates, hit the update button, and end up with a webpage that looks like this one? I have. Everyone has. Fortunately, it's avoidable. I'm going to show you a really cool tool for testing what's going to happen to your website when you do updates before you do updates. It's called a staging server, and I'm going to show you how to do it on xCloud. I'm here on my xCloud dashboard for my site, cybernate360.com, and I want a staging server. If you click this little down arrow here, you'll see there's a spot to add staging, but there's also this link here to deploy staging all the time. They do the same thing. You can pick whichever one you want. So I'm going to click deploy staging, and you can choose a test domain, which will be something not really useful, uh, toppersite-sz@1.host. Um, or you can choose a custom domain. And what's cool is that you can use a staging server or a subdomain off your main domain. So I'm going to choose staging.cybernate360.com. And since I have integrated Cloudflare with my account already, all I have to do is click there and it's all set on Cloudflare just like that. That took less than a second. So then I hit deploy staging. Now what this is doing is actually spinning up a new website next to your other one. And there we are. We have a new website called staging.360 and I So I'm going to go to MagicLogin and there's our new site. So there's staging and there's production and you can see that they look identical. Um, there are 2 plugins to be updated in production and 2 to be updated on staging. So I'm going to show you a couple of things that you can do with this. Uh, the first thing I'm going to do is update plugins. On staging. So we go to updates and there are two and I hit update and that worked. So now you have two options. You can either just go to production and hit update, or you can push the new files back using the tools here. Um, uh, staging servers have a managed staging link right here and you can pull or push. And right now we're going to talk about push. Right below, there's a spot that keeps a log of everything that happens. I'm going to push, and I didn't make any database changes, so I'm not going to check that yet, but we'll— I'll show you that in a minute. But for files, you can either send all the files back, which I don't recommend because it's just the same files already there, or you can do incremental, which copies only the new stuff. Okay. That's fast and cool. So, um, also right here is an option to take a backup of your production site before pushing changes. It does this automatically. So, uh, if it, for some reason it goes sideways, which it shouldn't, but there's, if it does, there's a backup. So let's go to push to production and you'll see how that goes. So now the push has been initiated. It hasn't happened or hasn't finished yet. Uh, you can see as of 12 seconds ago, it was pending. There. Now it is finished. Uh, I'm going to reload this page and it should update. What's happened here? Yeah. So the push finished 9 seconds ago. So now if we reload, uh, we're going to watch this little thing at the top when I reload. And after a reload, you'll see that, uh, it's done. Let's go to plugins. And you see there are none to be updated. So that's a very simple push. You made some changes on staging and you push the files back to production. Now I want to show you what happens if something breaks. I have WooCommerce installed on both servers and I have a plugin that I commissioned where if I go to my cart, my total gets a red border. That's all it does. It's a very simple plugin. And we go to plugins. I'm gonna do it another tab. You can see it right here, Total Border, written by somebody who is definitely not Topher. Um, I wanted an update, so there's a version 2.0. So I'm going to add plugin, upload, and install. And it replaces current with uploaded. And then I go check out my site. Oh, it's broken. That's no good. But this is staging, so my main site is still fine. So now I need to fix this. So I come back to my panel here and I'm gonna go to Access Data and go to File Manager. You could do this with SSH if you wish, but I'm going to enable the File Manager and launch it. And all we're really gonna do is log in and delete the plugin. So we go to wp-content, plugins, there's Total Border. I check it and delete. Then pull up our broken store and it is gone. So now, uh, I'm gonna reinstall. There you can see it has been deactivated due to error: plugin does not exist. So I'm going to add the old version back in and we're back. So now I know that I can't just install 2.0 on production or push it because it's broken. So I go back to my developer who's definitely not Tover. I say, hey, you need to fix this. Send me a new version. I'll try it in staging again. Now, something else I want to show you that's fairly important is the database push and pull. Well, first let's talk about pull. I have a store here and stores change all the time. So your staging server may get stale. You maybe made it yesterday or even an hour ago. There's, there's new data in production. So we're going to do a pull and I'm going to do files incremental, which is going to get me any uploads that people have done. And under database, you can either do a full database pull, which would work fine. Mm-hmm. Or you can do selected tables. And this is super valuable because maybe you only want certain data. And so here they all are. So let's say, uh, there's new products in WooCommerce and I want to get those. So I need to find all the product tables. So I'm in Brave here, which is like Chrome. So I'm going to search for product_ and there are my, uh, product tables. and may surprise you to know that there are more than just, just one or two. So we're gonna go here and here and here and here and here. And then because I'm pulling the staging, I can safely do posts and postmeta. There we go. So now I'm going to pull data and it's going to get new files. And these, only these tables. Now it has initiated the pull and you can see how that's going. There, now it is pulled. It's done. So now my staging server has all new data. Now let's say that you make some changes to, uh, some tables on staging and you want to push them back. The same holds true. I'm not going to do it because it's exactly the same. But you can go to Database, Selected Tables, and choose. There you are. So let's cancel that because it really is exactly the same. So we don't need to do that. Now there are a couple of things I want to point out that might be a little confusing. Uh, when you make a, a temporary domain, so not a staging, uh, not a subdomain of your main one, then under Domain, you're going to see a link that says Go Live. That will not push your data to your live server. That will create a new live server, which you do not want. And so don't do that. If you want to replicate staging into production, copy everything, simply do a push and push all the files and all the tables, and that will get you what you want. Now, because I'm using a subdomain of my main domain, I don't have the go-live link. And so I don't, I'm not going to run into that. Uh, another gotcha. If you delete the main site, so this one, then the staging server goes with it. So don't assume that just because you have a staging server, you can delete production and keep staging. It doesn't work that way. Another thing that's good to point out is that staging servers are always set to noindex. So if we go to Settings, Reading, right here, discourage search engines from indexing the site. And that happens automatically because you don't necessarily want Google to crawl a staging server, a second version of your site, and you get dinged for duplicate content, things like that. Um, so always note that that's going to be on, or that's going to be checked. Another thing that's very, very important to remember is that when you push data from staging to production, then you're changing production, potentially overwriting things, especially database tables. So if you have a high-traffic site with lots of comments, members, um, sales, things like that, you almost certainly never want to do a straight push of everything. You should have a plan. You should think carefully. You should work to normalize data and things like that. I actually rarely myself push from staging to production, except for simple things like that, like that plugin update that we did. That, that was just a couple of files. That's totally fine. I'm more likely to test in staging and then manually do things in production that I just did because I know they'll work. And I'm not overwriting data. So, uh, my point is to have a plan. Think about what you're doing. These are very powerful tools and they can do wonderful things, but they can do terrible things if you're not careful. So think carefully about that. So I want to summarize real quick what we did. Uh, we had a main site right here. In fact, I'm going to open up that panel. And so here it is for Cybernate360 and for staging. Staging gets a managed staging link that lets you do pushes and pulls and things like that. And, uh, keep in mind that staging can get stale. And so you may want to pull data fairly regularly so that you're working with the latest material. And you should always use staging to test new stuff, test new plugins, test updates of plugins, test new themes. Test designs, test all kinds of stuff. Um, you can have multiple staging servers based off the same main server, based off the same main site. So, uh, maybe you want to test multiple designs. So you spin up 3 or 4 staging sites and you're all set. You can test on all of them. And then when you're done, just delete them. Uh, that's another thing. I don't recommend keeping them around unless you're using them. They're just taking up space. Spin one up, test stuff, delete it. You can do as many as you want, as often as you want, no harm at all. So you can just go right to town. Um, keep in mind that you can push and pull both fragments of data. So incremental files, individual tables, things like that. You don't— it's not an all or nothing thing. So you're going to be safe there. Um, it always does backups before you go. Yeah. So you can revert if you need to, if something terrible happens, which seems unlikely, but I've done terrible things by accident. I'm sure everyone else will as well. So remember to use staging servers. They're free. They're easy. They're quick. There's no reason not to. Thank you.
More from M

How to Deploy EmDash CMS in One Click on xCloud: A Fast, Lightweight WordPress Alternative

Self-Host OpenPanel in One Click on xCloud: A Privacy-Friendly Google Analytics Alternative

xCloud September 2026 Release Notes: Site Security Pro, AI Caching, Docker Backups & More | xCloud

xCloud August 2026 Recap: App-First Deployment, 250+ One-Click Apps & DeepSeek Harness Hosting

Deploy Vaultwarden Password Managed on xCloud (Self-Hosted Open Source Password Manager)





