docs/template-requirements.md

Rama main · réplica de lectura del repositorio original.

# Template setup requirements

Reviewed on 13 September 2026 against official setup documentation and, where useful,
the pinned release's configuration source. Image pins are unchanged. This review
checks configuration requirements; it does not expand the runtime claims in the
[template guide](templates.md#verification).

| Template | Required configuration and runtime findings | Sources |
| --- | --- | --- |
| PostgreSQL | The official image requires `POSTGRES_PASSWORD`. `POSTGRES_USER` creates the initial superuser; `POSTGRES_DB` chooses the initial database. These variables apply only to an empty data directory. PostgreSQL 17 keeps the existing `/var/lib/postgresql/data` mount and explicit `PGDATA`. The form guides database/user names and a private password reference. | [Official image documentation](https://github.com/docker-library/docs/blob/master/postgres/README.md) |
| Valkey | Private network access plus `requirepass` protects the default user. AOF and a 64 MiB data budget are explicit in the template; no eviction means writes can fail when full. A strong password is generated or supplied, never placed directly in TOML. | [Security](https://valkey.io/topics/security/) |
| Redis | The template uses authenticated private access and AOF. `requirepass` covers the default user; applications needing separate ACL users must configure those inside Redis. Review the Redis 8 license and capacity before production use. | [Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/) |
| MySQL | `MYSQL_ROOT_PASSWORD` initializes root; `MYSQL_USER`, `MYSQL_PASSWORD` and `MYSQL_DATABASE` create the application database/account. Initialization does not rotate an existing database's credentials. Hakopod rejects the root username for the application account and requires distinct root/application passwords. | [Official image documentation](https://github.com/docker-library/docs/blob/master/mysql/README.md) |
| CockroachDB | Secure startup requires a CA certificate plus matching node certificate/private key. The node certificate needs the node principal, service DNS names and both server/client authentication. Hakopod verifies the chain, validity, key pair, `main` and `localhost`. SQL administration still needs a separate client certificate. This is one secure node, with no HA claim. | [Docker setup](https://www.cockroachlabs.com/docs/stable/start-a-local-cluster-in-docker-linux), [Certificates](https://www.cockroachlabs.com/docs/stable/create-security-certificates-openssl) |
| ClickHouse | Network access must use a password. This preset supplies its own bounded XML configuration and hashed password for the `default` user; it does not depend on the image's first-start user environment variables. It exposes private HTTP 8123, not native TCP. Persistent storage and memory/CPU limits remain explicit. | [Official container guide](https://github.com/ClickHouse/ClickHouse/blob/master/docker/server/README.md) |
| Metabase | Production application metadata belongs in PostgreSQL rather than the embedded H2 database. The preset wires `MB_DB_*` to its private database and now supplies `MB_ENCRYPTION_SECRET_KEY` for saved connection credentials. Keep the key with backups. An existing Metabase requires the documented encryption migration; this form creates a new application. `MB_SITE_URL` is optional. | [Docker setup](https://www.metabase.com/docs/latest/installation-and-operation/running-metabase-on-docker), [Credential encryption](https://www.metabase.com/docs/latest/databases/encrypting-details-at-rest) |
| Infisical | Standard deployment requires a 16-byte hexadecimal `ENCRYPTION_KEY`, 32-byte Base64 `AUTH_SECRET`, `DB_CONNECTION_URI`, `REDIS_URL` and stable `SITE_URL`. The FIPS key format differs and is not selected here. Hakopod builds and verifies the private database/Redis URLs against their saved passwords. PostgreSQL and the encryption key must be backed up together. Optional SMTP and external integrations remain operator configuration. | [Environment variables](https://infisical.com/docs/self-hosting/configuration/envars) |
| Open WebUI | Authentication requires a stable `WEBUI_SECRET_KEY`. The chosen OpenAI-compatible endpoint, API key and model are explicit. Optional `WEBUI_URL` supplies the canonical origin. SQLite/data files persist; the first administrator still completes upstream setup. Local Ollama and automatic local weight downloads stay disabled. Optional embedding/audio providers may need separate configuration inside Open WebUI. | [Pinned authentication environment](https://github.com/open-webui/open-webui/blob/v0.11.3/backend/open_webui/env.py), [Pinned provider configuration](https://github.com/open-webui/open-webui/blob/v0.11.3/backend/open_webui/config.py) |
| Flowise | The pinned example supports `FLOWISE_SECRETKEY_OVERWRITE`, session/JWT/token-hash secrets, persistent SQLite/blob/key paths, `APP_URL` and secure cookies. Hakopod supplies five stable secret references and a required HTTPS origin. Set up the first administrator, model nodes, provider credentials and prediction API protection inside Flowise. Persist keys with data. | [Pinned environment reference](https://github.com/FlowiseAI/Flowise/blob/flowise%403.1.4/docker/.env.example) |
| Uptime Kuma | Persist `/app/data`; the upstream guide explicitly excludes NFS. No shared starter password is installed. Complete the first administrator and configure monitors and notification credentials inside the application. | [Official setup guide](https://github.com/louislam/uptime-kuma#how-to-install) |
| Gitea | The rootless image uses UID/GID 1000 and persistent data/configuration. SQLite is supported for this single instance. HTTP Git is enabled; SSH is disabled. Optional `ROOT_URL` sets clone links and callbacks. Administrator setup, mail and any OAuth integration still require application configuration. | [Rootless container](https://docs.gitea.com/installation/install-with-docker-rootless), [Configuration reference](https://docs.gitea.com/administration/config-cheat-sheet) |
| vLLM | Serving requires a compatible GPU/driver/device plugin, model storage, an immutable model revision and inference API key. The runtime accepts `HF_TOKEN` for approved private/gated access; the form now supports that reference. GPU workloads already receive a private 1 GiB shared-memory mount. The current pinned image targets CUDA 13 and NVIDIA SBSA on ARM64. No model is downloaded during planning and no remote model code is enabled. | [Container deployment](https://docs.vllm.ai/en/stable/deployment/docker/), [Environment variables](https://docs.vllm.ai/en/stable/configuration/env_vars/) |
| xem.email | The official chart still requires a frontend built for the installation's public API origin plus API, PostgreSQL and Redis configuration. JWT, session, RSA encryption, administrator and SMTP credentials must be private and installation-specific. The catalog remains a prerequisite guide until a matching frontend artifact is supplied and verified. | [Official Kubernetes guide](https://github.com/mailxem/devops/blob/main/docs/kubernetes.md), [Detailed reviewed pins and requirements](templates-xem.md) |

Generated values are cryptographically random. Local passwords require at least
16 characters; signing/encryption token inputs require at least 32 unless an
upstream format is stricter. Provider keys are checked for shape, not remotely
validated or billed by Hakopod. Stored values are never returned by the secret API.
Only scoped references appear in reviewed TOML and deployment history.

Focused tests cover the fourteen-entry catalog, TOML round trips, input validation,
credential formats, certificate verification, URL/password consistency, scoped
secret reads, generation without accidental replacement, and durable deployment
acceptance after review. Actual external provider access, SMTP delivery, new domain
DNS/TLS setup, larger application runtime behavior and GPU execution still require
their target environments. No messages, model requests or provider API charges were
made for this review.