Deployment and Hosting - Jump Start PHP Environment (2015)

Jump Start PHP Environment (2015)

Chapter 6 Deployment and Hosting

Now that version control is out of the way, it's time to look into deployment and hosting.

Deployment, as you may have learned from previous chapters, refers to the act of putting your locally developed application online for people to use. A deployed application doesn't necessarily mean a publicly available one―it can be an intranet application that is internal to a company, for example; it means it can be used by its target audience.

An application, however, cannot be deployed without being hosted; there needs to be a server computer that is its home. In this chapter, we'll talk about both terms in more detail and list some approaches to each. We'll also cover the pros and cons of common approaches and define some terms you'll be hearing a lot throughout your web development career.

Even if you're familiar with aspects of deployment and hosting, it's recommended you read this chapter as it contains up-to-date information on what to avoid and what to select.


We'll explain hosting first, as it's important to know how to pick a home before you move into one.

The three main types of hosting you'll repeatedly encounter are: shared hosting, cloud hosting, and (virtual) private hosting. I'll explain the parenthesized "virtual" further on.

Shared Hosting

When hosting companies have a single server (which can consist of either a single machine or several acting as one), they make a separate folder and user account for each customer on this server; this is known as shared hosting. Each customer is allotted a part of the server's processing power, a fraction of its total RAM, and a chunk of the hard drive space. This shard of resources can then be used as a home for your deployed application. A company might have several such servers set up for when one runs out of space to accommodate new users. This sounds great in theory, but in practice it has many problems.

Shared Hosting is Bad

For lack of better (that is, cheaper and/or simpler) options, shared hosting was the only viable approach for many people for a long, long time. This kind of widespread use lead to its dominance of the hosting market, and it remains popular purely because of this initial inertia.

Shared hosting is bad for several reasons:

· Security risk: many popular content management systems such as WordPress, Drupal, Joomla, and others ask the user to enable write-all access mode on certain folders so that they may place their files in there. In doing this, many users unwittingly allow access to their website's files by mistake while sharing a hard drive with other customers. This so-called "777 problem" (where 777 is Linux code for "allow everyone to do everything on this file or in this folder") is a tremendous security risk. What's more, when using content management systems on shared hosts, you're at risk of outdated versions. One site's laziness and unwillingness to update another instance of the installed CMS on the same server can lead to your site being hacked, as it can become a gateway through which attackers gain access to the entire server!

· Traffic overload: You rely on other people's competence and traffic. If a site on a given server has badly written code that uses too many CPU cycles or eats up a lot of RAM, other applications on the same server may suffer because of it; since all applications are sharing the same hardware—which is quite limited in shared hosting environments—a user's excessive needs may be detrimental to your own application. The same goes for well-written code with lots of traffic: if another site receives too much traffic, the server might get overloaded and shut down, taking your site down with it.

· Limits: a lot of shared hosting companies promise unlimited bandwidth and resources, but this is almost never true. There is no such thing as "unlimited" anything: as soon as your site manages to breach an internally agreed-upon limit (be it regular CPU use, hard drive space, or bandwidth), you'll be sure to discover just what unlimited really means. Check out the following piece from that points out the pitfalls of shared hosting, and provides a cautionary tale about getting disconnected due to using up too many resources on an unlimited plan.

· Reputation: when you're on the same server as other customers, you all share an IP address. Any illicit activity done by others on the same server can reflect badly on you as well. Imagine a customer sending millions of spam emails from a shared hosting server that you use. These emails are then picked up by popular spam-hunting engines and the IP address is flagged as one that often spams people. Suddenly, all emails that your own application sends out are also flagged as spam in people's inboxes, purely because the IP address is the same as that of the original spammer.

These are just some of the main issues around shared hosting. But there's one that's arguably more important than all the others mentioned: shared hosting holds you back.

Shared Hosting Holds You Back

When using shared hosting, you're typically given a simplified user interface such as cPanel, the one shown in Figure 6.1, through which to configure your site. There is, however, no actual server access to fine-tune aspects of your site, install custom extensions, upgrade your app the way you upgrade your local development server, and so on. Essentially, you're locked into what the hosting company has installed and there's no way to change it because it would affect hundreds―maybe thousands―of other users.

cPanel is a common shared-hosting control panel

Figure 6.1. cPanel is a common shared-hosting control panel

This might seem ideal for entry-level users, but it provides too much abstraction. In other words, it places a user too far from the nitty-gritty of custom configuration and server setups―something that is absolutely essential to be familiar with in your web development career.

By sticking with such simple approaches, you do yourself a short-term favor for long-term harm. The time will come when you'll have to deploy to a real, non-shared server, or when you'll need to manually update server software.

But there must be some use cases where all this simplicity is good, right?

Shared Hosting is Good for Limited Use Cases

There are projects where shared hosting is a godsend. In a career of serious web development, these use cases are rare but still possible:

· Custom email: with shared hosts, it's incredibly easy to set up a custom email address. Ever dreamed about having an email address such as Would look cool on a business card. With shared hosting, it's a breeze. You buy a domain (, go into your shared hosting account's control panel, and set it all up according to the instructions. Most have a step-by-step process, so you should have a personalized email account within 24 hours.

· Small code samples: those requiring very few resources are easily hosted on shared hosting servers. Small portfolio scripts and projects are ideal for this purpose; for example, code demos within tutorials you write, sample code from client websites you've built, and so on. Anything not needing to support large amounts of bandwidth should work indefinitely, and live demos instead of words on a resume always looks better!

· Fire-and forget projects: Finally, there's the simple sites for really low-maintenance clients such as a neighbor's pet, your grandma, a butcher, or a local store. Maybe you're actively involved with volunteer work and are helping to organize a conference by creating a website for them. Anything that's generally short-lived or updated rarely (also known as a fire-and-forget project) has a comfy home on a shared hosting server. The low resource demands of such projects and their relatively limited traffic ensure their compatibility for a long time to come. For a cost as low as $5 per month (the average price of shared hosting servers these days), you can accommodate multiple clients. What's more, the simplicity of the UI and ease of use ensure that the project can be easily taken over by someone else if you're no longer interested in being involved.

Cloud Hosting

Cloud hosting is where many computers are linked in a symbiosis making them act and appear as one.

In Figure 6.2, the horizontal units in the glass cases are minimized computers: hardware units with all the unnecessary parts stripped out so that they are as power, space, and heat efficient as possible. Networked together, they form one great whole, and there are warehouses upon warehouses of them. Contrary to their name, cloud computer systems are very much grounded. They're merely very large computers formed of many little ones.

A large collection of servers

Figure 6.2. A large collection of servers

On this apparent single computer, a special kind of software is run that dictates the look and feel of the environment; for example, making it seem like we're dealing with a single Linux server. In some ways it's like shared hosting―but on a much, much greater scale (many more computers).

Cloud hosting usually allows terminal access to the server (enabling you to manually configure some items) but often features GUI elements that are used to generate access codes, install plugins into your cloud-powered applications, and more.

Some popular cloud hosting providers are:

· Google App Engine (

· Heroku (

· Amazon Web Services (

· OpenShift (

· Azure (

· Fortrabbit (

... and there are many more.

There are several approaches to cloud hosting, but the one common vector they all share is that you do not depend on other customers' good will and code, unlike with shared hosting. The resources of the cloud (aka the network of computers on which your app is operating) are focused on processing your (and other people's) code, while the hard drive storage parts (such as storing images your users upload, for example) are usually saved elsewhere. This has two advantages:

1. The cloud is used exclusively to process code. It is optimized for that one purpose, so your app is always fast (depending on your code's quality, of course).

2. There are no resource limits. In cloud computing, there are so many machines working as one that there are always plenty of resources for your app if needed.

Cloud hosting follows a payment model that charges by the number of units of time your app has been using a server. For example, it might be priced at two cents per unit of time per CPU, and units may be increments of 15 minutes. So if your application used one CPU core for 24 hours, then had a sudden traffic spike and used four cores for 24 more hours, you'd end up paying $1.9 for day one, and around $7.7 for day two, totaling around $10 for two days. Cloud hosting is more expensive if you have lots of traffic, but more reliable than shared hosting as it rarely, if ever, crashes. It can also auto-scale (if you tell it to), which means that if your site suddenly receives a huge traffic boost (maybe it ended up on the news), the cloud-hosting provider can automatically allocate more CPU cores to your app and keep it alive for those extra visitors. This means no lost business, which probably offsets those hosting costs anyway! Besides, if you fear a wave of traffic so powerful it could financially destroy you, most services offer limits you can set; for example, "throw more power at my app as long as it stays under $2,000 per month."

Many cloud hosting services also offer free tiers, meaning you can use them free of charge, no strings attached, for as long as you want―but with limited resources and missing features (no custom domains, for example). If you want to expand, you can very easily upgrade the account your site is already hosted on, and it immediately becomes more powerful (and more expensive).

Cloud hosting is the hosting choice these days, particularly for high-profile applications requiring extreme reliability, as downtimes are rare. Cloud hosting is also excellent for one-off projects such as demos and portfolio pieces if you utilize the free tiers many offer―at no cost, you can have permanently available, publicly accessible runnable code live online.

It's not all fun and games, though. Some of the disadvantages of shared hosting are present in cloud hosting, too:

· Vendor lock-in: this can happen in cloud hosting, too. Often, the platform you're on will have platform-specific settings you need to learn and tweaks to master. Likewise, versions of installed software also tend to remain unpatched. Since the servers are tweaked to run a specific version of, for example, PHP at incredible speeds, that version is also tweaked to run well in such an environment, making it difficult to update as a new version would require those (often non-trivial) tweaks applied as well.

· Learning limitations: while shared hosting holds you back by failing to teach you anything about server management, cloud hosting is limiting by teaching you only a specific type of server management―theirs. Moving from Google App Engine to Heroku is no trivial operation, both in code terms and in the learning curve involved in mastering a new tool with its own specific commands and utilities.

Remember―cloud hosting is similar to shared hosting, but on a much grander scale. To use cloud hosting, however, one is typically an advanced user already proficient in some server management. For the case of a newbie starting out, I'd always recommend virtual private servers.

(Virtual) Private Hosting

Also known as dedicated hosting, private hosting promises a dedicated machine―be it virtual or real―for your needs (hence why virtual is parenthesized). You can then use this machine for whatever purpose you see fit. If you choose to make it into your own shared hosting provider, you can set up the server to support this and resell the space. You could also buy several machines, and cluster them up to make your own mini cloud. Or just use a single server for a single app―that works, too!

In dedicated hosting, having a physical machine just for yourself is quite expensive, getting into thousands of dollars per month depending on the machine's power. That's why most users opt for VPS (virtual private servers), which are virtual machines, or VMs (not unlike Vagrant machines we talked about in previous chapters) on a single server. Much like in cloud and shared hosting, a single computer (or what appears to be one) contains several smaller ones―instances for customers to use. These instances act like real servers, so you gain full access to them via the terminal. You can install and uninstall anything at all, even change the operating system. The VM doesn't care; it's completely isolated from the rest, and you can make it and break it at will.

VPS hosting is the most accessible approach for new users for the following reasons:

· Price: modern VPS providers are incredibly cheap. Services such as Vultr and DigitalOcean provide virtual servers―machines more than strong enough for the average web app or two―for as little as five dollars per month. This is cheaper than cloud hosting, but much more powerful than shared hosting. The bandwidth is unlimited, and the only CPU, RAM, and hard drive limits you have are those you agree on upon purchase. All servers can also be upgraded at any time, and with programs such as DigitalOcean's referral system, you can end up never paying for a single month if you refer enough people to the service. In fact, the bonus goes both ways: even the ones coming in via a referral link receive a bonus of (currently) ten dollars just for signing up, giving the referrer a bonus after they've actually made a purchase.

· Reliability: VPS is as reliable as you make it. Very rarely does an entire data center of machines go offline for such a hosting provider, as there are a plethora of fail-safes installed to prevent downtime from happening. For the most part, the server's stability depends entirely on how you set it up, which leads to you training yourself in server matters―something of utmost importance. When compared to cloud hosting, reliability of the infrastructure behind the scenes is identical; the only real risk of downtime is the customer misconfiguring their VPS instance.

· Familiarity: a VPS will look familiar if you started with Vagrant VMs as described in this book. It will be the same interface, same commands, same procedures. You'll be familiar with most of the aspects you can modify, and able to debug your live server because you have experience on your local one (the local Vagrant VM you're developing on). A VPS is a quick and easy way to development-production parity, which is not as easy to achieve with cloud hosting, and impossible to achieve with shared hosting.

I always recommend VPS hosting to new developers because it's the perfect middle ground between cloud hosting's power and shared hosting's ease of use, once a person is comfortable enough with the terminal.


There are, of course, countless other types of hosting as well―each matching specific use cases.

For example, Nitrous.IO, Codenvy, Cloud9, and Koding are all cloud-based development environments (Cloud IDEs) with built-in hosting. Opening an account with them will give you a web interface in which to edit your code―much like in an IDE such as PhpStorm―and at the same time a place to automatically host and run the code you write. These services can be costly for apps that go any measure beyond basic, but are extremely practical for people on the go―particularly netbook users who lack the computing power to run VMs, but are always online and prefer to travel light.

Feel free to create an account with any of them and test out their sample applications. Nothing can go wrong, and nor is there a need to be code-literate to understand what's going on.

I've summarized my views on the pros and cons of various hosting options below.

Shared Hosting

Cloud Hosting


Cloud IDEs




(★★★★★) ★☆☆☆☆







Ease of use




















Hardware limits






Deployment is the act of sending a ready application to a live server so that it can be accessed by its target audience. It also includes pushing updates to an application online when a new feature is added or a bug is fixed.

There are two main types of deployment: manual and automatic.


Manual deployment involves actively recognizing that the application is at a stage when it's usable by the target audience, or at a stage matching one in the project specification―a document outlining the entire project's development process.

Once deemed ready, the developer takes one of several approaches to deploy the application:

· FTP: in the ancient days of Web 1.0, File Transfer Protocol (FTP) was a way to transfer files (duh!) from one server to another. Today, this approach is usually only seen in severely outdated systems and servers such as universities and schools, or shared hosting. Uploading files via FTP requires you to have an FTP client installed on your computer such as FileZilla or Cyberduck. You also need the credentials of the server you're uploading to―usually the server name, a username, and a password. If an application is already deployed and an updated one is being deployed on top, the older one is usually overwritten, which opens the doors to a whole throng of possible bugs. In regards to application deployment, there are better approaches and FTP should be avoided.

· Rsyncing involves using a tool called rsync to synchronize the contents of two folders. Rsync works via SSH (Secure Shell), which essentially means you can use it through the terminal without having to install any additional programs. Rsyncing is better than FTPing because SSH is more secure than FTP―unless you're using SCP (Secure Copy Protocol) in FTP (however, SCP in FTP is still suboptimal as any number of things can go wrong, such as files going missing or getting accidentally deleted, and there's little to no way to quickly undo these mistakes.)

· Pulling from a repository: this method uses the Git version control system (see Chapter 5) to push the changes live. Two approaches can be taken: a push can be made so that the code goes to a remote server. This is done from the development environment―the local server. More commonly, a pull can be made. Pulling is done by the live server―the machine on which the code should eventually end up. Pulling code from development machines is usually not possible and generally discouraged, because opening up outside access to your development machine is a security risk. Instead, a push is first made to a central repository such as GitHub, and then the live server pulls from there. This approach is the most common as it offers the safety and sanctity of infinite undo steps courtesy of version control, and removes any overwrites that may happen due to multiple people working on the same codebase and trying to upload at once.

These are far from the only means of manual deployment, but they are the most popular ones. They're somewhat tedious, though, and tend to take up time and resources that are better spent elsewhere. In software development, the general rule is to automate whatever can be automated. Which brings us to ...

Automatic and Semiautomatic Deployment

There are many tools for automatic deployment: Robo, Deployer, Envoyer, Rocketeer, DeployBot, and so on. They rely on certain pointers in the source code to know when a version of the application is ready for deployment, or on manual triggers from developers, and then take care of the rest automatically.

Practical aspects of automatic deployers are outside the scope of this book but, put simply, this is how they work:

1. You work on some code and then make a commit in Git.

2. You add this commit to the master branch, the main branch of your repository. As a general rule, anything committed into the master branch is ready for production, aka deployment.

3. A tool such as Deployer notices this new commit to the master branch, automatically checks the code for common errors, and if everything is well sends it online for you without you having to move a finger.

The application code will be up to date and you've simply continued to code after your last commit without even needing to check. The tool did it all for you.

Fully automatic deployment of this kind can be risky, though. The tests in the application may not be robust enough, enabling some bugs to slip through because the application is unable to find its own errors.

This is where semiautomatic deployment comes into play―automatic, but with a human element. Once a developer ensures the release (the newest version of the app) is fine, they run a simple command such as dep deploy and the tool takes over the rest of the process: preparing the server, making pushes and pulls, clearing cache files, and so on. This is the best of both worlds; the machine does the heavy lifting, but the developer tells it when to do it.

So, of all these tools and approaches, what's the best combination to use?


I'd recommend using manual deployment with an intermediary GitHub repository, and using DigitalOcean for hosting, at least for the first few months. In due time, you should definitely move towards automation―especially as more advanced concepts such as database migrations, cache busting, and file permissions come into play―but for now, this approach will benefit a newbie the most.

GitHub accounts are free, so you can open one at any time and create an arbitrary number of repositories. DigitalOcean is free for the first two months with my referral link, and only five dollars per month subsequently.

Apart from being wallet-friendly, using these two services in tandem will teach you server maintenance basics, improve your Git and GitHub skills, and make you proficient in the most commonly used deployment and hosting services today.

By the end of this book, we'll have used this GitHub and DigitalOcean flow to deploy a simple application.


In this chapter, we explained the theory behind deployment and hosting and covered the terms you'll meet most often. We went through the basics of how hosting services work, and learned the best approach to take at this stage of your web development career.

In subsequent chapters we'll be putting this theory into practice by using the tools we mentioned to deploy a sample application; however, there's one more critical piece of the puzzle we need to cover first: Composer, the PHP package manager. Stay tuned, we're about to get our hands dirty again.