servd

VPS servers have powered the majority of PHP applications for the last 10 years. They've served as the backbone of web based applications throughout that period. In part that has been due to their flexibility - a VPS offers a blank-slate - a generic solution to our app's needs. But that apparent strength can quickly become a weakness, primarily due to the additional complexity and overhead that it adds to our day-to-day lives.

Servd is designed to be different. We believe that, just like a good suit, a tailored solution not only fits better, but is a more rewarding long-term investment.

We're building a platform which we hope can replace VPS servers as a standard solution for a specific use-case: Craft CMS Hosting. We aim to not only save you time, but make your project:

• More secure,
• More performant,
• More scalable and
• Less stressful

We're doing this by building a platform with all the Craft CMS requirements and best practices already taken care of. Instead of starting from a blank-slate, you're starting with a framework which is pre-configured using the knowledge and experience of Craft and PHP hosting experts. All wrapped up in a product which is designed to put your application front-and-center, whilst taking care of all of the things that you shouldn't need to be worrying about behind the scenes.

Architecture

You're probably used to thinking about servers as empty boxes which we can fill with stuff to make our project's run. Each box ends up as a unique combination of all of the tools, code and software that we've ever needed over the lifecycle of our project. This has been the status-quo since internet applications came into being.

In recent years there has been a shift to another approach: containerization.

This approach packages your application up into a 'container', a self-contained bundle which contains your application and everything that it needs to run. You can make multiple copies of this bundle in order to run your application in multiple locations without having to install anything project-specific on the server first.

This decoupling of your application from the servers it runs on provides us with a huge benefit: we can focus on perfecting your application bundles and worry about the servers they run on later.

This concept of 'containers' and project bundles gives Servd many of the superpowers we discuss below, but at its heart, it's about moving the focus away from servers and back onto your application, where it should be.

Setup

The most important part of getting your project online is its initial setup, but it's often the most rushed. As deadlines approach and we need to get our hosting set up as quickly as possible. With traditional VPS hosting this might mean:

1. Setting up users and permissions
2. Configuring firewalls
3. Installing and configuring our base software
4. Setting up deployment tooling
5. Enabling and configuring backups
6. Testing connectivity
7. Generating and debugging SSL certificates
8. Configuring DNS records

And many other steps which we know we should probably have written down on a checklist somewhere.

Each of these steps is prone to human error which can result in a significant amount of time spent debugging. Time which otherwise could be spent adding value to your project.

This setup process has become the focus of a set of tools which try to address the potential human error: server provisioners. Services like Laravel Forge, Serverpilot and Ploi.io have all sprung up in this gap. Each will run a VPS's setup steps on your behalf in a formalised way.

This seems like a great solution for those who don't want to have to learn the ins and outs of server configuration, but can lead to some nightmare scenarios if anything does go wrong with these tools (and they regularly do). In this situation a developer not only needs to manually debug the problem, they also then need to reverse engineer the provisioning tool to figure out how it has configured the server! Ensuring that any changes don't break compatibility between the server and the provisioning tool moving forward. They often need to learn all of the same things required to manually provision a server, but they'll be doing it while your site is offline 😬.

How Servd Is Different

On Servd, your servers are already configured before you've even signed up. We have a set of pre-configured and tested bases onto which we layer your application once you provide us with access to it.

Not only does this save you time (it typically take less than 5 minutes to get your project deployed on Servd) it guarantees that your project gets a reliable, no-fuss setup process.

There is no potential for configuration error, because the configuration is already defined.

There's no need to learn what's going on under the hood, because it all works right out of the box.

And you can rest assured that your application is using a set of software and configurations which have been developed over time by infrastructure experts to perfectly match the unique requirements of Craft CMS projects - no generic solutions here!

Security

Security is often taken for granted with VPS servers. We assume that the software we're using is secure by default, but the reality is that a lot of it, with its default configuration, is not.

MySQL, Redis, SSHd and many other standard LAMP server tools are installed with insecure defaults and their proper configuration is often neglected as it requires some knowledge of their many configuration options as well as how networks and operating systems function.

Many hacks and data breaches that we see in the news are caused by the acceptance of default security options so they're important for us to address before we can say our application is actually secure.

Just like our initial setup process, this can be performed manually or by an automated tool. These method can still result in oversights however, as software is updated its requirements and configuration parameters change. This can result in previously well-rounded security policies becoming obsolete.

It's also important to consider changes made to a server over time. A VPS often becomes a bespoke result of all of the code, tools, software and bug fixes that have been required over its lifetime. This uniqueness is a significant flaw in the maintainability of a server's security: as all of its software becomes unique, so do its potential security vulnerabilities.

After initial setup a VPS needs to be maintained. This responsibility is often neglected as it can be a dangerous process. Updating individual components can lead to incompatibilities which need to be manually resolved, all while your project is offline. This danger involved in the update process often results in a reluctance by developers to apply any significant security updates which build up over time, compounding the issue.

Finallly, from an infrastructure point of view, most VPS servers are completely exposed to the internet. All traffic sent to your server's IP address will be received and processed by the server. Much of this traffic will be filtered out if a well-configured firewall has been defined, but any oversights can result in malicious traffic reaching the software on your server. We regularly see this on VPSs as SSH brute-forcing attempts or speculative FTP scanning.

How Servd Is Different

1. We curate all of your project's software and configuration

We take security seriously and we bake it into every project created on the Servd platform by default. Because we create and test our base software configurations ahead of project creation we're able to ensure that all the necessary security configurations have been taken care of on your behalf.

We are also able to release new base configurations on a regular basis which you can use to build new bundles for your project. If something breaks when you deploy the new bundle, just roll back. This eliminates all of the fear previously associated with updating system software and allows you to apply security fixes without a second thought.

2. We configure the infrastructure

The Servd platform is built to disallow most access to your project by default. Only a very limited amount of traffic types can reach it. This reduces the potential attack vectors by a massive amount - attackers are restricted to only sending HTTP traffic to your application and, by default, have zero ability to connect to your project's Redis or Database services.

We are also able to filter out common attack vectors at the infrastructure level. For example the recent SEOmatic attack was mitigated within Servd's infrastructure by simply blocking the requests which were being used as part of the exploit within the platform's infrastructure. We rolled out this change early on, which resulted in zero projects on Servd's platform being exploited, even though many of them were vulnerable.

3. Our filesystems are ephemeral

One of Servd's super-powers is its ability to fully reset a project's filesystem without breaking anything. This allows any compromised server to be fully cleaned of backdoors left by an attacker on every new deployment. You can read more about this and how it prevent security vulnerabilities in our recent blog article here.

Maintenance

Once your server is all set up and configured perfectly it's important to keep it up to date and ticking along nicely. These updates often require good background knowledge of both the server itself, the tools used to provision it and the application it's running. This usually means it becomes the original developer's responsibility.

This is often dealt with using a maintenance contract between the developer and the application owner, however these can be costly and often still result in problems occurring during required live updates.

Also, the updates that become available for VPSs are often the same for all LAMP stack projects, but the work to actually perform the updates has to be repeated for each individual server. This can result in both a huge waste of time and money when significant security updates are made to a core LAMP stack component.

As well as updates, things can simply go wrong with a server. Files can become corrupt or services can go haywire. These problems usually go undetected until your project stops responding to requests and a developer is brought in to debug the problem. If this happens at 2am, your project might be down for a while.

How Servd Is Different

We ensure that all projects running on Servd are configured in a similar way. This allows us to build a new base software update that can be applied to all projects, rather than trying to tackle them all individually. All you need to do is build a new bundle and deploy it once for each of your projects. We'll have already tested the updates with a variety of projects so the chances of any problems are minimised. If there are any problems they can simply be rolled back - minimising downtime.

As well as providing your projects with regular software updates, the Servd platform is monitored and updated on a daily basis. These updates ensure that the underlying infrastructure is working as well as possible for your project, without you needing to worry about how or when those updates are being applied.

The Servd platform also monitors your application on an ongoing basis. If PHP crashes or MySQL stops responding Servd will notice and take action. The platform's first line of defence is to simply kill the misbehaving software and restart it in a new, pristine environment. This fixes 99% of problems automatically. For the 1% of problems which aren't automatically fixed Servd detects the repeated issues and contact one of our team immediately to resolve the issue.

Deployments and DevOps

Getting your server ready is only half the battle. Once you're all set up you need a method of deploying code updates too. With a VPS this process can take many forms each with their own pros and cons, but the two most popular are Git deployments and symlink swap deployments.

Git deployments are often the easiest to configure and simplest to understand. They are the default deployment mechanism used by Laravel Forge and Serverpilot but they come with a few significant downsides:

1. If the git pull process is interrupted for any reason, the deployment will be left half completed and in a difficult to restore state (non-atomic)
2. If any files have changed on the server a merge conflict can occur which might take a minute or two to resolve
3. If you need to update any dependencies you'll need to subsequently run a composer install which is very likely to cause downtime and suck up 100% of your server's resources for a while

With these downsides it's likely that you'll run into issues during updates at some point in the project's lifetime.

The alternative, symlink swap, is known as an atomic deployment. If it fails at any point the changes made are simply abandoned and the live site isn't affected. This type of deployment normally requires a 3rd party tool to work well, an example being Buddy.works.

This alleviates many of the issues with the Git deployment method (as long as your 'composer update' is also being performed off server), but adds a significant level of additional setup time and another external service to configure and maintain. It also gives root access to your server to your deployment tool which is usually undesirable.

How Servd Is Different

We're an end-to-end platform, so we include building your bundles and deployments as a core part of our service. In fact, you might not even notice that they're happening behind the scenes.

Servd takes the files from your git repo and executes composer install on them in an isolated environment, away from your live project. Once that process is successful and your new bundle has been created it is booted up alongside your existing live app. We then perform a few tests to make sure it's ready to receive traffic before moving all of the incoming requests over to it. Once all the requests are going to the new container we then destroy the old version.

On Servd there's no chance of the update process interfering with your live application, and any errors will result in the process being aborted with no broken updates left hanging around.

We also optionally automate Craft migrations and project config updates to allow for zero downtime deployments, even when your database schema has changed. Setting this up is as simple as flicking a switch in the Servd dashboard.

Recently we've also added the ability to compile static assets as part of the deployment process, so you can provide a command to run webpack, gulp or any other node based buildchain. This brings the entire continuous integration and deployment flow for your project into a single, simple dashboard. Oh, and all this is included for every project on Servd.

Scalability and Performance

VPS servers are usually easy to scale vertically. Changing the number of available CPUs and memory can often be done via the server provider's dashboard. It's not unusual for this process to incur significant downtime though, and scaling down is normally not an option.

This can make scaling up and down to meet the changing demand of your audience a challenge.

Scaling horizontally by adding additional servers is even more complex. You'll need to manually add and configure a load balancer whilst also ensuring Craft has been configured to handle a load balanced environment. This will usually mean adding a Redis cache to ensure PHP sessions are shared between nodes.

Each of these components is another aspect of the project which needs to be maintained and updated. Very few server provisioning tools allow this to be done well in an automated fashion, so you'll often need to perform some of these duties manually.

When it comes to overall performance VPS servers are often configured with default settings for all of their components. This can have a particularly bad impact on the database. There are a lot of options which can be tweaked to ensure its performance is tuned to the typical workload of the application it is supporting. This is hardly ever performed during manual setups or when using a provisioning tool.

How Servd Is Different

Servd sets you up with a load balanced infrastructure by default. Even if you're only using a single server to begin with.

We automatically set up networking and Redis on your behalf and wire everything together. We even make a few changes to your project while it is being bundled in order to ensure that it is all set up to support a load balanced environment. You don't even need to change Craft's config files to get all of this working.

Ensuring all of our projects are ready to scale gives Servd a great advantage: Moving from 1 to 2 or more servers is as simple as clicking a button in the dashboard. Everything is taken care of for you and your project scales up within seconds. You'll only see a few seconds downtime if your database needs to scale too.

We handle all of this for you so that you aren't hit with an unexpected bill to build out new infrastructure when your project's traffic increases.

Servd is built on top of traditional VPS servers, so underneath you're still using the same CPUs so there shouldn't be any difference in raw resource performance there, but we do have one trick up our sleeve! Servd allows spare CPU resource in the cluster to be used by projects for a brief period of time. This means that your project might use more than 100% of its allocated CPU to process a single request, before dropping back down to 0%, at which point another project can make use of the spare CPU.

This results in increased performance for projects with randomly distributed incoming requests compared to traditional VPS hosting as well as being more efficient across the entire hosting cluster.

In order to further improve performance we also configure all of your project's services to be tuned for a typical Craft application. This includes a lot of individual tweaks, but some of the most important are:

• PHP's memory usage and worker pool management
• Opcache's filesystem usage and invalidation rules
• Redis memory management and filesystem flushing
• Database memory usage, filesystem flushing and transaction handling

We tailor each of these to not only work well with Craft, but also to work well with the underlying infrastructure, which is often distributed over multiple physical servers.

Monitoring

Monitoring comes in three pieces:

1. Tracking resource and other important metrics
2. Alerting rules to accurately interpret errors
3. A team to respond to these alerts

Traditional VPS hosting normally offers parts of the first two pieces.

Basic monitoring is often provided by the hosting providers themselves. This allows the tracking of CPU, memory and disk usage on your server. They normally also allow alerts to be defined when these metrics exceed a certain threshold.

These tools are useful for a high level glimpse at a project's health, but often don't uncover issues such as increased project response rates or failed processes within the server itself.

They also can't provide any solution for the third piece of the puzzle: a team to respond to any alerts.

How Servd Is Different

Servd operates a comprehensive monitoring platform for all of its infrastructure and projects. There are more than 300 individual metrics collected and available for us to analyse. The most important of these are fed into our custom built alerting framework which determines the severity of any issues it detects (soft or critical) and alerts our on-call team if infrastructure related problems are detected.

We supply all of the metrics, alerts and team support needed to ensure that if anything goes wrong, someone will be looking into it.

A few examples of soft alerts we have set up:

• SSL certificates nearly expired
• A project using a lot of CPU for a significant period of time
• A project's request latency is high or has increased significantly

And some critical alerts:

• A process has crashed and has been restarted multiple times
• A project is failing to boot
• A node is running low on memory
• Incoming requests aren't reaching their intended project

All of these things are flagged to our team and are handled directly by us. We'll only ever need to get you involved if we find a specific problem with your project's codebase, or to tell you that we've fixed something that you hopefully didn't even notice anyway.

Support

With a VPS, you're on your own.

Figuring out all of the ins and outs of provisioning and maintaining your servers is up to you or your developers. This can be a risky approach as we've discussed above. Any support which is offered by hosting providers or provisioning tools is limited to their specific services and will never be backed up by any Craft CMS specific knowledge.

How Servd Is Different

We actually enjoy helping you to get your project up and running on our platform. Not only that, but we've been working with Craft for years, so we know it inside and out. We're happy to debug issues with you because, ultimately, the better your project behaves on our platform the less we have to worry about things breaking in the future!

You can always contact us via live chat or email at any time. We'll get back to you within 3 hours during our core working hours (in reality it's normally within 10 minutes) and asap outside of those hours.

If you have any questions, or just want to chat about Servd or Craft, then feel free to reach out. You'll always be talking to an expert in both Craft and our platform.

Extra Features

We've covered a lot of the differences between traditional VPSs and Servd, but there are a few services which Servd offers for which VPS providers simply don't have any comparison. Below are a few of our favourites: