default.yaml

#
#                ______    _________        _          ______
#  {__}        .' ____ \  |  _   _  |      / \       .' ___  |         {__}
#   \/_____!   | (___ \_| |_/ | | \_|     / _ \     / .'   \_|    !_____\/
#     \----|    _.____`.      | |        / ___ \    | |   ____    |----/
#     /|   |\  | \____) |    _| |_     _/ /   \ \_  \ `.___]  |  /|   |\
#               \______.'   |_____|   |____| |____|  `._____.'
#
# Stag can do all sorts of wonderful things but you need to configure a few
# things to make it happen.
#
# DISCLAIMER: stag is still in beta mode. If you're not comfortable on the
# command line or ssh'n into your server. If you don't know how to do that,
# stag might not be for you just yet.
#
# SO PROCEED AT YOUR OWN RISK!
#
# That being said, I am using it in a production environment successfully. So
# if you still want to move forward, let's get started.
#
# Copy this whole file and dump it into _config/add-ons/stag.yaml
#
# *= SERVERS =*
#
# stag can talk to your servers, no matter how many you've got. For most
# commands, you will need ssh access. The deployment and pull content commands
# are configured here as well as they might be different for each server.
#
# This is specific to each server, so there are no defaults.
servers:
# Uncomment the following and fill your server's info
# production: # The name of the server to use with stag
#   host: example.com # The host to ssh into
#   webroot: /var/www/example.com/public # The webroot of your site
#   user: deploy # SSH username
#   password: password # DEPRECATED: Please use ftp_password
#   ftp_password: passwod # Your FTP password; Only if you're using ftp
#   port: 22 # SSH port; Don't need it if it's the default
#   forward_agent: true # Recommended if you're using git for deployments
#   strategy: git # You can set this to git, rsync or ftp
#   repo_url: git@github.com:example.git # If using git as your strategy, set the ssh repo url
#
#   === DEPLOY ===
#   You can have deploy pull_content, clear cache, and set permissions during
#   the deployment task. Each strategy will have a few different options. Use
#   the following configurations as guides for your preferred strategy.
#
#   == GIT ==
#   deploy:
#     pull_content_before: true
#     clear_cache_after: true
#     set_permissions_after: false
#     update_submodules: false
#
#   == RSYNC ==
#   deploy:
#     pull_content_before: true
#     clear_cache_after: true
#     set_permissions_after: false
#     ignore_files:
#       - .git
#       - _cache
#       - _logs
#
#   == FTP ==
#   deploy:
#     pull_content_before: true
#     clear_cache_after: true
#     set_permissions_after: true
#     ignore_files:
#       - .git
#       - _cache
#       - _logs
#
#   === PULL CONTENT ===
#   This will pull your content down from the server. You can choose between
#   git, ftp or rsync.
#
#   == GIT ==
#   pull_content:
#     commit_message: "Content update from production"
#
#   == RSYNC ==
#   pull_content:
#     content_directories:
#      - _content
#      - assets
#
#   == FTP ==
#   pull_content:
#     content_directories:
#      - _content
#      - assets
#
# *= CLEAR CACHE =*
# When in doubt clear the cache out.
# stag will clear the directories in the _cache folders that you specify. The
# only reason you'd need to change the defaults is if you're storing other
# things in the cache that need clearing. If you have a server configured,
# it'll clear cache there too!
clear_cache:
  directories:
    - _app
    - _add-ons

# *= SET PERMISSIONS =*
# stag will set permissions for you. If you have a server configured, it'll
# even ssh in and try and update permissions there too!  The defaults might do
# ya fine, but by all means, change away my sysadmin friend.
set_permissions:
  site_permissions: 755 # This will be run first on the whole site directory
  writable_permissions: 775 # Will be run after to set the writable directories
  writable_directories: # A list of the writable directories; Statamic defaults
    - _cache
    - _content
    - _logs
    - _config/users