^Status|Draft|
^Todo|Content Review and additions|

====== Deploying Kohana to Production: =====
Here are a few items you should keep in mind before deploying your Kohana application to a production environment.


===== Production Mode =====
Kohana offers a single declaration to change between production and development mode. This is defined at the top of index.php:

<code php>
define('IN_PRODUCTION', FALSE);
</code>

By setting this to ''TRUE'', you automatically disable all module demonstration controllers and the default Kohana welcome page. This "toggle" can also be set using a test case. For example, if you wanted ''IN_PRODUCTION'' to be turned off for "localhost", you could do this:

<code php>
define('IN_PRODUCTION', (strpos($_SERVER['SERVER_NAME'], 'localhost') === FALSE));
</code>

Or, if you wanted to only enable production mode for your live website:

<code php>
define('IN_PRODUCTION', (strpos($_SERVER['SERVER_NAME'], 'example.com') !== FALSE));
</code>

Of course, you can always set this to ''TRUE'' or ''FALSE'' manually, for maximum performance. Generally, using a test case is suitable for "live testing" of new applications. On a high-traffic website, a manual setting would be beneficial.



===== Update Your Configuration Files =====
Kohana provides various default configuration files in the ''system/config'' directory.  Since Kohana utilizes a [[:general:filesystem|cascading file system]], you have the option to either utilize the default configuration file versions or override these files with your own custom versions by creating a copy in the ''application/config'' directory. There are some files that **must** be updated. Read this list carefully!

<box round>
**Note:** A "enabled" configuration option means a setting of ''TRUE'', and a "disabled" configuration option means a setting of ''FALSE''.
</box>


==== config.php ====

     * Change ''site_domain'' from your development setting to the production domain.
     * Disable ''display_errors'' disable error messages from being displayed. Errors will still be logged, but a simple, generic error will be displayed instead.
     * Enable ''global_xss_filtering'', unless you are doing manual [[wp>Cross-site_scripting|XSS]] filtering.

For slightly higher performance, you can also enable the ''output_compression'' option. Using a setting of 4-6, or ''TRUE'' will result in a balanced optimization.


==== log.php ====

It is recommended to set your log ''threshold'' option to ''1'', to enable error logging. If you set ''threshold'' to ''0'', no error logs will not be written!


==== routes.php ====

Make sure to set the ''_default'' to your default controller route. This can be a single name, or a full URI route.


==== database.php ====

If your application uses a database, update the options to match your production database.


==== cookie.php ====

Change options to match your production server settings. Always set the ''domain'' option to match your production server name. If wish to have your cookie readable on all sub-domains, add an extra period before the domain name, ''.example.com'' instead of ''example.com''.

It is also recommended to set the ''expire'' option to a non-zero value, because it can result in sessions that never expire. A value of ''7200'' (2 hours) is generally safe.

If your website only runs under ''https://'', you should also enable the ''secure'' option.


==== session.php ====

Update the session ''name'' and ''driver'' options. If you use the database driver, make sure the session tables are installed in your production database.

If you use the ''cookie'' driver, it is strongly recommended to enable the ''encryption'' option.


==== encryption.php ====

If you use the [[libraries:Encrypt|Encryption]] library anywhere, be sure to set a new ''key''. Remember that all previous encrypted data will become unreadable when the ''key'' changes!


==== auth.php ====

If you use the [[addons:Auth|Auth]] module, be sure use a non-default ''salt_pattern''. Remember that all previous passwords will be come unreadable, and will have to be reset, when the ''salt_pattern'' changes!


===== Protect Kohana Directories =====
<box round>
If your host does not allow this structure, you can also [[http://kohanaphp.com/tutorials/remove_index.html|use an .htaccess file]] to protect the Kohana directories.
</box>

Although this is an optional step and not required by Kohana, it is considered a good security practice to place as few files as possible in your public web server document root directory.  Since most web hosts give you access to at least one level above the web server document root, this should not be a problem.

Moving your core Kohana directories also gives you the ability to utilize one central Kohana codebase on your server that can be shared by multiple websites.  You could also create a set of common modules used across all of your web sites.

To accomplish this in Kohana, do the following:

     - move your Kohana ''system'', ''application'', and ''modules'' directories at least one level above your document root directory (typically ''public_html'' or ''www'').
     - modify the following lines in your ''index.php'' file:   
        * ''$kohana_application = '../application';''
        * ''$kohana_modules = '../modules';''
        * ''$kohana_system = '../system';''

**Note:** This example assumes one-level above ''public_html'', however, you can use relative or absolute directories when specifying directory locations.

Your final directory structure will look similar to this:

     yourdomain_root_directory
     +- application
     +- system
     +- modules
     +- public_html (web server document root)
      |    - index.php
      |    - .htaccess