Solution to maintain a web app (PHP) deployed in different droplets

Posted June 10, 2019 3.8k views


I’m developing a PHP web app that, because of business model reasons, we’re thinking to initially deploy it to each customer along with an own virtual machine (droplet).

Haven’t used docker or kubernetes before, but I understand it could help with this, but before I dig deeper into that I would like to know if it’s indeed the right path to follow.

After the app is deployed, we’ll be doing updates to the app, so we’re seeking to just “push them” to each customer’s droplet with ease.

I would like to ask the community for opinions on this and, if possible, a rough list of steps to follow.

Many thanks

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
2 answers

Hi there,

A few clarifying questions about the service you are providing that may help guiding your decision.

Does your frontend scale well to many instances?
If applicable, can your backend scale well to many instances?
Is your application tightly coupled to any other services?
Can you application easily be broken down into logical components?
Are you having issues with your current design right now?

Other things to consider to get an idea of what the application may look like:
Does the webapp frontend have differences per client?
Do the updates you’re pushing go out to each client or sometimes only to a few?
Do you need storage for some sort of backend? Do the clients each need separate backends or can they share a single one?

While kubernetes and containerization can be beneficial in a lot of ways, sometimes for very simple use cases it could certainly be unnecessary legwork to containerize applications and learn kubernetes and surrounding technologies for little actual benefit.

That being said containerization does help in easing the deployment and portability of the application in question(in most cases).

It may largely come down to what your biggest priorities for this application are, that may steer you in one direction or the other.


John Kwiatkoski
Senior Developer Support Engineer

  • Hi John,

    Thanks for your replay.

    The front and back end will reside in each customer’s virtual machine.

    Consider the WordPress scenario mixed with a SaaS business model. Every customer will have its own installation, but instead of the customer pulling updates and deal with the whole administration. We’ll take care of everything by pushing updates to the front and back end ( “rolling releases” instead of “versions”).

    Our focus is to keep one version only (like a SaaS). However, I understand that in the long run we may be forced to pivot and allow/process customer’s customization requests. But we’ll try to avoid this as much as possible.

    Hopefully this clarifies most of your questions.

    Thanks again.

    • Thanks for clarifying. Unfortunately I really don’t know the ins and outs, or challenges of managing that sort of SaaS delivery model so I wouldn’t be able to definitively tell you which route is best or the specific pros and cons of each.

      However, I will say that maybe starting a very simple proof of concept that works similar to your app would be beneficial. This way you could try out what it would be like to go through maintenance and update pipelines for each version of the app the strengths and weaknesses of those would start to become more clear.


      John Kwiatkoski
      Senior Developer Support Engineer

      • Thanks John. Leaving aside the management aspect, what technologies would you recommend for mass deployment/updates to different virtual machines?

        Do you know if kubernetes/docker could fill the void? Is there any other smilar/better/easier?

        We will be pushing code updates (plain files) and database changes. Basically what we need to automate is the deployment to all virtual machines in “one move”.

        Thanks again.

        • If goin the containerized route kubernetes is nice for orchaestration. You also don’t need to use docker, there are other container technology that you could use. RKT and CRIO as well as specific CRI compliant tools like podman and buildah come to mind.

          If going the VM route, I would recommend using a config management/automation tools to ensure your changes/updates are done properly and in a repeatable fashion. I personally really like Ansible and have used it a lot in the past but have heard good things about Chef, and Puppet.


          John Kwiatkoski
          Senior Developer Support Engineer