Sessions is temporarily moving to YouTube, check out all our new videos here.

Deploying Your Laravel Application

Neo Ighodaro speaking at Laravel Nigeria in April, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

In this talk, we are going to look at deployment strategies and techniques available to you once you are done creating your beautiful application.


Neo: I'm gonna go straight into what I'm gonna be talking about today. I'm talking about deploying your Laravel application. What we are going to do in this topic is see methods in which you can deploy your beautiful application, I have created, using Laravel. Before I go, I'll introduce myself, I'm Neo. I'm the CTO at I'm also founder of CreativityKills. I do guest writing at Pusher and Scotch. In this particular presentation, we are going to cover things like choosing your application server, server deployment options, we talk about shared hosts, how you can deploy your Laravel application on a shared hosting system, cloud VPS like Digital Ocean and Linode. We're gonna talk about how you can deploy your application on a PaaS service like Heroku and Pagodabox or Fortrabbit. We're also gonna talk about automatic deployment using Jenkins, and finally we'll talk about how you can handle things like Queue and Workers when you are working with your Laravel application, on your host. Choosing your application server. There are a few things you need to consider when you are choosing your server. So you've used you application, and your application looks nice, and it works locally, but now you need to take it live. So what do you need to consider? First, you need to think about your product, the thing you are working on, the nature of your application. What does the application do? Is it a personal blog, what is it exactly? You need to think about the potential size of the application. You also need to think about the features that your application needs for it to run properly. You need to think about the flexibility of the server, because it or not, when you application wants to go viral, it doesn't warn you, it just goes viral, and then at that point you start to wonder, okay, how can I quickly migrate? That's not when you should wonder, you should wonder before you even migrate. Then you need to think about price. I mean, price is also very important. If your creating a small application, a very simple application, usually it doesn't matter where you deploy yourself. If I'm creating my personal blog, I don't expect, like massive traffic. I expect just a few people, who just wonder, like when they are lost, and they just get on the blog. So I don't need so much stuff. I only need my normal eloquent models and I need my SQL database, or whatever database engine I'm using. I just need my application code. I don't need ORMs normally, I'll deploy it anyway, it doesn't really matter actually. But if you're using a bigger structure, so let's say something like it's really, really, really massive and you can't just deploy it everywhere. You have to be very careful where you deploy it. So you have things like workers running in the background, we have a proxy, we have cache managers, we have application, we have a lot of stuff. You can't just take that and dump it in one shared hosting and hope to be fine, it won't work, it will break down. Complex architecture actually requires more capable servers. You also need to think about features that can get out of hand. If you've worked with clients, I believe some of you have done freelance work, you've worked with people and they give you a specification of your product, and all of this sort of thing, it starts spiralling out of control. Initially they said it wanted to be able to log in, use a password. The next thing, they're telling you they want Facebook log in, the next thing, they tell you they want LinkedIn log in. It just keeps spiralling and spiralling. You need to consider that free migration, before you start moving. You need to think of, can my feature really expand to a level where this server can not handle it, or can my feature ever get to a point where, if I put it on this server, I'm going to be in trouble later. Then, flexibility. If you're choosing your server, you want flexibility, so I will talk about something like a service like Conga for instance. Conga receives little traffic throughout maybe January, February, but once it gets in towards the 'ember months, people invest a lot into devices and stuff, and then your traffic really skyrockets. They need to have a server that is flexible enough to scale up when you need to. September, October, November, December, they need to scale up their resources to be able to handle the amount of traffic that is jamming them. So the server has to be flexible enough to handle that kind of brute force. So, what are your server deployment options? The first one is shared hosting. I've talked about shared hosting before. The next one is cloud VPS, then the platform as a service. So let me talk about the shared hosting. Shared hosting is basically web hosting in which the service provider serves pages for multiple websites, each one having its own internet domain from a single server. What this means, basically is, there's one server, and then, they basically just give you folders inside that one server, and then build your application. The problem with that is, each machine or each server has limitations. If all of us here have shared accounts on one particular server, you are going to run out of resources at some point. You need to know what you are getting into when you are using a shared hosting system. Let's just say you want to use a shared hosting platform, because I know there are some that are very, very cheap. For instance, Smartweb, or one of them, you can actually get 5000 for a year, for an entire year, so it's extremely cheap if you decided, I want to go with a shared hosting platform, which by all means you can deploy because by default, I don't think they give you SSH access, they just give you FTP. You're supposed to log in with your FTP details, and get like a folder list and they now start transferring files one by one, one by one. If you've ever used Laravel composer, you know that is a headache. You can't even update your packages at the end of the day, it becomes a nightmare. How can you get past this particular hurdle? Initially, when I started working with Laravel, I really didn't have enough money to get all these big hosts, so I used a shared host. I know there are cases where you actually have to use them. The way I got through it was something called FTPloy. What it does is, it allows you to deploy your Laravel application, any application actually, when you push. The application, FTPloy basically stands in between where you push, so you push your code to GitHub, FTPloy picks it and makes the changes on the server. So you don't have to do all those, go in here and drag and drop, I change this file, I change this file. You basically just push the GitHub, that's all you do. Push the GitHub, FTPloy picks it up and makes the changes on your server. That is actually very cool. It actually take a little wait and see, in which you have to start uploading files because, trust me, it is really, really difficult. The last service that does this is Beanstalk. I discovered this one after using FTPloy for a while. Beanstalk does exactly the same thing, it just makes you focus on deploying your code. Let's say you have your code on somewhere like GitLab or GitHub or Bitbucket, Beanstalk just stays somewhere right there, and when you push your code there, it picks up whatever changes you've made and pushes it to the server. The good part about it is, it works exactly the same way Git works. It only picks the changes, it doesn't pick every single thing, it just picks whatever changes you've made. You can go ahead and update your composer files, commit it to the repo and then push to the repo and your Laravel application or whatever application in fact, will pick it up. So that's about shared hosts. Shared hosting has its ups. Its ups is it's cheap, its down is it's very, very difficult to work past and it's not ideal for any application that is going into the hands of everybody. Cloud VPS is basically VPS in the cloud. It's better than shared hosting, but it requires some knowledge of operating systems and how they work. Has anybody ever used DigitalOcean? Wow, we are very few. If you are using a DigitalOcean droplet, what they give you is only your SSH login, that's all, and they give you route access to the server. What they do is, they create a virtual server for you. You own it, you're not sharing resources with anybody. You basically own that small piece of machine. But they don't do anything else, they don't give you CPAN, or they won't give you nothing. So you have to have some sort of knowledge of maybe like, Linux systems like Ubuntu or Centaur, depending on whatever you're working with. That is a disadvantage, but the advantage is it gives you power to control whatever you're doing. You can do whatever you want on your server, it's yours, they give you route access. Some people that provide these services are DigitalOcean like I said before. They are pretty popular and a lot of big services use them. I think LinkedIn does use them, or something. So they are pretty popular and they are stable enough, and they have some really, really great features like they can allow you create a floating IP. What a floating IP is, every serves has an IP address, so there is a floating IP and then you can create other droplets. So let's say you create a floating IP, which would be the IP for your server, and then you create five droplets which have exactly the same code base, you can now link all the five to that one floating IP, so that you have latency in your code ... Sorry for this ... So you have latency in your code, and if one of the droplets goes down, it automatically reroutes to the other one. So you basically have a very, very scalable system where there is a lot of points for drop-offs, but it doesn't reflect towards the user. They have really, really cool stuff. You also have Linode. Now Linode is almost the same as DigitalOcean, with a few differences. Linode is a bit brute, they don't really care about your user experience when you are using their site. DigitalOcean gives you places where you can create droplets, and all this stuff, Linode doesn't care, it just gives you the machine, knock yourself out. They are a bit brute, but I prefer them because they have better resources and their server uptime is really, really high. But they do exactly the same thing DigitalOcean does. Platform as a service. This is by far the easiest was to deploy any of your Laravel applications, the easiest way. Platform as a service often simply referred to as PaaS, is a category of cloud computing that provides a platform and environment to allow developers build their services over the internet. What this basically means is, there telling you, don't worry, you don't need to care about your server route and all this stuff, we will do all that for you, we are just giving you a platform as a service, we are giving you PHP as a service, we are giving you [inaudible 00:11:44] as a service. All you are using is that particular service, that they have provided you as a platform. People like Heroku for instance, gives you different build options, so they have build options for Apache, they have build options for just engine excel vazelin, they have build options for PHP and so on, and so forth, ruby and the rest. They just give you that platform and then they give you ... They have a prog file, that's what they call it, where you can basically tell the application what you need it to do, to build successfully. Platform as a service really, really makes everything simple, because you just push and then it builds. You really don't do anything server related. You don't need to know anything about Linux. As you can see here, you just straight to building your apps. You basically cover all the complexities that you might have, are taken care of before. Now the downside to it is, you'd never get to know these things, that's a bad thing in my experience. If you're using Heroku, if you already know how to do Linux systems, it's fine, but if you don't know, you'll get very comforted by ... I think that's the way life is out there. If you go working for maybe a big firm, you'd find out that they're probably not using that, they're probably using their own stack and then you'd get lost very quickly. It's usually good to use platform as a service, but not until you know how it actually works. If you are using Heroku and you are deploying a PHP application, I am just saying it is wow, magic, cool. But it's actually better if you know what exactly goes into the process. How does PHP even handle the stuff? PHP doesn't show web pages, PHP just handles it and passes it onto the web browser. You need to know the actual flow and process. How does it get here? What's viewed in ... Why ... And that can give you a better understanding of how platforms as a service works. Let's talk about autodeployment suite, Jenkins. I'm sure everybody here has heard of continuous integration. It's one of those trendy words that has been thrown around, up and down, and it sounds like a big word. Basically, continuous integration is a development practise that requires developers to integrate code into a shared repository, several times a day. Each check-in is verified by an automated build, allowing teams to detect problems early. Let me just break that long thing down. Basically, continuous integration is just, I push my code, somebody picks it up automatically, does a bunch of stuff, and then deploys it live. That's what all this junk is about. How can continuous integration really help you? Think about your normal workflow process, imagine you have an application online, right now. You are actually hosted on a VPS, for instance, a server that is given to you, with just routes. You make your changes through GitHub, for instance and when you push that change to GitHub, nothing happens. Usually, what you do, what people do without continuous integration is login to the server and then pull. Pull the changes. Or if you are doing a git flow system, where you use versioning, you check out of that branch and then you know, I've committed the last one, but that's a lot of work. Plus, you can't even test what you did, except you have a staging server and you have to run your commands manually, all these unit tests and everything. So continuous integration basically takes that entire workflow and automates it. This is you pushing your code to GitHub, like Jenkins, which does continuous integration, picks it up and then runs a bunch of commands, so let's say you have a pipeline, and you say okay, when I push my code, check first. If I'm pushing to dev, follow this pipeline, run my tests - if it fails, stop and report to me. Don't push it to the live code. Or if I push to master, just make a dev version, test it there, run whatever you need to run to make sure that particular branch or that particular piece of code you just pushed, you didn't break anything. If it works perfectly, then go back to master and then deploy it online. That's literally what continuous integration is. It's nothing too complicated. I'd like you guys to meet Jenkins. We use Jenkins at to deploy most of our microservices, nothing too complicated, we just make sure it does automatic deploy. That's pretty much what we use it for, then a little bit of testing, but mostly for the automatic deployment. Jenkins is an open source automation server, written in Java. You don't need to buy it. It's actually free. You can instal it in any open source system, you can even instal it on your machine if you like. Like I explained before, this is the process which Jenkins goes through when the continuous integration process, you push your code to a Git server, Jenkins automatically pulls the server every x minutes to check if there's any change, and if it sees a change, picks it up and then runs whatever command you have given it to run and then pushes it down to your web server, and you've just done nothing but push a code. It basically lets your workflow seamless and almost instant, every time you make changes on a code basis, almost like, enter and then you go onto something else because you know your code has entered. Or you didn't enter because it tells you, okay something broke, I'm not pushing this code, something broke. Laravel queues and workers. This is a very distant part of Laravel that a lot of people do not use. But I'll give you a use case of why queues are very important. First, let me define what queues are. Queues allow you to defer process, the time consuming process such as sending an email, until a later time. Deferring this time consuming task, drastically speeds up your application, ans makes requests almost instant. I'll give you the example of sending an email for instance. If you've ever viewed an application where you use a register, sometimes [inaudible 00:18:08] message, yeah. How it usually looks in the code is maybe registration controller and down registration and then maybe that part just sends the welcome image, welcome message instantly. The problem with that is, if you are using a third party system for instance, like SendGrid and it just happens to be a little bit down or latent at that particular point in time, the application will just stay. And then maybe at some point, it will time out. The user will not even get his email, and the user will not see anything. He will just be there, looking at a blank screen, which is actually bad. What queues does is, it takes your ... You've got until the point where you are supposed to send the email, all it does is just queue that process. It keeps it and then continues executing. Instead of sending the email instantly, really the user doesn't need to get it instantly if you think about it. He can wait for five, ten, twenty seconds, he'll be fine. Even one minute. It just queues the process and then executes to the end. So the user sees welcome to Laravel Nigeria blah blah blah. Moving on. Then later, the worker goes and checks the queue process, is anything queued? Yeah, there's an email that was supposed to be sent, it takes it and it sends the email in the background. It has nothing to do with your user, your user just seamlessly walks through your application. Another example could be maybe, you have a podcast like this Mince podcast they've been doing recently. If they wanted to give their site ... As somebody uploads, or they allow community uploads, and then someone uploads a podcast, and you have to do some sort of processing, maybe to make the mp3 file smaller, you can't do it immediately, you can't just run it. It would take a very long time, especially if it's a big mp3 file, so you have to a queue a process like that to the background, and then the user that okay your mp3 is ready, we'll message you when it's done. So that queue process goes there and looks at all the queued up stuff and then it takes it and it processes it. When it's done, you can send an email. In Laravel, to dispatch a queue, you basically run an artisan command with make job, and you create a job, something like process podcast, and then in your code somewhere, where you need to actually do that stuff that you needed to do, maybe you only needed to process the podcast, you just do dispatch and then you put the name of the job that you just created with artisan. It will just take it from there and queue it to whatever driver you set. Then, when you are ready to run your queues, the artisan command to do that is PHP artisan queue:work and then the dash dash queue is basically telling it, okay I want it as a high priority or a low priority or whatever you need to tell it. If you run this command on your development server, it will run and then, that's it. But if you try to exit, it will stop running. The queue worker needs to run continuously because it needs to check every single time, is there something new, is there something new. It needs to check every time. But if you're running one time, you cancel it, it will stop running and then anybody that adds new processes that needs to be queued, we generally not get anything because the queue process just died. So how do you keep running stuff like that in the background? That's where something like Supervisor comes in. Supervisor basically is a client server system that allows users to monitor and control processes. Basically it just stays in the background and then makes sure the process is running in the background. It just supervises whatever process you put for it, is running. When you're writing a Supervisor process, it has its own syntax. I wouldn't really go deep into it because I believe everybody has to do their own research on how it works, exactly. But this is something related to how it will look like. You have your process name. The process name is just usually something like, maybe Laravel queue. The reason why I did this is so that it takes the name of your application and the process number, in case you want to add multiple instances, or you want to launch or spawn multiple process instances. It doesn't clash or collide. We're at the command where Supervisor is supposed to run when it starts, and then we tell it that if we're with a server, automatically restarts. So that is what auto start ... Auto start means, sorry, auto start means just that, and auto restart means, when we reboot the server, restarts. Then we tell you the number of processes, so we just say when you are running this particular command, have, like its processes, just in case there are too many queues. One of them is bound to pick one up. Also, let me tell where to log whatever results it gets into. The command to run Supervisor is simple, supervisor ctlstart. I hope you guys have enjoyed the presentation. I know everybody deploys applications every single day, but there are things you need to take into consideration before deploying your application. Don't just jump into it. Actually sit down and think about your application and its use cases. How big do you envision this application to be? What are the things you really need it to work with? Are you going to be sending an email? Can you really take advantage of some other lovely things that Laravel have inside? Right inside ... Many people don't use because they thinks it's kind of unnecessary or too much work. There are some really, really dope features that Laravel has in store, this can really help smoothing out whatever application you have viewed and all this seamless experience. Thanks.