Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I just had a crisis with an app in production. I am sharing it in case it can help someone avoid a similar situation and to see if someone has a bright idea on how to deal with it.
Short summary of the setup:
So far everything has been working fine. But today the server crashed and EB tried to create a new instance. And one of the packages that my app relies on had removed the branch I was using. Therefore the build process failed and my app was nowhere to be found!!
So I realized that I cannot rely on publicly hosted packages to build my production app whenever is needed, as they may not be available. EB makes it so easy to deploy a version from your git repo that I didn't put too much thought into what could go wrong.
I haven't decided yet what my approach will be. Right now I am leaning towards building a zip file with all the necessary source files once I have tested a version. That way I don't depend on 3rd parties. Any bright ideas that I haven't thought of?
Therefore Laravel Envoyer would be a good choice.
Because before your app is deployed Envoyer checks if everything is fine. If not ( like you case ) you will get an error message, but your current site is still online. Thats why Envoyer is called "zero downtime deployment".
I always use packages and proceed with the idea that a branch will go BUT! I've actually run across package take-downs! Talk about WTF situation.
Anyway, composer lock is part of the protection against this. Also, doing like you wrote but having a vendor.zip ready to go would be an easy method to forward protect your application.
I normally fork the projects that I use so that IF I have to I could roll my own package. I do like upgrading and using that as chance to refactor, rewrite and write better code. However, I totally can understand that a production app shouldn't be upgraded for the fun of it.
@christopher The setup I described is also "zero downtime deployment". When I deploy a new version EB gives you the same control: if it fails, it maintains the old version.
The problem is when a new server is created, either because you need more power or because the original server crashed. I don't know Laravel Envoyer in depth, but if the original server is down for whatever reason, keeping it doesn't solve the problem... :-(
Thanks @andy, forking the projects I use was the first idea that came to mind. But I think that updating them from time to time could be more painful than creating a zip file with the vendor files every time I upload a new version.
Sometimes, old methods and techniques are still useful ;-) Like I said, the vendor.lock file combined with a vendor.zip file should be a good way to make sure that your production app is stable.
@otepas That's definitely a real concern. There's a few things to be done:
I all situations, I like the idea of a central build server which can get kicked off from github web hooks. (Shameless plug: That's what deploy.serversforhackers.com builds up to in the video series).
Hope that's useful!
Which is why the staging method is used?
@fideloper your serversforhackers link is being swallowed ;-) (great site btw!)
Thanks @fideloper. I think I will go for option 1 in the near future but I like the idea of a central build server.
Please or to participate in this conversation.