Deployment Options
==================

CodeScene runs anywhere a modern Java Virtual Machine (JVM) runs.
We test the tool on Mac OS, Windows, and various Linux distributions.

You can run CodeScene on your own server or choose from many popular cloud providers like AWS or Azure.
When considering a fully-managed solution like Azure App Service
keep in mind that CodeScene needs a **fast and reliable file storage** to operate properly.
See also the *System Requirements* section.

You can also deploy CodeScene via AWS Marketplace - see :doc:`Deploy CodeScene on AWS Marketplace <aws-marketplace>` for more details.


System Requirements
-------------------

The requirements change with the size and history of the codebase you want to analyze.

**Physical memory and fast disk IO** are the most critical resources on the server:

- **4+ GB of RAM** - we recommend adjusting the default Java heap size via `-Xmx` or `-XX:MaxRAMPercentage`.
  See :ref:`configure-memory` for more details.
- **Fast (SSD) disk** - crucial for analyzing large repositories with deep history.

  * **Do not use shared/distributed file storage** like *Azure Files*, *Amazon EFS*, or *NFS*!
    Our experience shows that this leads to **serious performance problems**
    and sometimes to stability issues (internal application errors due to the CodeScene database
    being hosted on a distributed file system).
    For this reason, you should **avoid hosting CodeScene on platforms like Azure App Service, Azure Containers, or (AWS) Lambda.**
- **4 or more vCPUs** are recommended

  * Some parts of the CodeScene analysis pipeline are run in parallel
  * You can configure CodeScene to run :doc:`multiple concurrent analysis </configuration/concurrent-analyses>` as well.

Serverless solutions like `AWS Lambda <https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html>`_
are also a poor fit for CodeScene due to max running time limitations and, again, reliance on distributed file system.


Public Cloud (AWS, Azure, et. al.)
----------------------------------

For performance and stability reasons outlined in the *System Requirements* section we don't recommend
using managed services like *Azure App Service* or `Azure Containers <https://azure.microsoft.com/en-us/product-categories/containers/>`_
that rely on distributed file storage.

The recommended option is to deploy a **plain Linux VM** and run CodeScene with Docker as described in :doc:`Installation </getting-started/installation>`.

Security - HTTPS & SSL/TLS certificates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If your instance is open to the general public, using HTTPS is important.
CodeScene itself uses HTTP so you need to put another layer in front of it.

This can be done by using a proxy like *nginx* (see `our example repo <https://github.com/empear-analytics/docker-codescene-nginx-self-signed-ssl>`_)
or by using your cloud provider's offering,
e.g. `AWS Beanstalk and ACM <https://aws.amazon.com/premiumsupport/knowledge-center/elastic-beanstalk-https-configuration/>`_
or `Azure Key Vault <https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-secure-web-server>`_.

Another popular option for SSL certificates is the *Let's Encrypt* certification authority
which makes it easy to renew certificates automatically - you can find more details about this option
in `our docker repository <https://github.com/empear-analytics/docker-codescene-nginx-self-signed-ssl#prepare-the-host-and-reverse-proxy-configuration-for-letsencrypt-ssl-certificate>`_.

Backups
-------

You should backup your **CodeScene database** regularly (see :ref:`db-backup` for description of various backup options).

Cloned repositories and analysis results may be recreated by running a new analysis.

