Installing Gleyk on-prem: overview
Requirements, the component set, choosing between Docker Compose and Kubernetes, where to place the GPU server with the model and where to get the full installation guide.
Gleyk is installed inside the customer's perimeter: on a single server or in a Kubernetes cluster. This article gives the general picture. The step-by-step procedure with commands, checks and runbooks is in the Installation guide (76 pages), and an interactive choice of the option is in the wizard Deploy Gleyk on-prem.
Requirements
Minimum resources for installation on a single server:
| Resource | Minimum | For operation |
|---|---|---|
| CPU | 4 cores | from 8 cores, more for parallel document processing |
| Memory | 16 GB | from 32 GB, depends on recognition tools and models |
| Disk | 50 GB | from 200 GB on a separate reliable volume |
| OS | 64-bit Linux x86-64 | Astra Linux Special Edition 1.7 and 1.8, RED OS 7.3 and 8.0 are supported |
In addition: Docker with docker compose support, the system parameter vm.max_map_count of at least 262144, free ports 80 and 443, a domain name and a certificate from a trusted certificate authority, time synchronization. For a cluster the minimum values do not apply: resources are calculated separately for the application services and for each storage, based on the number of users, the volume of documents and the processing queue.
Component set
| Component | Purpose | Persistent data |
|---|---|---|
| Server side (backend) | Screen forms, API, application operations | Settings and object relations in PostgreSQL |
| Job worker | Text extraction, chunking, background jobs | Job state in PostgreSQL and the temporary storage |
| Web interface and entry service | Publishing the interface and the API over HTTPS | Certificates, does not store user data |
| PostgreSQL | Accounts, organizations, settings, job state | Critical data, must be backed up |
| Object storage MinIO or S3 | Source documents and derived files | Critical user files |
| Temporary storage Valkey (Redis-compatible) | Queues, sessions, short-lived state | Does not replace a backup |
| Document store | Search representations and indexes | Infinity by default, Elasticsearch and OpenSearch are allowed |
| Account service | Sign-in, SSO, roles | The service data is included in the backup |
| Model service | Generation, embeddings, reranker | An external service or a separate GPU workload; not part of the standard package |
Increasing the number of backend instances does not remove the single point of failure in the database or storage. For a production environment, each storage needs an external fault-tolerant service, or an approved clustered setup, or an explicitly accepted recovery time from a backup.
Docker Compose or Kubernetes
A single server, Docker Compose. The package contains the docker/ directory with the files docker-compose.yml, docker-compose-base.yml, .env, a settings template and scripts for starting and migrating. It suits a pilot, a small organization and a test environment. All storages run as a single instance.
A Kubernetes cluster or Deckhouse Kubernetes Platform. The cluster package contains a Helm chart and the values file values-production.yaml: the number of backend instances and workers, the classes and sizes of persistent volumes, ingress and TLS, the account service settings, the audit log retention period and the volume for the model cache. Choose a cluster if you need several instances of the application services, distribution across nodes and the platform's standard monitoring and backup tools.
After the OS is prepared, the installation order is the same for any option: verify the checksums of the package, replace all demo passwords, set the model addresses and the external address, start the services, perform the first sign-in of the main administrator, create an organization, connect the models, upload a control document and run a control search.
Warning
The ports of the database, the search, object and temporary storages are not published to external networks. Only the entry address over HTTPS is available from the user network. Secrets are not stored in container composition files or in a version control system.
Model: your own GPU or an external API
If the platform calls an external model service (through a gateway, with a provider allowlist and data transfer rules), GPU accelerators are not required on the Gleyk nodes. If the model is hosted inside your perimeter, it is designed as a separate workload: GPU nodes, drivers, a persistent model cache and a calculation of device memory. The platform works with vLLM and other OpenAI-compatible servers, as well as with Ollama, Xinference, LocalAI and similar. A model is connected in the "Model providers" section by specifying the base URL, the model name and the maximum context size. The embedding model is not changed after chunks are created without reprocessing the knowledge bases.
Isolated environment
For a perimeter without internet access, images with checksums, OS packages, model files and recognition dictionaries are transferred in advance. Before strict offline mode is turned on, the processing of a control document is checked with external access fully disconnected.
After installation
Mandatory checks: the sign-in page opens in Russian, the certificate is valid, the "Admin Console" is available to the main administrator, an organization can be created, a document is processed to the "SUCCESS" state, the control search returns the expected fragment, the sign-in event appears in the log, and the data persists after a restart. Then set up backups (a full copy weekly, changes daily, a trial restore quarterly) and alerts on disk space, memory, restarts and certificate expiry.
Next: Organizations, roles and access, Connecting 1C via OData, all guides in the Documents section.
Ask Sema