I recently installed Horizon for Laravel.io and while it wasn’t that hard to install, I still had to figure some things out. Since this was the first time setting everything up I thought I’d write up the steps to take to get started with Horizon and set everything up with Forge and Envoyer.

[...] Remember that this isn’t a guide that dives deep into Horizon, just enough to get it up and running. If you want more info about Horizon’s internals I suggest this excellent post by Mohamed Said.

The tutorial then walks through the six step process to get the full deployment flow set up:

Step 1: Installation

Step 2: Configuration

Step 3: Scheduler

Step 4: Authentication

Step 5: Envoyer

Step 6: Forge

When the setup and configuration is complete the deployment you'll end up with a Horizon environment ready to use. The post ends with a reminder for queue management and where to change the setting to be applied in the next deploy.

The Cloudways blog has a new tutorial posted showing you how to speed up your deployment using Envoyer, a service from the Laravel ecosystem that's used to push code to an environment in an automated way.

Envoyer is a deployment tool used to deploy PHP applications. The best thing about the the tool is the zero downtime during deployment. This means that your application and the customers using it are not even aware of the fact that a new version has been pushed.

Envoyer works well with major repository management platforms such as GitLab and Bitbucket. Other benefits include unlimited deployments and team members. The following blog will guide you through the process of deploying applications on Cloudways using Envoyer.

The tutorial then walks you through creating an Envoyer account, connect it to a repository and set up the server to deploy the code to. They then show how to set up the deployment itself, make the push to the server and configure any post-deployment steps that may need to be performed. Screenshots are included in each step of the process so you can be sure you're on the right path.

Test automation, continuous integration, and continuous delivery are quite widespread in the community now. This brought to life multiple services trying to make the process more enjoyable and less overwhelming for developers, so they can focus on delivering software instead of building/configuring tools to do that. One of those services is SemaphoreCI.

In this article, we’re going to cover how to use our own deploy scripts and tools to continue the deployment process after a successful test.

They then show you how to create the Deployer configuration file to make the deployment to the remote Digital Ocean servers of a Laravel-based application. Most of the steps are in copying the local files up to the remote server as a "staging" environment. He then hops back over to the SemaphoreCI service to create the deployment plan for the project using the "deployer.phar" command line tool, linking it to the push of new code. They then move to the same process just defined via the Laravel Envoyer tool and a similar command line call.

Matt Stauffer has a post to his site today sharing a step-by-step guide to setting up your Laravel application for zero downtime deploys when using the Envoyer/Capistrano combination.

The reason you're getting zero-downtime deploy from these tools is because the entire deploy process—clone, composer install, etc.—doesn't happen in the directory that is currently serving your site. Instead, each new release gets its own separate "release" directory, all while your site is still being served from its current "release" directory.

All of these release directories are just subdirectories of releases. Each directory here represents one of your deploys, and each directory individually has everything needed to serve your site. [...] So, once the build process is complete for each new release, your deploy tool will delete the current symlink and create a new current symlink that points to your latest release. Boom. Now that release is live.

He then relates this back to the deployment of a Laravel application with Envoyer which already follows this "symlink deploy" method. There's a few caveats he mentions with this deploy, however, including information that shouldn't be removed in each deploy (like caches or configuration files). He then provides the steps (commands) you can follow with the deploy to manually use the "symlink deploy" method in your own scripting.

On the DotDev.co blog today there's a post from Jordon Brill showing you how to manage custom VMs with Laravel Forge. In his particular setup, the VMs he was working with weren't ones created by Forge so he needed to do some custom work to integrate the two.

I had a legacy php application that I wanted to move to a newer version of php. This application is not built on Laravel but rather is a conglomerate of a bunch of different php scripts and pieces of different frameworks. We recently deployed a Laravel-based application to a server running on AWS via Laravel Forge and Laravel Envoyer and fell in love with the service. We were completely up and running in about 10 minutes and it was great.

This case, however, was a bit outside of the typical scenario since it was not a Laravel application and Forge wasn’t going to be creating the server on one of the built-in services that Forge has an integration with (Linode, DigitalOcean, and AWS).

He starts by creating a new VM instance of a Ubuntu-based Linux system. He then shows how to connect it up to Laravel Forge via the "Custom VPS" option. This provides you with a custom command and token to use to make the connection to manage the server via Forge from then on. He does point out a few "gotchas": that it all needs to be run as the "root" account and that you'll need to open SSH ports in your firewall (if you have one) to allow the Forge service access.

The Product & Support site has posted an interview with Taylor Otwell, the creator of the Laravel framework. In it they talk about what Laravel is, how it treats users as "customers" and the community around it.

Taylor is the creator of Laravel, founder of Laravel Forge and founder of Envoyer . I spoke with him about open source software and making the transition to entrepreneurship.

Taylor also answers questions about the ecosystem around the framework (marketing, documentation, etc) and how its helped the popularity of the framework. He also shares a few things he might have changed if he could start over with Laravel, including features he feels are "overdone". They also talk about Taylor's move from a full-time job into being self-employed and how that works with two large open source projects to maintain. Check out the full interview for the answers to these and other questions.

The Full Stack Radio podcast has released their latest episode: Episode #14, "Taylor Otwell - Building Envoyer, Laravel 5.1 and Learning to Program". In this new show host Adam Wathan is joined by Laravel creator and lead developer Taylor Otwell to talk about the framework, the Envoyer deployment tool and development in general.

In this episode, Adam talks to Taylor Otwell, creator of Laravel. Taylor gives an in-depth behind-the-scenes look at how Envoyer is architected, and shares some new tips and tricks he's been using to keep his code simple. They also talk about the decisions behind upcoming changes in Laravel 5.1, how Taylor learned to program, and how he almost became the manager of a retirement home.

Matt Stauffer has taken the reins and is the host and Shawn has switched to a new podcast outside of just Laravel. The podcast is also moving to a shorter format, 20 minutes and is scheduled for every other week. With the shorter format, it forces the discussion to move quicker and is much easier to consume. For me at least.

The first episode with Matt at the helm talks about the recently released Envyoer deployment tool and the latest version of Laravel (v5). You can listen to this latest episode either through the in-page audio player or by downloading the mp3.