Otter Documentation

Architecture & Components

  • Last Modified: 2018-05-17

Otter is comprised of several different components, which may be installed on different servers. See the installation guides for more details.

Web Application

This is how most users will interact with Otter on a day-to-day basis, and manages the servers, plans, security, users, etc., and also hosts the API.

It is a standard ASP.NET application, and administrators familiar with IIS may tweak the application pool settings as needed. Note that modifying the web.config file for any purpose other than to change the database connection string or encryption key is not at all supported.


This runs in the background and actually runs your configuration and orchestration plans using the execution engine. It's a standard Windows Service Application, and may be managed and configured using the Windows Service Manager or sc.exe as you see fit.

Note that modifying the Otter.Service.config file for any purpose other than to change the database connection string or encryption key is not at all supported.

The Service page details how to administer this further.


This persists all the configuration data, execution logs, job schedules, users, etc.

It is a standard SQL Server database, and administrators familiar with SQL Server may tweak the database settings as needed.


Sensitive data, most notably resource credentials, are encrypted before being stored. Obviously, the encryption key is not stored in the database, but in both the web.config file (used by the web application) and the Otter.Service.config file (used by the service).


Experienced users are welcome to query data from the various tables, and sensitive information resource credentials are stored encrypted, and can only be decrypted by the service account. The tables/columns should be fairly obvious once you're familiar with the software, and we can answer any questions you may have about the data or relations.

We do not support... nay, we strongly discourage trying to modify any of the data in the tables directly. Instead, use the API or the non-internal Stored Procedures.


Agents are a lightweight service that are installed on remote servers that you want to configure and orchestrate. They use a highly-optimized and resilient protocol, and are secured (by default) using a FIPS-compliant symmetric AES encryption scheme.

Agents may also be configured to use SSL instead of built-in AES, see KB#1040 for those instructions.

More on this topic:

Have a question? Try the Q&A Forum

Our documentation is now Open Source and on GitHub. We highly encourage our users to contribute and get involved! .