I dont get the difference between forge and envoyer :)

@hostianer

With forge you can easily create server for Laravel, and manage these servers.
With Envoyer you can easily deploy your application on multiple server without downtime.

@RomainLanz So it`s more for a "cluster" ?

What do you mean by "a cluster"?

@hostianer

Forge is for the initial provisioning of the server

Envoyer is for deployment

@hostianer you use Forge to get all the latest goodies running on the server, such as latest PHP version, Redis, HHVM, etc.

You'd use Envoyer to deploy your code to a server using Github, with zero downtime. It can be the same server you've built with Forge but doesn't have to. Yeah, you have "push to deploy" on Forge too, but there are some extra features on Envoyer, such as deploy with zero downtime, heartbeats, health checks, deployment hooks etc.

What got me most thinking is how zero downtime actually works, and it's really great. You can see it in action in the Envoyer series.

@toniperic Document root points to symlink, symlnik points to current files, changing the symlink will update the path to the files.

Furthermore, "zero downtime" is possible because you do all the work (composer install, asset building, whatever else) outside of your live app. Switching the symlink is an instant process once everything is ready to go and it makes rolling back super simple.

Envoyer looks fantastic and is something I'd love to use!

The downside - although only $10 (which isn't much)... all of these $10 add up for the small guy.

So we've got ~$10 for Digital Ocean, another $10 for Forge and another $10 for Envoyer, not forgetting your $9 for Laracasts :) and anything else you might want to add. Things are starting to mount up already.

Now there's some overlap between Forge and Digital Ocean regarding the provisioning - and further overlap between Envoyer and Forge regarding deployment.

Personally I'd forego Forge and use Envoyer instead, since provisioning is kinda one-off and the only major attraction of Forge after that would be "Push to Deploy" (for me anyways), which Envoyer handles better.

What I'd like to see is Forge and Envoyer bundled at a cheaper price, (or even combined as another product). That way I'd be much more inclined to stick with Forge as well.

Just my thoughts for what they're worth :)

Today I learned how zero downtime deployment is done. Cool symlink trick. :)

@pmall Or a simple changing of the document root :p it's really not that magic. Been doing it for years! fideloper also provides the same script for free with a screencast to explain it.

@bashy @deringer exactly - it does everything "outside" of the live app, and once it's all ready just changes the symlink.

Pretty much the same as if you had the different/newer version of your app that the live in a different folder, and once it's all ready and working just change the document root to point to it.

@radbonev Yes, images and the like. Large assets like that have no purpose in a repo since they're very large, rarely change, etc. Also, yes, I know I can make the symlink manually, but part of the point of Envoyer is automating these tasks. I could just as easily symlink the storage directory too, but that's done for me. Also, full CDN setups are complete overkill for even medium sized websites. nginx is extremely efficient at serving those files, and CloudFlare does a great job of acting as a CDN middle-man anyway.

So Envoyer would really benefit a really large group of people not using a CDN for their images/etc if it handled this situation.

@olimorris I don't use Forge, and no, I am talking assets, not source code. Not CSS and the like, but images, fonts, other binary data that is rarely, if ever modified. Even GitHub themselves suggest you do not store these things unless you have a very specific need for it.

@coolmatty - well, we should probably stick to the right terminology :)

However, I don't think that Envoyer.io should take care of those files, but in case you have to - you can achieve great results with 2 lines of bash code. I think that the default settings will get you up an running pretty fast, I don't see any reason why would we change that.

I would argue that any CSS, JavaScript, or image assets that are needed to deploy your website (whether it be for another dev to work on, to staging, production, etc.) should be in your version control. If you're using a pre-processor for CSS or JS, you'd probably only commit the source files and build the compiled assets on deploy.

As far as CDN for storing content from userland (gallery images, profile pictures, etc.), putting them in the storage path is what the storage path is for. Serving from there means you don't have to worry about those items disappearing between deploys. To suggest that a CDN is useful only for a large scale websites is to assume that their only benefit is in edge serving is simplistic.

Sure, nginx does very well at serving that content - it's what it was built for - however, using a CDN has the greater benefit of not bogging your web server down processing, storing, and serving images. CDN gives you way more storage, way faster delivery of assets and cheaper bandwidth to serve that content.

@radbonev is right, though - it's only a couple of lines of code - I've been symlinking user content outside of public for WordPress sites for years.

If you're comfortable setting up a server yourself, you could forgo Forge and stick with Envoyer to simplify the deployment aspect. If you're comfortable with deployment but want the simplicity of provisioning flip the equation. If you're client is paying for it - charge them and use both.

End of the day, nothing stopping you from using Forge + dploy.io or even just vanilla Envoy (super easy to replicate 90% of Envoyer). What Envoyer providers is a centralised, managed solution for deployment. If I need to deploy when I'm away from my main development machine, I can just login to Envoyer, without the need for SSH keys or being on the right side of the production server's firewall.

I like it and will be committing to both Forge and Envoy (and charging my clients for the hosting, of course!)

For anyone looking for a v. basic alternative using the Envoy tool, we just created one - see https://laracasts.com/discuss/channels/general-discussion/envoyer-inspired-envoy-script

@davidrushton great script man thanks !

Just a question : I like to keep a passphrase to unlock my ssh key on my server (unlocking the key to pull from git repo). I don't mind about typing it everytime. However envoy doesn't show the prompt for me to type the password and throw an error. How can I workaround this ?

Thanks @pmall.

I don't think Envoy can prompt for things like key passphrases, but you might find some luck using https://help.github.com/articles/working-with-ssh-key-passphrases/#but-i-dont-want-to-enter-a-long-passphrase-every-time-i-use-the-key ssh-agent if you don't want to remove the passphrase.

@davidrushton I knew this but for some reason I never got ssh-agent to work on my distant server. It is installed, running, everything, but it keeps asking for my passphrase everytime.

@pmall - I'm afraid I don't have much experience with ssh-agent, but this might help: https://developer.github.com/guides/using-ssh-agent-forwarding/

At $10 / month, if it saves at least 1 hr of work a year, it's worth it to me. After setting up a couple sites, I really like it overall but also have a few observations:

1. Redeploying an old release only works if you didn't do any migrations after that release.

2. If your release involves migrations, it may not be quite zero-down time. Not sure if there is any way around that but there will be a very short period of time where your database is not in sync with your app. Still much better than the alternative.

3. If would be nice if you could 'rollback' a release, which would let you run a custom script like php artisan migrate:rollback. I say custom because our rollback process involves copying some files and doing some other cleanup beyond the standard rollback command.

It would be awesome if Forge & Envoyer were merged together into a single integrated management & deploy tool sometime in the future :).