> For the complete documentation index, see [llms.txt](https://docs.syntho.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syntho.ai/deploy-syntho/application-settings.md). # Application settings Application-specific settings for each Syntho module that are not covered elsewhere in the documentation. This page lists environment variables that tune application behavior for each module. Infrastructure settings (ports, database hosts, credentials) are covered in the [Docker Compose](/deploy-syntho/deploy-syntho-using-docker.md) and [Kubernetes](/deploy-syntho/deploy-syntho-using-kubernetes.md) deployment guides. ## How to configure ### Docker Compose Add variables to the `.env` file at the root of your deployment directory. Docker Compose picks them up automatically. ```bash # .env DATABRICKS_READ_STMT_MAX_ATTEMPTS=15 LOG_LEVEL=WARNING ``` ### Kubernetes (Helm) The Helm chart uses different schemas depending on the service. **Core API and Backend** — set variables under the service's `env:` map in `values.yaml`: ```yaml # values.yaml core: env: MAX_RUNNING_JOBS: "8" CANCEL_TIMEOUT: "120" backend: env: SESSION_AGE: "1800" DATA_ACCESS: "False" ``` **Core (Ray)** — Ray uses the KubeRay chart with a standard Kubernetes env list under `head.containerEnv:` and `worker.containerEnv:`: ```yaml # ray values.yaml head: containerEnv: - name: DATABRICKS_READ_STMT_MAX_ATTEMPTS value: "15" - name: LOG_LEVEL value: "WARNING" worker: containerEnv: - name: DATABRICKS_READ_STMT_MAX_ATTEMPTS value: "15" - name: LOG_LEVEL value: "WARNING" ``` *** ## Core | Name | Default | Description | | ----------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `LOG_LEVEL` | `INFO` | Log verbosity. Accepted values: `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL`. Falls back to `INFO` if the value is invalid. | | `DATABRICKS_READ_STMT_MAX_ATTEMPTS` | `10` | Maximum number of polling attempts when waiting for a Databricks SQL statement to finish executing. If the statement has not succeeded after this many attempts, the read fails with an error. Must be a positive integer. | | `DATABRICKS_READ_STMT_INITIAL_WAIT` | `2` | Base wait time in seconds used for the exponential backoff between polling attempts. The wait after attempt *n* is `initial_wait ** n` seconds (e.g. with the default of `2`: 2 s, 4 s, 8 s, …). Must be a positive integer. | | `NULL_MASK_PLACEHOLDER` | `###` | Placeholder substituted for `NULL` in the consistent-mapping hash source, so that `NULL` rows map consistently. | *** ## Core API | Name | Default | Description | | --------------------------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MAX_RUNNING_JOBS` | `6` | Maximum number of data generation jobs that can run in parallel. Also determines the default `CELERY_WORKER_CONCURRENCY`. | | `CELERY_WORKER_CONCURRENCY` | `MAX_RUNNING_JOBS + 2` | Number of Celery worker processes, i.e. how many background tasks the worker runs at the same time. When raising it, also raise the worker memory limit (roughly 0.5 GB + 0.2 GB per process + headroom). | | `CELERY_WORKER_MAX_MEMORY_PER_CHILD_KB` | `700000` | Memory (KiB) above which a Celery worker process is replaced after finishing its current task. Must stay well above the \~370 MB a process uses at start-up, otherwise processes are replaced after every task. | | `CELERY_WORKER_MAX_TASKS_PER_CHILD` | `500` | Number of tasks after which a Celery worker process is replaced. | | `CELERY_WORKER_PREFETCH_MULTIPLIER` | `1` | Number of tasks each Celery worker process reserves ahead of time. | | `CANCEL_TIMEOUT` | `60` | Default timeout in seconds for cancellable blocking operations (used as the fallback for `run_cancellable`). Affects any operation that wraps a blocking call with a cancellation guard. | | `FILE_SYSTEM_MAX_SIZE` | `104857600` | Maximum allowed size in bytes for a single file upload when using the filesystem connector (default: 100 MB). | | `FILE_SYSTEM_MAX_FILES` | `2` | Maximum number of files allowed per filesystem connector upload. | | `STREAMING_MAX_BYTES` | `524288` | Maximum bytes per chunk when streaming data (default: \~512 KB). | | `STREAMING_MAX_ROWS` | `2000` | Maximum rows per chunk when streaming data. Also controls database `yield_per` batch size. | | `STREAMING_MAX_INTERVAL_MS` | `400` | Flush cadence in milliseconds for streaming responses. | | `FEATURE_CHAT_ASSISTANT` | `False` | Enable the AI chat assistant feature. | | `FEATURE_KEY_GENERATION_GENERATE` | `False` | Show Generate in workspace mode form along with other key generation methods | ### Job log retention and recovery `JOB_LOG_BACKEND` defaults to `redis`. Complete per-job streams have no TTL or MAXLEN trimming until the final PostgreSQL ZIP archive commits. Active downloads build read-only ZIP snapshots without saving intermediate database attachments. The final archive is created only after log producers finish; failed archives retain their Redis streams for retry. Active ZIP snapshots are staged in memory up to 8 MiB, then spill to ephemeral local temporary files; provision writable temporary storage for concurrent downloads. This is not a persistent/shared log volume. The snapshot lock is released before HTTP streaming, and staged files are closed on completion, cancellation, or failure. Snapshot reading and compression hold the job lock until staging completes, which can delay final archival for large logs; network delivery does not hold that lock. | Name | Default | Description | | ----------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `LOG_UPLOAD_INTERVAL_SECONDS` | `60` | Legacy setting name retained for compatibility. Controls the periodic final-log recovery and orphan-cleanup sweep, not active or intermediate uploads. The Celery schedule is named `recover-final-job-logs`. | `JOB_LOG_TTL_SECONDS` and `JOB_LOG_STREAM_MAXLEN` are obsolete and no longer control retention. Provision Redis memory for the full logs of every unarchived job, including long-running jobs and archive retries, plus queues, status data, and Redis overhead. Bounded reads/compression avoid keeping the complete uncompressed log in application memory, but the final compressed ZIP must still fit because it is stored as a single PostgreSQL BYTEA. Redis persistence and capacity are deployment settings, not Core API environment variables. See [Docker Compose Redis configuration](/deploy-syntho/deploy-syntho-using-docker.md#redis-persistence-and-sizing) or [Helm Redis configuration](/deploy-syntho/deploy-syntho-using-kubernetes.md#redis-persistence-and-sizing), including [expansion of an existing Redis PVC](/deploy-syntho/deploy-syntho-using-kubernetes/operations.md#resize-the-redis-data-pvc). *** ## Backend | Name | Default | Description | | --------------------------------- | ------------------- | ------------------------------------------------------------------------------- | | `SESSION_AGE` | `900` | Session lifetime in seconds (default: 15 minutes). | | `SESSION_EXPIRE_AT_BROWSER_CLOSE` | `FALSE` | When `TRUE`, the session ends when the browser is closed. | | `DATA_ACCESS` | `TRUE` | When `TRUE`, users have access to source data by default. | | `EMAIL_LOGIN_ENABLED` | `FALSE` | Allow users to log in with email and password when SSO is also enabled. | | `EXTRA_ALLOWED_HOSTS` | `backend localhost` | Space-separated list of additional hostnames the service accepts requests from. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.syntho.ai/deploy-syntho/application-settings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.