> For the complete documentation index, see [llms.txt](https://scriptables.gitbook.io/scriptables-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://scriptables.gitbook.io/scriptables-documentation/under-the-hood.md).

# Under the hood

When a build starts, Scriptables will connect to your server via SSH using a Golang SSH client. 

The builder will then find modules matching the "server type" or "site type" or in the case of servers - you can run more than one module by specifying a comma-separated list of modules in the "Scriptables" input form field. 

Modules are a folder of bash scripts found in the **scriptables/** folder. This is the actual code that is run on deploys and server builds. The "server type", "site type" or "Scriptables" field values are the module names, lower-cased, and underscored.

Each module has a series of bash scripts named with a prefix "**xyz\_**" - where **xyz** is a 3-digit number e.g.: 001, 002, 003, and so forth. This prefix controls the order in which the scripts are run - i.e. from the lowest number to the highest number.

Here is a breakdown of the folder structure:

1. **\_\_shared** - this is where you should put any code you wish to share with other modules. You can then import this code inside other modules using: ***SCRIPTABLE::IMPORT modulename*** . 

       e.g. scriptables/\_\_shared/auth.sh would be: ***SCRIPTABLE::IMPORT auth***
2. **cache, MySQL, Laravel, lemp,nginx** - these are all server and app templates. In the dashboard, if you choose "LEMP" - then the code in the **lemp** folder will be run to set up your server. The same applies to Nginx, MySQL, and so forth.
3. **\_deploy** - this is a push to deploy module for your application type. For example, if your application type is "Laravel", on the first build - the module "Laravel" is run to set up and configure the site. After the first build, when you trigger a deployment from either Git webhooks or manually - the builder will look for a folder named "laravel\_deploy", which only does the steps needed to update the app such as: pull, migrate, and clear cache.

A typical bash script looks like the following:

```
#!/bin/bash
# exit-on-failure=yes

cd  #USER_DIRECTORY#/#SITE_SLUG#
sudo  -u  #SITE_SLUG# GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -i #KEY_PATH#" git pull
sudo  -u  www-data  php#PHP_VERSION#  artisan  config:clear
sudo  -u  www-data  php#PHP_VERSION#  artisan  cache:clear
sudo  -u  www-data  php#PHP_VERSION#  artisan  view:clear
sudo  -u  #SITE_SLUG# php#PHP_VERSION# /usr/bin/composer.phar install
sudo  -u  #SITE_SLUG# php#PHP_VERSION# artisan migrate
```

On line 2 - exit-on-failure, does just that. When a line fails - the build will just stop at that line and mark the build as a failure. 

If this is set to no, the builder will try to continue with the script. If a serious failure occurs, the Script can still exit on failure anywhere, so in most instances it's better to just leave this on.

You will notice variables starting with the hash **#** symbol e.g. **php#PHP\_VERSION#.** These are automatically replaced on build, by the values you filled in the forms via the interface.