Operation and administration

Alcilla.Desk can be operated on a single workstation, within a company infrastructure, or in conjunction with Alcilla.Station. The specific operational effort depends on the scope of functions, number of users, and selected operating model.

Which components are part of an Alcilla environment?

Basic components

A basic installation requires:

• a suitable workstation, server, or virtual machine,
• a permanently writable storage area with sufficient capacity,
• the required file permissions for the Alcilla process,
• at least one compatible AI model endpoint, such as Ollama, an internal model server, or Alcilla.Station,
• approved data sources, such as document folders or email accounts,
• the required network, proxy, and certificate approvals for configured external or central services.

Optional components

Depending on the scope of functions, additional services may be required:

Not every component has to run on the same system. Models and compute-intensive services can be provided centrally, for example, while personal working data remains on the workstation.

Installation and configuration

Alcilla is supplied as an executable application. It must be placed on the intended workstation, made executable if necessary, and then started.

Initial configuration is performed through an integrated setup assistant.

For subsequent operation, the deployed version, storage locations, permissions, connected services, network approvals, backup, and recovery arrangements should be documented in particular.

Updates and model changes

Updates should first be tested in an appropriate test or pilot environment. Backing up the relevant configuration and working data before an update is recommended.

After an update, at least the following should be verified:

• application startup and availability,
• connection to the AI models,
• access to the knowledge index,
• email and calendar synchronization,
• optionally configured services,
• sign-in and permissions in centralized operation,
• key user workflows.

If the embedding model used for semantic search is changed, the entire knowledge index must be rebuilt. Changing only the chat model normally does not require rebuilding the index.

Storage requirements

Storage is required for more than the application itself. Depending on the configuration, the following may be stored locally or centrally:

• configuration and access information,
• the database and knowledge index,
• processed documents,
• locally synchronized emails and attachments,
• notes and chat histories,
• recordings, transcripts, and minutes,
• Kanban boards and card content,
• research results and case information,
• locally installed AI models.

Very large mailboxes, audio recordings, document archives, and local model files can significantly increase storage requirements.

Backup

Depending on the enabled functions, Alcilla stores configuration, local databases, index data, and working content in the configured storage directories.

The following may be particularly relevant when integrating Alcilla into existing backup procedures:

• configuration and the separate secrets area,
• local databases and the knowledge index,
• notes, chat histories, and Kanban data,
• Recorder content and minutes,
• converted documents and local email data.

The operating company’s requirements determine which directories are backed up and which recovery objectives apply. Some derived data, such as the knowledge index, can be rebuilt. However, rebuilding may require considerable time and compute resources.

Monitoring and troubleshooting

Alcilla displays status information and ongoing operations within the application. The logging level can be adjusted in the application settings. Alcilla does not transmit product telemetry. Central monitoring must therefore be deliberately integrated into the existing operating environment when required.

Notes on secure operation

In the standard local operating mode, Alcilla is provided exclusively through 127.0.0.1. If the application is to be accessible over the network, access must be secured in accordance with the existing company infrastructure. An unsecured or unapproved deployment outside the intended operating model is the responsibility of the operator. Alaska.Labs accepts no liability for damage, data loss, or unauthorized access resulting from improper or inadequately secured network or internet exposure.

An encrypted connection and suitable central authentication are intended for centralized operation. Implementation is the operator’s responsibility.

Further technical information is available under Security and data protection.