Deploys - Overview

There are two ways to deploy to the serverless platform, using either git for continuous deployment (our recommended approach), or file deploys. We also provide SFTP access, but this is primarily used for viewing, editing or transferring a small number of files.

Note

The deployment method you choose for a website is permanent, and can’t be changed later. If you need to change approach for a website later, you will need to recreate it.

Atomic Deploys

On Webslice deploys are atomic, meaning your whole application is deployed each time, and the existing release stays separate. This ensures zero downtime, simple rollback, and consistent state.

If you are used to deploying files with SFTP, SSH or similar this is a bit different, with two key concepts to keep in mind:

• Your application files are downloaded and replaced entirely each deployment, giving you a clean slate.
• Any files written to your application directory during runtime (think uploads, cache, logs, built artifacts) will not be present on the next deployment, unless placed in persistent storage of some kind.

Persistent Storage

For some parts of your application you may need persistent storage. Some common uses cases are for storing generated images, caches, logs, or user submitted content.

That’s where the shared directory /mnt/data/website/shared comes in – it’s a directory that exists outside your application’s deployment directory and survives across all deploys. You can write whatever files you like here, and they will be available to all deploys now and in the future. You can also structure it’s contents however you like. Here’s a simplified example of how we use it for our own website:

We have three things we want to persist between deploys. User submitted form entries, our generated responsive images and some logging. In our build script we have the following:

.webslice/build.sh

#!/bin/bash

# create shared directories if they don't exist
mkdir -p /mnt/data/website/shared/forms
mkdir -p /mnt/data/website/shared/img-cache
mkdir -p /mnt/data/website/shared/logs

# remove existing public image directory
rm -rf public/img-cache

# create symlink to persistent storage so image paths work
ln -sf /mnt/data/website/shared/img-cache public/img-cache

echo "✓ Symlinks created successfully"

This gives us the three folders we want to persist, and we have made only the image directory accessible in our public/ directory to ensure existing image paths work and are available to the browser. The other two directories are private, so there’s no symlink required. Instead in our site.php we tell the system that’s where to write logs and form entries to:

config/site.php

return [
  'image_manipulation' => [
    'cache' => true,
      'cache_path' => storage_path('/mnt/data/website/img-cache'),
  ],

  'disks' => [
     'forms' => [
        'driver' => 'local',
        'root' => storage_path('/mnt/data/website/forms'),
     ],
    'logs' => [
        'driver' => 'local',
        'root' => storage_path('/mnt/shared/logs'),
     ],
  ],
];

With that done we end up with the folder structure below in persistent storage:

• Directorymnt/website/shared/

  • Directoryforms/

    • …
  • Directoryimg-cache/ » public/img-cache

    • …
  • Directorylogs/

    • …

These folders and any files they container will accessible by all future deploys, and our image directory can be served to the browser, ensuring we’re not having to generate new images each deploy.