Deployment methods

Universal Apps offer three methods to deploy and access code:

  1. SFTP — legacy upload style
  2. Git — advanced: push to deploy
  3. SSH — advanced tasks and deployment

The different deployment methods work side by side. This articles explains how they interact, what you need to know when mixing methods and give tips for best practices.

Understanding the architecture

# Universal App deployment architecture
                                                         │ website users │
                                                          http requests
                            │fortrabbit App                     │         │
                            │                                   │         │
┌────────────────┐          │┌─────────────────┐         ┌──────▼────────┐│
│ local Git repo ├─Git push─┼▶ remote Git repo ├──rsync──▶  web storage  ││
└────────────────┘          │└─────────────────┘         └──────▲────────┘│
                            │                                   │         │
                            │                                   │         │
                                                          │ developer │

What the web storage contains

Please keep in mind, that the Git repo is not the web storage. After you Git push, first the Git repo will be updated, then changes will be synchronized (overwrite but not delete) to the web storage. So the web storage contains:

  1. The latest changes from Git
  2. Changes from SFTP & SSH
  3. Uploads from website users

Git works only one way

You can not pull the changes, which are made via SSH or SFTP, from the web storage back into your Git repo. While this might looks odd at first: this design keeps your Git repo clean of temporary, binary and other blob data. Use Git only for code deployment, not to manage all of your Apps runtime data.

Git push overwrite but not deletes

When you push new changes via git to your App Composer will be executed. In addition, user defined scripts (either specified via deployment file or Composer scripts) might also be executed. Resulting of the push and the executions, a temporary file set is generated and subsequently synchronized to your App's web storage. Since you also can access your App via SSH/SFTP, the web storage can contain files which are not in Git, nor generated by the scripts. The strategy applied in the synchronization is:

  • Files existing in the temporary file set and existing on the web storage will be overwritten
  • Files existing in the temporary file set but not existing on the web storage will be created
  • Files not existing in the temporary file set but existing on the web storage will not be touched

Not all applications work well with Git

Git deployment is great when your App skeleton has clean folder structure with exclude patterns and Composer support. Laravel and Symfony are poster childs for good Git support. WordPress and other CMS are not Git compatible, out-of-the-box (while good hacks are available).

Further readings

Need individual help?

Get support › Learn about Company plans ›

Looking for an old article?

See the full list of articles ›

Found an error?

Contribute on GitHub ›