Automation Anywhere Enterprise Knowledge On-Premises FAQs

Refer to this FAQ for common questions and detailed answers regarding the On-Premises deployment of the Automation Anywhere Enterprise Knowledge platform ranging from the definition and architecture of On-Premises, to infrastructure requirements, deployment processes, security considerations, and more.

Deployment

Will the Enterprise Knowledge On-Premises installation support installation on AWS, GCP, Azure or bare metal and virtual machines such as VMWare?

Yes, we have the necessary specifications for both Production and Development environments across these platforms.

Do I still need to use Automation 360 Cloud although I prefer to use Automation Anywhere Enterprise Knowledge On-Premises? Or, can I build my nativeAutomation 360 Cloud equivalent environment in a completely closed premises?

There is no On-Premises deployment of the Automation 360 cloud with Kubernetes, Pod Services, and API services. Enterprise Knowledge can be deployed either On-Premises or in the cloud as SaaS. The product itself is the same and can be used in conjunction with both an Automation 360 cloud environment and an Automation 360 On-Premises environment.

Who deploys the On-Premises environment?

The initial installation is a collaborative effort between the Enterprise Knowledge SMEs and you. You will need to provide SSH and network access to the designated deployment machine(s). If direct access cannot be granted, you will need to assign technical resources who possess the required access. The Enterprise Knowledge SMEs can then guide these resources remotely via screen sharing. You are responsible for provisioning the necessary machine(s). The initial installation and subsequent updates will be completed through a series of sessions involving downloading, deploying, and configuring the software. The installation script will incorporate CI/CD connections to retrieve assets, perform installation, configure the system, deploy the components, and enable future updates. It's important to note that installation and updates are not something you will directly manage.

Do you have any estimates on how long it takes to deploy a working system?

Deployment can vary from approximately 4 hours to 2 weeks, depending on your specific environment and requirements. Sometimes, we do run into roadblocks like SSL certificates or someone not having full access to the network to make changes, and so on. But, in an ideal scenario, around 4 hours to finalize and test.

Which node accepts the SSL certificates for incoming connections?

Most deployments will require SSL, but it might not be implemented during the initial deployment. The server can be deployed without SSL and configured later. The specific deployment ports outlined in the architecture diagram indicate where SSL certificates will need to be applied.

Are scripts used to install?

Yes, Terraform scripts are currently utilized to install all components. These scripts streamline the installation process and ensure consistent, repeatable results.

Are there shared storage requirements?

No, shared file storage is not required. The Docker containers and other services use the local scratch disk and the PostgreSQL database for all storage needs.

Is SSD disk required?

Yes, an SSD (Solid State Drive) is a requirement. Databases, particularly vector databases due to their size, are highly sensitive to disk latency. Any delay in disk access will negatively impact performance.

Is NAS possible?
No, Network Attached Storage (NAS) is not suitable. NAS involves shared disk accessed over a network. Even if partitioned and provisioned via iSCSI, the inherent network latency and rotational latency of traditional hard drives (typically 2.5 to 5 times slower access than SSD) make it unsuitable for the performance requirements.
Are there any limitations on features for On-Premises?
There are no inherent feature limitations in the On-Premises deployment. Capabilities such as crawling and Single Sign-On (SSO) are fully supported. Access to internal resources can necessitate white-listing specific IP addresses or domains within your network. Enabling the Document Editor and Support logging are optional configurations. The "Actions" functionality can also be selectively enabled or disabled. It's worth noting that highly restricted air-gapped environments with no internet access can experience limitations in utility beyond local network functionalities.
There are several optional items. Does not using them reduce the machines needed?
No, the inclusion or exclusion of optional features does not impact the required number of machines.
The sentry signaling machine is marked optional, what does it do?
The sentry signaling machine, if enabled, provides detailed debugging information via logging, which is valuable for support purposes. When used, it is typically collocated with other components.
The document editor is optional, what does it do and is it collocated?
Yes, the document editor is an optional feature and is a function integrated within the console. It provides web socket functionality for real-time document editing. The web socket server supports this feature and can be leveraged for future web socket-based actions. While the editor might not be frequently used, it allows a user with rights to directly type and edit documents within the system as an activity to add to the Knowledge Base (KB). If the primary source of knowledge is uploaded or crawled data, the document editor is largely unnecessary. The Docker container hosting the editor can be collocated with other components. However, a best practice for adding knowledge involves posting the document file to a standard shared content location and then uploading it to the KB from that known point, either through web crawling or an automated process.
Are LLMs provided?
No, Large Language Models (LLMs) are not directly provided with the On-Premises deployment. However, built-in connections are included, allowing the use of credits (similar to the cloud offering). In most On-Premises deployments, it is anticipated that you will use custom LLM connections, leveraging your own Bring Your Own Key (BYOK) arrangements.
How does On-Premises deployment affect the use of credit or BYOK GenAI consumption?
You have the option to use built-in credits for accessing LLMs. However, for cost-effective and scalable use of LLMs, and to leverage your existing relationships with hyperscalers or other GenAI LLM vendors, most will likely employ a Bring Your Own Key (BYOK) model for hosting LLMs. In such cases, white-listing outbound connections to the respective LLM service providers will be necessary within your network.
How is scaling handled beyond the large fully distributed deployment?
Fully distributed and scaled deployments currently apply only to the cloud offering, not to On-Premises. While a larger cloud deployment would involve scaling out pod servers and iterating Docker containers, the following considerations apply to On-Premises:
  • In the majority of cases, an On-Premises deployment for you is a single machine.
  • The detailed architectural components are primarily for understanding the overall structure, and most are not directly interacted with after the initial deployment.
  • Scaling beyond the large fully distributed level is not currently supported for On-Premises deployments.
  • High Availability (HA) and Disaster Recovery (DR) are not supported out-of-the-box for On-Premises.

Architecture

What is the architecture for On-Premises?
The On-Premises architecture is based on Dockers and a Database. It does not use pre-built static Docker images but instead employs Docker and docker-compose for orchestration.
What database is used?

The database used is PostgreSQL, which has been modified to function as a vector index store, known as Supabase. This customized database will be built according to the specified requirements using the provided installation script.

Is the database a freestanding server, or can it be RDS, Azure, or otherwise cloud provisioned?

The database must be a free-standing server and needs to be initiated as a Virtual Machine (VM). It cannot be replaced by managed cloud database services such as AWS RDS Aurora, Azure Database for PostgreSQL, or similar cloud-provisioned offerings. The database server is a core component of the entire deployment and requires hands-on configuration to become a fully functional Supabase node.

How do we get Postgres to become Supabase? We have not heard about Supabase

Yes, the database must reside on its own dedicated server within the architecture. Supabase can be understood as PostgreSQL with enhanced capabilities. Therefore, you cannot directly convert an existing managed PostgreSQL instance or any other type of database into Supabase. However, migrating data from one to the other is possible. The Supabase instance requires full hands-on management.

Are hyperscaler provisioned PostgreSQL databases a good starting point?

No. The database requires specific modifications that necessitate direct access and control. Managed services like AWS RDS offer a more abstracted, sliced usage of PostgreSQL deployment and do not provide the level of customization required to transform it into Supabase. Supabase needs to be deployed on a VM, whether hosted on a hyperscaler platform or on local infrastructure.

What Access Ports are used?

The following ports need to be whitelisted for your users and automations accessing the Enterprise Knowledge server: 80 (HTTP), 443 (HTTPS), 8000 (HTTP/HTTPS web sockets), 8443 (HTTP/HTTPS web sockets), and 1234 (web sockets). It is crucial to ensure that no application-level (Layer 7) firewalls are blocking access for users or bots within your network. Note that in single-machine deployments, the Supabase VM and Docker containers must be able to communicate fully. Similarly, in larger, distributed deployments, all machines need to have unrestricted internal communication.

Is SSL Supported?

Yes, SSL (Secure Sockets Layer) is supported. This requires an SSL Certificate associated with the host or domain name. Here are the general steps for SSL configuration within your environment:

  • Add a record in your DNS that resolves the Fully Qualified Domain Name (FQDN) hostname to the designated IP Address.
  • You can generate a temporary, self-signed SSL certificate using tools like certbot for initial testing. However, for production environments, we strongly recommend providing a valid SSL certificate and private key for the FQDN hostname.
  • Place the SSL certificate and key files onto that machine within the /nginx-proxy/ssl/ folder.
  • Once these steps are completed, notify the Enterprise Knowledge SME team so they can finalize the necessary configurations on the Nginx proxy to point to the correct SSL files.
  • If the front-end Docker container is deployed separately from the Supabase VM, a separate set of certificate and key files should be created for the front-end.
What ports are used within the solution components?
Table 1.
Purpose Path Parameter Internal* External HTTP HTTPS WSS/WS
Frontend /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
Backend /api BACKEND_SUFFIX 8001 X x
Automator /automator AUTOMATOR_SUFFIX 8002 x X
Redis 6379 x X
RabbitMQ 5672, 15672 x x
Document Editor /ws WEBSOCKET_SUFFIX 1234 1234 x x x
Supabase Kong API Gateway /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x
Supabase Postgres 6543 x x
PostgreSQL (automator) 5433 x x
Redis (automator) 6380 x x
Ollama 11434 x x ****

* All internal machines must be able to communicate freely with each other

** admin only

*** We recommend using SSL (https) connections, but we can support http connections for PoCs

**** Only applies if deploying Ollama locally

What ports do clients (human, bots, API) use?

Clients only use 80/443. Other ports are for internal communication and administration and deployment. Nginx proxies all access and egress.

What allowed methods need to be enabled within my network?
Some networks turn on APP filtering with layer 7 app layer via firewalls, app accelerators, and some switches. It is important to allow the following methods for the solution within your network:
  • GET
  • POST
  • PUT
  • DELETE
  • OPTIONS
If the system uses SSO, automator, or crawling, which node initiates the call from?
SSO, like client access, is a front-end service. With SSO, this process continues with the authentication service, and if the authentication request is successful, it then connects via webhook, completing authentication and generating a token for further use.
Crawling is a back-end service, and all inbound/outbound traffic is handled by the back-end End Server.
Automator is a back-end service, and all inbound/outbound traffic is handled by the Front End Server.
Can Enterprise Knowledge use forward proxies?

Yes. Nginx proxies all inbound and outbound traffic. It is your network, so configure it to allow and permit traffic end-to-end for this to work.

What about SSH Management?
SSH access to the deployment box (main database machine) will be necessary for our technical resources to perform installation, updates, and any required troubleshooting.
To facilitate this access:
  • You need to configure the necessary SSH keys and network access for our specific resources on the base machines.
  • If your team cannot provide direct access, we require designated technical resources from your team. These resources must have the necessary access. They must be available when needed for installation, updates, and troubleshooting.
  • Our Enterprise Knowledge SME resources and your technical resources will collaborate closely. They will coordinate the required steps. You can achieve this coordination through IT shared access, such as a shared screen meeting.
  • Coordinated technical sessions can take time. Downloading and running longer deployment scripts take time. Support from our Enterprise Knowledge SMEs will likely involve multiple sessions. Therefore, the designated resources should be prepared to start, pause, continue, and stop as needed.
Is data encrypted at rest and in-flight?
Yes, SSL and TLS 1.2 are used for data in transit.
Yes, AES 256 is used for data at rest. Furthermore, it is possible to generate and set an encryption key for OnPrem installations as part of the initial setup script.
How can SSO be applied?
SSO is supported via protocols such as Okta, Azure AD, and SAML 2.0.
What provides High Availability (HA)?
A key consideration for OnPrem deployments is that your IT team is responsible for managing network outages and ensuring High Availability (HA). The Enterprise Knowledge installation, particularly for setups exceeding a single server, does not include built-in fault tolerance. Therefore, a sizing exercise is essential to design an appropriate architecture that scales and meets your HA requirements.
What needs to be backed up?
Everything—the configuration and parameters—is stored in the database. A scheduled backup of the database will handle both backup and restore operations.
Are Docker images currently used?
Docker images are not currently used directly. However, Docker images can be assembled as the docker-compose files are available.
What enables any Docker auto-scaling?
Docker containers are used for deployments, requiring Docker v27.1.1 or above. The sizing exercise with the SME team will determine if the solution requires sizing with auto-scaling for the API and workers, as well as any distribution of servers towards a fully distributed deployment.
Do customers need a Docker registry?
No.