On the Pineco.de blog there's a tutorial for the Laravel users out there showing how to set up subdomains in your application using the built-in framework functionality (and their setup with Valet/Forge).

Often we need to handle subdomains with our Laravel application. Let’s take a look, how can we treat the routes dynamically and set up the subdomain with Valet and Forge.

The tutorial then walks you through the steps to get subdomains working:

• Defining Subdomains in Our Routes
• Dynamically Generate Subdomains
• Faking Subdomains in Valet
• Setting Up Subdomains in Forge

Each section comes with a brief explanation and any code or configuration changes that would need to be made to make it all work.

Dries Vints has posted a step-by-step guide for the Laravel users out there showing how to set up Laravel Horizon using Forge and Envoyer for the server management. Laravel Horizon is a frontend/backend interface for Laravel that makes working with Redis easier.

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.

On the SitePoint PHP blog there's a new post that compares three deployment tools to help you manage your VPS servers: RunCloud vs Forge vs ServerPilot.

When your website or web application has outgrown your shared hosting account, it is time to move it to the cloud, or into a virtual private server (VPS). [...] However, I can recall when I wanted to move my website to Amazon Web Services a few years ago, and it took me days to deploy the server and get it ready with PHP, MySQL and Apache.

Fortunately, that is not the case today as we have the help of some cool tools and third party services. I took a look at three similar services – RunCloud, ServerPilot and Laravel Forge – and compared them to see which performs best.

The post then walks through each service showing how to set up an account and talking about the pros and cons. Screenshots are included showing the UI and the steps you'll need to set up servers and providers. The post ends with a look at performance tests on the resulting VPSes including information like time of request completion, response time and successful/failed transactions. These results show a clear leader as far as performance results - Laravel Forge - but there are some reminders that performance is only part of what you should consider when selecting a service.

On the Laravel News site they've posted a tutorial showing you how to create a CI process for deploying Laravel applications using the Codeship and Forge services.

Codeship empowers developers to efficiently test and deploy web applications with a basic command. Today, I want to demonstrate some of the platform’s features through testing and deploying a Laravel application.

They start the tutorial with some of the things you'll need to have set up prior to the process including a local instance of Docker, a DigitalOcean or AWS account and a Laravel Forge account. The tutorial then shows how to complete the process using this sample application:

• Setting up our Codeship project
• Setting up Laravel Forge
• Connecting Forge and Codeship

The article walks you through all the setup and configuration you'll need to get the process integrated and up and running quickly.

On the SitePoint PHP blog author Prosper Otemuyiwa shares what they call the ultimate guide to deploying PHP apps in the cloud with examples for Heroku, Google Cloud, IBM BlueMix, Microsoft Azure, Amazon Web Services and Laravel Forge.

There is a popular mantra amongst developers that goes like this write, test and deploy. In this tutorial, I’ll show you how to deploy your PHP apps to different cloud server platforms such as Google Cloud, Microsoft Azure, Heroku, IBM Bluemix, and others.

Cloud servers are basically virtual servers that run within a cloud computing environment. There are various benefits to hosting and deploying your applications in the cloud. [...] In fact, many companies have moved their infrastructure to the cloud in order to reduce cost and complexity. It’s a great option for small, mid-sized, and enterprise scale businesses. If you write a lot of tutorials and do POCs (Proof-of-concepts) like me, it’s also a great choice for you!

He starts off by covering the technologies that will be involved in each deploy: Linux, Apache, MySQL and of course PHP. Then, for each of the platforms previously mentioned, he goes through the setup and configuration of the same functionality. Most include screenshots of the UI in the service setting up the account and application. He also links to two tools that can make it easier to deploy your actual application to these newly configured cloud instances: Envoyer and Deployer.

On the Laravel News site there's a quick post showing you how you can use the Alfred tool to manage your Forge created servers. Alfred is a productivity tool for OSX systems that makes it easier to create shortcuts and interface with external applications in a convenient way.

Since the release of the Forge API developers have started creating a lot of apps and integrations, as well as an unofficial SDK. For those that use Alfred on the Mac, Vince Mitchell, launched a Workflow so you can quickly run many Forge commands right from your desktop.

The post includes the list of commands that the workflow includes allowing you to perform operations like opening the server's page in a browser, rebooting a system and restarting the web server on a specific machine. You can grab the workflow from the Packal site and drop it into your Alfred installation for immediate use.

On the Laravel News site there's an announcement about the release of an SDK for the Forge API to make it easier to use the Laravel Forge API to manage your sites and servers.

Laravel Forge announced it’s first official API back in February and we have seen a lot of interesting uses like the F-Bar Mac app. Today, Mohamed Said released a PHP SDK for the API that covers all the features.

The post includes an example of using the SDK to create a new server on your Forge account, providing settings like size, name, region and provider. The post also lists out some of the other methods available in the SDK including:

• revokeAccess
• rebootMysql
• installBlackfire
• installPapertrail

You can find out more about this SDK on its GitHub repository.

The Laravel News site has posted an official announcement about the Forge API being released for public use. Forge is a service that makes it easier to set up and configuration servers by taking care of a lot of the details for you.

Laravel Forge just announced it’s first official API that allows you to create and interact with your servers and sites.

This was a highly requested feature and the API includes support for all the features Forge provides including Servers, Services, Daemons, Firewall Rules, Sites, SSL, and more.

The post includes how to get started with the API, where to get your API token and how to send it over for authorization handling. You can find more information about the Forge API in the documentation on the Forge site.

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.

Freek Van der Herten has a post to his site showing you how to set up Varnish with a Laravel Forge server. Forge is a service that makes it simpler to set up and manage servers and the applications installed without having to mess with the details yourself.

For a project we’re working on at Spatie we’re expecting high traffic. That’s why we spent some time researching how to improve the request speed of a Laravel application and the amount of requests a single server can handle. There are many strategies and services you can use to speed up a site. In our specific project one of the things we settled on is Varnish. In this post I’d like to share how to set up Varnish on a Forge provisioned server.

He gives a high level overview of what Varnish is and what benefit it provides to your application (complete with illustrations) and includes a link to a presentation introducing Varnish to PHP developers. Then he moves on to installing Varnish on the server, updating the VCL configuration file and opening a port for you to use when connecting to the Varnish service. He shows the difference in the response headers when Varnish handles the response and the updates you'll need to make to get your Laravel application to play nicely with Varnish with this package.

He ends the post with examples of how to test the performance difference and some final steps to update the config and have it run on port 80 instead of the default 6081.