# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://scriptables.gitbook.io/scriptables-documentation/under-the-hood.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.