Working with data

Most applications need to store data in some shape or form, whether it's a database, flat file or a cloud-based storage service. This section explains how to manage persistent data on Magelify.

Stateless containers

Deployments on Magelify are per definition stateless, meaning the container file system is ephemeral and any file changes will be lost during a container restart. This is radically different from a traditional server-centric model where data is written to a local disk.

Stateless deployments have many advantages:

• Containers are immutable (read-only) which greatly reduces the attack surface and possible exploits;
• Containers are portable and can quickly move between nodes in case of hardware failure or scheduled maintenance;
• Containers are horizontally scalable out of the box as they are effectively stateless.

However, it also enforce some constraints on how you design your application architecture and storage layer. Most importantly,

The only exception is for storing temporary files or debugging, and you don't care if the data gets deleted.

The recommended way to manage data in modern cloud-native apps (aka Twelve-Factor) is to use external cloud storage such as Amazon S3 or Google Cloud Storage, but this is not always feasible.

Stateful applications

Many web application and databases still depends on a filesystem for persistent storage, including widely used ones such as Wordpress.

To accommodate stateful workloads Magelify supports persistent volumes, a software defined storage solution that offers reliable, persistent cloud storage that looks and behaves just like a locally mounted filesystem.

Volumes supports replication and zero-downtime failover, and they "move" with the application if a container is rescheduled to a different node.

Shared volumes

By default a volume can only be mounted to a single instance of an application at the same time. Shared volumes enables simultaneous read/write access to a single volume from multiple apps/instances, possibly running on different nodes.

Example use cases include:

• Scaling a web app across multiple instances while using a single volume for file storage
• Writing application logs to a central location
• Enable shared (global) state between applications

Shared volumes is integral to how Magelify enables horizontal scaling of stateful apps such as Magento and Wordpress.

Snapshots

Volumes support point-in-time snapshots for backup and disaster recovery. See Create a snapshot for more details.

SFTP

To transfer files to and from your volumes you can use SFTP or the rsync / scp command line utilities. There are many SFTP clients available for every operating system, such as FileZilla and WinSCP.

You can obtain your SFTP connection details from the Site Dashboard under the Settings tab.

The SFTP hostname is the same for every site within the same cluster, while each environment is assigned a unique port number.

Unified login

All site collaborators with developer role or higher can access SFTP using their Magelify account credentials. The following authentication methods are supported:

• Email/password authentication (if not using Google/Github social login)
• SSH key authentication
• Access token authentication

This allows a user to access all their sites using the same credentials provided they have the necessary permissions.

External users

Magelify also supports the notion of external SFTP users. These are additional username/password-based credentials that can be used to grant temporary access or simplify integrations with 3. party systems, etc.

Click on Add a new user to bring up the "Add SFTP user" dialog, and fill in the following information:

• Username: an arbitrary name for this user (minimum 4 characters)
• Password: the account password (minimum 6 characters)
• Home directory: set if user should be restricted to a sub directory (defaults to app root)
• Permissions: whether user can both upload (write) and download (read) files

When you connect to the SFTP server, you'll be able to see all the files and directories as projected in the container. This includes the container file system itself (files part of the build image) and any mounted volumes.

Make sure that you only upload data to a directory that is backed by a persistent volume