Title: WordPress DevOps – Environments Last modified: May 29, 2018 --- # WordPress DevOps – Environments * [Jahanzaib](https://wordpress.org/support/users/jahanzaibasharat/) * (@jahanzaibasharat) * [8 years ago](https://wordpress.org/support/topic/wordpress-devops-environments/) * Hi everyone, * in my company we are trying to use WordPress on Docker. Our target is to give a “staging” envrionment where users/editors can make changes, update plugins/ themes, write pages/articles, etc…. * We want to make a “snapshot” of the version on the staging and deploy it to the production environment, where we want to disable the wp-admin area (security reasons). * This might me doable but we are facing a problem related to the plugin management. On staging and production the database can be quite different and we all know that WP saves absolute paths so we also have to do a replacement for the domain. * The issue is that the settings of the plugins might reside in different tables as not every plugin saves stuff in wp_option. So the problem is to understand how to pick only the changes made to plugins on staging and deploy to production without taking all the DB. * Is there any experience on this scenario available in the community? Has anybody tried to have multiple environments with Worpdress on Docker? We are using Rancher for the orchestration. Viewing 3 replies - 1 through 3 (of 3 total) * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [8 years ago](https://wordpress.org/support/topic/wordpress-devops-environments/#post-10337219) * I’m unfamiliar with Docker beyond knowing what it is. But maybe my experience will inspire you to find a similar solution within Docker. I often develop on localhost. To avoid needing to change all the URLs in the DB when exporting to the target host’s server, I place the target domain in my local hosts file. Thus as far as WP is concerned, it is on that domain already and all the URLs are correct. The only drawback is I cannot access the domain’s real site except by IP address. * I would hope Docker has some sort of similar mechanism for domain alias that you can use. In cases where URLs still must be altered in the DB when moving sites, I rely on interconnect/it’s [Search and Replace](https://interconnectit.com/products/search-and-replace-for-wordpress-databases/) tool. You are right, there’s no telling where various modules will place URL’s. This tool is pretty good at finding them all. The one time it failed was for a theme that stored URLs that were base64 encoded! Why they did this I cannot even imagine. * I do have several WP installations on localhost. My public root .htaccess file redirects traffic to the proper subfolder based on the requested domain alias. It’s not been a problem at all. The subfolder appears to be the domain’s public root. * I hope this gives you some ideas on what to do with Docker. * Thread Starter [Jahanzaib](https://wordpress.org/support/users/jahanzaibasharat/) * (@jahanzaibasharat) * [7 years, 12 months ago](https://wordpress.org/support/topic/wordpress-devops-environments/#post-10365142) * Thanks for the feedback. Your solutions covers the URL part of the problem but i need to tackle the environments (dev, staging, prod). In this context i am looking for advices, experiences… * [JointByte](https://wordpress.org/support/users/jointbyte/) * (@jointbyte) * [7 years, 12 months ago](https://wordpress.org/support/topic/wordpress-devops-environments/#post-10366680) * May I strongly recommend you stay away from any sort of flow (ie: Docker) that means there is a significant gap of time between a plugin being updated by a vendor and it being applied to your website. Especially in production, considering how important security patches can be. * Data is stored in all sorts of ways (as you noted above with the options table, there are many others to name too!) * If your goal is to deploy from your development environment to staging, or move from staging to production, then you are free to follow which ever process makes the most sense to you. That being said, my team tends to do the following when creating WordPress-based solutions: – We create our dev, staging, and prod environments from a blank WordPress installation. – We always keep plugins up to date using the autoupdater built-in to WordPress. The moment we notice a plugin can be updated, we go for it. – We install custom plugins with FTP and any time one of our developers performs an update, they are responsible for updating staging first then updating production once they have tested their changes. – For importing and exporting data, we tend to use built-in practices: [https://codex.wordpress.org/Tools_Export_Screen](https://codex.wordpress.org/Tools_Export_Screen)– For the above (importing/exporting data), as long as your developers are using the WordPress API properly you should be fine. If your developers are creating tables un-necessarily for things like custom post types, you might want to shake your finger at them for making your job much harder. – If we need to modify a plugin that is not our own, we use WordPatch to make a patch and call it a day. Every time WordPress updates one or more plugins, the patch is re-applied and we don’t have to worry about losing our changes. * Hopefully this helps. Viewing 3 replies - 1 through 3 (of 3 total) The topic ‘WordPress DevOps – Environments’ is closed to new replies. ## Tags * [deployment](https://wordpress.org/support/topic-tag/deployment/) * [docker](https://wordpress.org/support/topic-tag/docker/) * In: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/) * 3 replies * 3 participants * Last reply from: [JointByte](https://wordpress.org/support/users/jointbyte/) * Last activity: [7 years, 12 months ago](https://wordpress.org/support/topic/wordpress-devops-environments/#post-10366680) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics