How Servd Works
Servd is a little different to normal hosting platforms. We believe that you shouldn't need to be able to provision servers to get your Craft websites live.
So we've tried our best to hide all of the complexities and at the same time provide you with all of the Craft hosting best-practices without you having to configure a thing.
Because we're so different, there are a few concepts that it's important to understand before we get started...
Most hosting solutions are server-first. You rent a server and that becomes the focus of your workflow.
Servd takes a different approach by making your application the star of the show.
We do this by using the concept of bundles.
A bundle is simply a package containing a specific version of your application, an installed vendor folder created from your composer.lock file, the base software needed to run everything (PHP, nginx etc), and some configuration which allows us to understand the files inside your Git repo.
Once a bundle has been created it cannot be changed, but you can create as many bundles as you need.
This ensures that when you deploy a specific bundle to your Staging environment, it'll be identical to the same bundle deployed to Production - right down to the specific patch version of PHP - with zero server configuration required.
Because we're application-first we aren't constrained by the normal rules of hosting which force you to choose a specific amount of CPU and memory up-front. Instead Servd has a pool of resources which your deployed bundles can make use of. Each of your bundles has a guaranteed set of resources which change depending on the plan you've selected, but they're also able to use more resources in short bursts.
This makes a lot of sense when you consider that Craft projects tend to use resources for a very short amount of time for each user requests for a page or resource.
This also allows you to grow your application fluidly without having to worry about scaling any servers to match. Need two instances of your application for a month? Just change your project's plan and it's all taken care of for you.
The Local Filesystem
One of the trade-offs that we've had to make with our bundling approach relates to how the filesystem works. Your application's filesystem is closely related to the currently deployed bundle. This means that if you swap the bundle for a new version the filesystem resets to an initial state.
This can be a very positive thing. Imagine if a rogue plugin has trashed all of your template files; just redeploy your bundle to reset the entire filesystem.
However, it does mean we also need to take a few precautions. If control panel users can upload images to the local filesystem, they might disappear when a new bundle is deployed. Don't worry though - Servd supplies a zero-config alternative to local filesystem uploads.
Just keep in mind that although your app will always have a filesystem to use, you should only use it for temporary files at run-time.