# 🐳 Docker Guide — OmniRoute (ਪੰਜਾਬੀ)

🌐 **Languages:** 🇺🇸 [English](../../../../guides/DOCKER_GUIDE.md) · 🇪🇹 [am](../../../am/docs/guides/DOCKER_GUIDE.md) · 🇸🇦 [ar](../../../ar/docs/guides/DOCKER_GUIDE.md) · 🇦🇿 [az](../../../az/docs/guides/DOCKER_GUIDE.md) · 🇧🇬 [bg](../../../bg/docs/guides/DOCKER_GUIDE.md) · 🇧🇩 [bn](../../../bn/docs/guides/DOCKER_GUIDE.md) · 🇧🇦 [bs](../../../bs/docs/guides/DOCKER_GUIDE.md) · 🇨🇿 [cs](../../../cs/docs/guides/DOCKER_GUIDE.md) · 🇩🇰 [da](../../../da/docs/guides/DOCKER_GUIDE.md) · 🇩🇪 [de](../../../de/docs/guides/DOCKER_GUIDE.md) · 🇬🇷 [el](../../../el/docs/guides/DOCKER_GUIDE.md) · 🇪🇸 [es](../../../es/docs/guides/DOCKER_GUIDE.md) · 🇪🇪 [et](../../../et/docs/guides/DOCKER_GUIDE.md) · 🇮🇷 [fa](../../../fa/docs/guides/DOCKER_GUIDE.md) · 🇫🇮 [fi](../../../fi/docs/guides/DOCKER_GUIDE.md) · 🇫🇷 [fr](../../../fr/docs/guides/DOCKER_GUIDE.md) · 🇮🇪 [ga](../../../ga/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [gu](../../../gu/docs/guides/DOCKER_GUIDE.md) · 🇳🇬 [ha](../../../ha/docs/guides/DOCKER_GUIDE.md) · 🇮🇱 [he](../../../he/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [hi](../../../hi/docs/guides/DOCKER_GUIDE.md) · 🇭🇷 [hr](../../../hr/docs/guides/DOCKER_GUIDE.md) · 🇭🇺 [hu](../../../hu/docs/guides/DOCKER_GUIDE.md) · 🇦🇲 [hy](../../../hy/docs/guides/DOCKER_GUIDE.md) · 🇮🇩 [id](../../../id/docs/guides/DOCKER_GUIDE.md) · 🇳🇬 [ig](../../../ig/docs/guides/DOCKER_GUIDE.md) · 🇮🇹 [it](../../../it/docs/guides/DOCKER_GUIDE.md) · 🇯🇵 [ja](../../../ja/docs/guides/DOCKER_GUIDE.md) · 🇬🇪 [ka](../../../ka/docs/guides/DOCKER_GUIDE.md) · 🇰🇭 [km](../../../km/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [kn](../../../kn/docs/guides/DOCKER_GUIDE.md) · 🇰🇷 [ko](../../../ko/docs/guides/DOCKER_GUIDE.md) · 🇱🇹 [lt](../../../lt/docs/guides/DOCKER_GUIDE.md) · 🇱🇻 [lv](../../../lv/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [ml](../../../ml/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [mr](../../../mr/docs/guides/DOCKER_GUIDE.md) · 🇲🇾 [ms](../../../ms/docs/guides/DOCKER_GUIDE.md) · 🇲🇹 [mt](../../../mt/docs/guides/DOCKER_GUIDE.md) · 🇲🇲 [my](../../../my/docs/guides/DOCKER_GUIDE.md) · 🇳🇵 [ne](../../../ne/docs/guides/DOCKER_GUIDE.md) · 🇳🇱 [nl](../../../nl/docs/guides/DOCKER_GUIDE.md) · 🇳🇴 [no](../../../no/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [or](../../../or/docs/guides/DOCKER_GUIDE.md) · 🇵🇭 [phi](../../../phi/docs/guides/DOCKER_GUIDE.md) · 🇵🇱 [pl](../../../pl/docs/guides/DOCKER_GUIDE.md) · 🇵🇹 [pt](../../../pt/docs/guides/DOCKER_GUIDE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/guides/DOCKER_GUIDE.md) · 🇷🇴 [ro](../../../ro/docs/guides/DOCKER_GUIDE.md) · 🇷🇺 [ru](../../../ru/docs/guides/DOCKER_GUIDE.md) · 🇱🇰 [si](../../../si/docs/guides/DOCKER_GUIDE.md) · 🇸🇰 [sk](../../../sk/docs/guides/DOCKER_GUIDE.md) · 🇸🇮 [sl](../../../sl/docs/guides/DOCKER_GUIDE.md) · 🇷🇸 [sr](../../../sr/docs/guides/DOCKER_GUIDE.md) · 🇸🇪 [sv](../../../sv/docs/guides/DOCKER_GUIDE.md) · 🇰🇪 [sw](../../../sw/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [ta](../../../ta/docs/guides/DOCKER_GUIDE.md) · 🇮🇳 [te](../../../te/docs/guides/DOCKER_GUIDE.md) · 🇹🇭 [th](../../../th/docs/guides/DOCKER_GUIDE.md) · 🇹🇷 [tr](../../../tr/docs/guides/DOCKER_GUIDE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/guides/DOCKER_GUIDE.md) · 🇵🇰 [ur](../../../ur/docs/guides/DOCKER_GUIDE.md) · 🇺🇿 [uz](../../../uz/docs/guides/DOCKER_GUIDE.md) · 🇻🇳 [vi](../../../vi/docs/guides/DOCKER_GUIDE.md) · 🇳🇬 [yo](../../../yo/docs/guides/DOCKER_GUIDE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/guides/DOCKER_GUIDE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/guides/DOCKER_GUIDE.md)

---

> Docker ਡਿਪਲੌਇਮੈਂਟ ਦਾ ਸੰਪੂਰਨ ਹਵਾਲਾ। ਤੁਰੰਤ ਸ਼ੁਰੂਆਤ ਲਈ, [README ਦਾ Docker ਭਾਗ](../README.md#-docker) ਵੇਖੋ।

## ਵਿਸ਼ਾ-ਸੂਚੀ

- [ਤੁਰੰਤ ਚਲਾਓ](#quick-run)
- [ਇਨਵਾਇਰਨਮੈਂਟ ਫ਼ਾਈਲ ਨਾਲ](#with-environment-file)
- [Docker Compose](#docker-compose)
- [ਉਪਲਬਧ ਪ੍ਰੋਫ਼ਾਈਲ](#available-profiles)
- [ਜਦੋਂ OmniRoute Docker ਵਿੱਚ ਚੱਲਦਾ ਹੋਵੇ ਤਾਂ ਹੋਸਟ CLI ਟੂਲਾਂ ਦੀ ਸੰਰਚਨਾ](#configuring-host-cli-tools-when-omniroute-runs-in-docker)
- [Redis ਸਾਈਡਕਾਰ](#redis-sidecar)
- [ਪ੍ਰੋਡਕਸ਼ਨ Compose](#production-compose)
- [Dockerfile ਪੜਾਅ](#dockerfile-stages)
- [ਅਹਿਮ ਇਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ](#critical-environment-variables)
- [Caddy (HTTPS) ਨਾਲ Docker Compose](#docker-compose-with-caddy-https-auto-tls)
- [Cloudflare ਤੁਰੰਤ ਟਨਲ](#cloudflare-quick-tunnel)
- [ਇਮੇਜ ਟੈਗ](#image-tags)
- [Docker ਵਿੱਚ ਡੈਸ਼ਬੋਰਡ ਅੱਪਡੇਟ](#dashboard-updates-in-docker)
- [ਉਪਲਬਧਤਾ: ਮੂਲ SQLite ਸਿਰਫ਼ ਇੱਕ ਰੈਪਲਿਕਾ ਲਈ ਹੈ](#availability-default-sqlite-is-single-replica)
- [Docker ਦੇ ਅੰਦਰ Gemini ਖੇਤਰੀ ਤਰੁੱਟੀਆਂ](#gemini-regional-errors-inside-docker)
- [ਮਹੱਤਵਪੂਰਨ ਨੋਟ](#important-notes)

---

## ਤੁਰੰਤ ਚਲਾਓ

> **ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਖੁਦ ਹੋਸਟ ਕਰਨਾ ਹੈ?**
> [ਸੈਲਫ਼-ਹੋਸਟ ਗਾਈਡ](../getting-started/SELF_HOST_GUIDE.md) ਵੇਖੋ —
> `docker compose -f docker-compose.selfhost.yml up -d` (ਪ੍ਰਕਾਸ਼ਿਤ ਇਮੇਜ +
> Redis, ਸਿਰਫ਼ ਲੂਪਬੈਕ, ਕੋਈ ਪ੍ਰੋਫ਼ਾਈਲ ਚੋਣ ਨਹੀਂ)। ਹੇਠਾਂ ਦਿੱਤਾ ਤੁਰੰਤ ਚਲਾਉਣ ਦਾ ਤਰੀਕਾ
> ਉਹਨਾਂ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਸਿੰਗਲ-ਕੰਟੇਨਰ ਮਾਰਗ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ Redis ਨੂੰ ਕਿਸੇ ਹੋਰ ਥਾਂ ਚਲਾ ਰਹੇ ਹਨ।

```bash
docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --stop-timeout 40 \
  -p 20128:20128 \
  -v omniroute-data:/app/data \
  diegosouzapw/omniroute:latest
```

## ਇਨਵਾਇਰਨਮੈਂਟ ਫ਼ਾਈਲ ਨਾਲ

```bash
# ਪਹਿਲਾਂ .env ਨੂੰ ਕਾਪੀ ਅਤੇ ਸੋਧੋ
cp .env.example .env

docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --stop-timeout 40 \
  --env-file .env \
  -p 20128:20128 \
  -v omniroute-data:/app/data \
  diegosouzapw/omniroute:latest
```

## Docker Compose

```bash
# ਬੇਸ ਪ੍ਰੋਫ਼ਾਈਲ (ਕੋਈ CLI ਟੂਲ ਨਹੀਂ)
docker compose --profile base up -d

# CLI ਪ੍ਰੋਫ਼ਾਈਲ (Claude Code, Codex, OpenClaw ਬਿਲਟ-ਇਨ)
docker compose --profile cli up -d

# ਹੋਸਟ ਪ੍ਰੋਫ਼ਾਈਲ (ਮੁੱਖ ਤੌਰ 'ਤੇ Linux ਲਈ; ਹੋਸਟ CLI ਬਾਈਨਰੀਆਂ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ ਢੰਗ ਨਾਲ ਮਾਊਂਟ ਕਰਦਾ ਹੈ)
docker compose --profile host up -d

# ਵੈੱਬ ਪ੍ਰੋਫ਼ਾਈਲ (ਵੈੱਬ-ਸੈਸ਼ਨ ਪ੍ਰਦਾਤਾਵਾਂ ਲਈ Chromium/Playwright)
docker compose --profile web up -d

# CLI + CLIProxyAPI ਸਾਈਡਕਾਰ ਨੂੰ ਜੋੜੋ
docker compose --profile cli --profile cliproxyapi up -d
```

## ਉਪਲਬਧ ਪ੍ਰੋਫ਼ਾਈਲ

OmniRoute ਮੁੱਖ ਡਿਪਲੌਇਮੈਂਟ ਰੂਪਾਂ ਲਈ Compose ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਆਪਣੇ ਇਨਵਾਇਰਨਮੈਂਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਪ੍ਰੋਫ਼ਾਈਲ ਚੁਣੋ।

| ਪ੍ਰੋਫ਼ਾਈਲ     | ਸਰਵਿਸ            | ਕਦੋਂ ਵਰਤਣਾ ਹੈ                                                                                                                                        | ਕਮਾਂਡ                                        |
| ------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| `base` (ਮੂਲ)  | `omniroute-base` | ਹੈੱਡਲੈੱਸ ਸਰਵਰ / ਘੱਟੋ-ਘੱਟ ਰਨਟਾਈਮ, ਕੋਈ ਪ੍ਰਦਾਤਾ CLI ਬੰਡਲ ਨਹੀਂ                                                                                           | `docker compose --profile base up -d`        |
| `cli`         | `omniroute-cli`  | `omniroute providers/setup/doctor` ਅਤੇ ਬੰਡਲ ਕੀਤੇ CLI (Codex, Claude Code, Droid, OpenClaw) ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੇ ਏਜੰਟਿਕ ਵਰਕਫ਼ਲੋ                           | `docker compose --profile cli up -d`         |
| `host`        | `omniroute-host` | ਉਹ Linux ਹੋਸਟ ਜੋ `~/.local/bin`, `~/.codex`, `~/.claude` ਆਦਿ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ ਢੰਗ ਨਾਲ ਮਾਊਂਟ ਕਰਕੇ ਹੋਸਟ CLI ਤੱਕ `network_mode`-ਵਰਗੀ ਪਹੁੰਚ ਚਾਹੁੰਦੇ ਹਨ | `docker compose --profile host up -d`        |
| `cliproxyapi` | `cliproxyapi`    | ਅੱਪਸਟ੍ਰੀਮ CLI ਪ੍ਰੌਕਸੀ ਲਈ ਪੋਰਟ `8317` ਉੱਤੇ [CLIProxyAPI](https://github.com/router-for-me/CLIProxyAPI) ਸਾਈਡਕਾਰ ਚਲਾਓ                                   | `docker compose --profile cliproxyapi up -d` |
| `web`         | `omniroute-web`  | ਉਹ ਵੈੱਬ-ਸੈਸ਼ਨ ਪ੍ਰਦਾਤਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਚਾਹੀਦਾ ਹੈ: `gemini-web`, `claude-web`, `claude-turnstile` (`runner-web` ਬਣਾਉਂਦਾ ਹੈ, Chromium ਸ਼ਾਮਲ ਹੈ)    | `docker compose --profile web up -d`         |

> ਕਈ ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਨੂੰ ਇਕੱਠੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ: `docker compose --profile cli --profile cliproxyapi up -d`।

## ਜਦੋਂ OmniRoute Docker ਵਿੱਚ ਚੱਲਦਾ ਹੋਵੇ ਤਾਂ ਹੋਸਟ CLI ਟੂਲਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਨੀ

`omniroute setup-codex`, `setup-claude`, `config set <tool>` ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਦਾ
**ਸੰਰਚਨਾ ਸੰਭਾਲੋ** ਬਟਨ ਸਾਰੇ `~/.codex/*.config.toml` ਵਰਗੀਆਂ ਫ਼ਾਈਲਾਂ ਲਿਖਦੇ ਹਨ। ਉਹ ਪਾਥ
ਸਿਰਫ਼ ਉਸ ਮਸ਼ੀਨ ਉੱਤੇ ਅਰਥ ਰੱਖਦੇ ਹਨ ਜਿੱਥੇ CLI ਅਸਲ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ
ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਚਲਾਉਣ ਨਾਲ ਲਿਖਤ ਕੰਟੇਨਰ ਦੇ ਆਪਣੇ ਹੋਮ (`/home/node` —
ਇਮੇਜ `USER node` ਵਜੋਂ ਚੱਲਦਾ ਹੈ) ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਜਿੱਥੋਂ ਕੋਈ ਵੀ ਹੋਸਟ CLI ਇਸਨੂੰ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹੇਗਾ ਅਤੇ ਕੰਟੇਨਰ
ਮੁੜ ਬਣਾਏ ਜਾਣ ਦੇ ਪਲ ਹੀ ਇਹ ਮਿਟ ਜਾਂਦੀ ਹੈ।

OmniRoute ਇਸਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਅਤੇ ਅਜਿਹੀ ਸਫਲਤਾ ਰਿਪੋਰਟ ਕਰਨ ਦੀ ਬਜਾਏ, ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਰਤ ਨਹੀਂ ਸਕਦੇ,
ਹਦਾਇਤਾਂ ਦੇ ਨਾਲ ਲਿਖਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ: CLI `2` ਨਾਲ ਬੰਦ ਹੁੰਦਾ ਹੈ ਅਤੇ API `422`
ਦੇ ਨਾਲ `containerEphemeralTarget: true` ਵਾਪਸ ਕਰਦਾ ਹੈ।

### ਸਿਫ਼ਾਰਸ਼ੀ: CLI ਨੂੰ ਹੋਸਟ ਉੱਤੇ ਅਤੇ OmniRoute ਨੂੰ Docker ਵਿੱਚ ਚਲਾਓ

ਕੰਟੇਨਰ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; CLI ਤੁਹਾਡੇ ਹੋਸਟ ਟੂਲਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਦਾ ਹੈ।

```bash
docker compose --profile base up -d

npm install -g omniroute
omniroute connect http://localhost:20128   # CLI ਨੂੰ ਕੰਟੇਨਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਵਾਓ
omniroute setup-codex                      # ਤੁਹਾਡੇ ਹੋਸਟ ਉੱਤੇ ਅਸਲ ~/.codex ਲਿਖਦਾ ਹੈ
```

ਜਦੋਂ Codex, Claude Code, Cursor ਜਾਂ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ ਟੂਲ ਤੁਹਾਡੇ
ਲੈਪਟਾਪ ਉੱਤੇ ਚੱਲਦੇ ਹਨ ਤਾਂ ਇਹ ਸਹੀ ਚੋਣ ਹੈ — ਅਤੇ ਆਮ ਤੌਰ ਉੱਤੇ ਸੈੱਟਅੱਪ ਵੀ ਇਹੀ ਹੁੰਦਾ ਹੈ।

### ਵਿਕਲਪ: ਹੋਸਟ ਸੰਰਚਨਾ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ bind-mount ਕਰੋ (`host` ਪ੍ਰੋਫ਼ਾਈਲ)

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕੰਟੇਨਰ ਖੁਦ ਤੁਹਾਡੀ ਹੋਸਟ ਸੰਰਚਨਾ ਲਿਖੇ, ਤਾਂ
ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਅੰਦਰ ਮਾਊਂਟ ਕਰੋ ਅਤੇ `CLI_CONFIG_HOME` ਨੂੰ ਮਾਊਂਟ ਰੂਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਵਾਓ। `host` ਪ੍ਰੋਫ਼ਾਈਲ
ਪਹਿਲਾਂ ਹੀ ਇਹ ਕਰਦਾ ਹੈ:

```yaml
environment:
  - CLI_CONFIG_HOME=/host-home
  - CLI_ALLOW_CONFIG_WRITES=true
volumes:
  - ~/.codex:/host-home/.codex:rw
  - ~/.claude:/host-home/.claude:rw
```

bind mount ਹੀ ਪਾਥ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: OmniRoute
`/proc/self/mountinfo` ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਮਾਊਂਟ ਕੀਤੇ ਪਾਥਾਂ (ਅਤੇ ਉਹਨਾਂ ਡਾਇਰੈਕਟਰੀਆਂ,
ਜਿਨ੍ਹਾਂ ਦੇ ਚਾਈਲਡ ਮਾਊਂਟ ਹਨ, ਜੋ ਉੱਪਰ ਦਿੱਤੇ `/host-home` ਦੇ ਰੂਪ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਖਾਂਦਾ ਹੈ) ਉੱਤੇ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ
ਮਾਊਂਟ ਨਾ ਕੀਤੇ ਪਾਥਾਂ ਲਈ ਅਜੇ ਵੀ ਇਨਕਾਰ ਕਰਦਾ ਹੈ।

### ਬਚਾਅ ਦਾ ਰਸਤਾ: ਕੰਟੇਨਰ ਦੇ ਆਪਣੇ CLIs ਦੀ ਸੰਰਚਨਾ ਕਰੋ (ਸੰਜਮ ਨਾਲ ਵਰਤੋ)

ਜਦੋਂ CLIs ਸੱਚਮੁੱਚ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਹੀ ਮੌਜੂਦ ਹੋਣ (`cli` ਪ੍ਰੋਫ਼ਾਈਲ), ਤਾਂ ਇਹ ਲਿਖਤ
ਜਾਣਬੁੱਝ ਕੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਕਿਸੇ ਵੀ `setup-*` ਕਮਾਂਡ ਨੂੰ `--allow-container-write` ਦਿਓ, ਜਾਂ ਸਰਵਰ ਲਈ
`OMNIROUTE_ALLOW_CONTAINER_CONFIG_WRITE=true` ਸੈੱਟ ਕਰੋ। ਲਿਖਤ ਇਸ ਚੇਤਾਵਨੀ ਨਾਲ ਅੱਗੇ ਵਧਦੀ ਹੈ
ਕਿ ਇਹ ਕੰਟੇਨਰ ਤੋਂ ਬਾਅਦ ਕਾਇਮ ਨਹੀਂ ਰਹੇਗੀ।

> **ਸੁਰੱਖਿਆ ਚੇਤਾਵਨੀ — `cli` ਪ੍ਰੋਫ਼ਾਈਲ + `docker.sock` ਮਾਊਂਟ।**
> `cli` ਪ੍ਰੋਫ਼ਾਈਲ `/var/run/docker.sock` ਨੂੰ bind-mount ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਕੰਟੇਨਰ ਅੰਦਰਲਾ
> ਆਟੋ-ਅੱਪਡੇਟਰ ਹੋਸਟ ਡੀਮਨ ਤੋਂ ਸਟੈਕ ਮੁੜ ਬਣਾ ਸਕੇ
> (`src/lib/system/autoUpdate.ts` ਉਸ ਸਾਕਟ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਇਹ
> ਮੌਜੂਦ ਨਾ ਹੋਵੇ ਤਾਂ Docker ਪਾਥ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ)। ਉਹ ਸਾਕਟ **ਹੋਸਟ-root ਭਰੋਸੇ ਦੀ
> ਸੀਮਾ** ਹੈ: ਜੋ ਵੀ ਇਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਉਹ ਹੋਸਟ Docker ਡੀਮਨ ਨੂੰ
> root ਵਜੋਂ ਚਲਾਉਂਦਾ ਹੈ — ਉਹ ਹੋਸਟ ਉੱਤੇ ਕਿਸੇ ਵੀ ਕੰਟੇਨਰ ਨੂੰ ਬਣਾ, ਜਾਂਚ, ਰੋਕ ਅਤੇ ਹਟਾ ਸਕਦਾ ਹੈ।
> ਪ੍ਰਭਾਵ:
>
> 1. **`cli` ਪ੍ਰੋਫ਼ਾਈਲ ਦਾ ਪੋਰਟ ਕਦੇ ਵੀ ਨੈੱਟਵਰਕ ਉੱਤੇ ਉਪਲਬਧ ਨਾ ਕਰੋ।** ਇਸਨੂੰ
>    `127.0.0.1` ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ (`ports: "127.0.0.1:${DASHBOARD_PORT:-20128}:..."`)
>    — LAN ਤੋਂ ਪਹੁੰਚਯੋਗ `cli` ਪ੍ਰੋਫ਼ਾਈਲ ਕਿਸੇ ਵੀ ਡੈਸ਼ਬੋਰਡ-ਪੱਧਰੀ RCE ਨੂੰ
>    ਪੂਰੇ ਹੋਸਟ ਦੇ ਸਮਝੌਤੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
> 2. **`cli` ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਕੋਈ ਵਾਧੂ ਹੋਸਟ ਡਾਇਰੈਕਟਰੀ bind ਨਾ ਕਰੋ।**
>    Docker ਸਾਕਟ ਦੇ ਨਾਲ ਕੋਈ ਵੀ ਹੋਰ ਮਾਊਂਟ ਕੰਟੇਨਰ ਨੂੰ ਤੁਹਾਡੇ ਫ਼ਾਈਲ-ਸਿਸਟਮ
>    ਅਤੇ ਹੋਸਟ ਸੰਰਚਨਾ ਲਈ ਪੂਰੀ ਪੜ੍ਹਨ/ਲਿਖਣ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਟੂਲ ਨੂੰ
>    ਪ੍ਰੋਜੈਕਟ ਵੇਖਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਨੂੰ CLI ਬਾਈਨਰੀ ਨਾਲ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਚਲਾਓ — ਇਸਨੂੰ
>    `cli` ਕੰਟੇਨਰ ਵਿੱਚ ਮਾਊਂਟ ਨਾ ਕਰੋ।
>
> ਜੇ ਤੁਹਾਨੂੰ ਕੰਟੇਨਰ ਅੰਦਰ ਆਟੋ-ਅੱਪਡੇਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ `cli` ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਬੰਦ ਰੱਖੋ
> (`COMPOSE_PROFILES=core,redis` ਜਾਂ ਇਸ ਤੋਂ ਛੋਟਾ)। ਹੋਰ ਪ੍ਰੋਫ਼ਾਈਲ
> Docker ਸਾਕਟ ਨੂੰ ਮਾਊਂਟ ਨਹੀਂ ਕਰਦੇ।
>
> MITM ਨਾਲ ਸੰਬੰਧਿਤ ਖ਼ਤਰਾ ਮਾਡਲ ਲਈ `docs/security/MITM-TPROXY-DECRYPT.md` (git; `/docs` ਵਿੱਚ ਕੰਪਾਇਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ) ਵੇਖੋ,
> ਅਤੇ `codex`/`claude-code`/`droid`/`openclaw` ਬਾਈਨਰੀ ਦੇ ਸਰੋਤ ਦੀ ਲੜੀ ਲਈ
> `docs/security/SUPPLY_CHAIN.md` ਵੇਖੋ।

## Redis ਸਾਈਡਕਾਰ

OmniRoute ਡਿਸਟ੍ਰਿਬਿਊਟਡ ਰੇਟ ਲਿਮਿਟਰ ਅਤੇ ਸਾਂਝੇ ਕੈਸ਼ ਲਈ Redis 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। `redis` ਸਰਵਿਸ `docker-compose.yml` ਵਿੱਚ **ਹਮੇਸ਼ਾ ਪਰਿਭਾਸ਼ਿਤ** ਹੁੰਦੀ ਹੈ (ਇਸ ਉੱਤੇ ਕੋਈ ਪ੍ਰੋਫ਼ਾਈਲ ਗੇਟ ਨਹੀਂ ਹੈ) ਅਤੇ ਕਿਸੇ ਵੀ ਹੋਰ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।

| ਵੇਰਵਾ                | ਮੁੱਲ                                   |
| -------------------- | -------------------------------------- |
| ਇਮੇਜ                 | `redis:7-alpine`                       |
| ਕੰਟੇਨਰ ਦਾ ਨਾਮ        | `omniroute-redis`                      |
| ਅੰਦਰੂਨੀ ਪੋਰਟ         | `6379`                                 |
| ਹੋਸਟ ਪੋਰਟ (ਓਵਰਰਾਈਡ)  | `REDIS_PORT` (ਡਿਫਾਲਟ `6379`)           |
| ਹੋਸਟ ਬਾਈਂਡ (ਓਵਰਰਾਈਡ) | `REDIS_BIND_HOST` (ਡਿਫਾਲਟ `127.0.0.1`) |
| ਵਾਲਿਊਮ               | `omniroute-redis-data` → `/data`       |
| ਹੈਲਥਚੈੱਕ             | `redis-cli ping` (10s ਦਾ ਅੰਤਰਾਲ)       |

ਸੰਬੰਧਿਤ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ:

- `REDIS_URL` — ਐਪ ਵਿੱਚ ਇੰਜੈਕਟ ਕੀਤੀ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ (ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ `redis://redis:6379`)।
- `REDIS_PORT` — Redis ਕੰਟੇਨਰ ਲਈ ਹੋਸਟ-ਸਾਈਡ ਪੋਰਟ ਮੈਪਿੰਗ।
- `REDIS_BIND_HOST` — ਉਹ ਹੋਸਟ ਇੰਟਰਫੇਸ ਜਿਸ 'ਤੇ ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਡਿਫਾਲਟ `127.0.0.1` ਹੈ।

> **ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਲੂਪਬੈਕ ਕਿਉਂ:** ਸਾਈਡਕਾਰ `requirepass` ਤੋਂ ਬਿਨਾਂ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਐਪ
> ਕੰਟੇਨਰ ਕੰਪੋਜ਼ ਨੈੱਟਵਰਕ (`redis:6379`) ਰਾਹੀਂ ਇਸ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ — ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ
> ਸਿਰਫ਼ ਹੋਸਟ-ਸਾਈਡ ਟੂਲਿੰਗ (`redis-cli`, ਇੱਕ ਲੋਕਲ `npm run dev`) ਲਈ ਹੈ। ਇਸਨੂੰ
> `0.0.0.0` 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਨਾਲ ਬਿਨਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਵਾਲਾ Redis ਤੁਹਾਡੇ LAN ਦੇ ਹਰੇਕ ਹੋਸਟ ਲਈ ਉਪਲਬਧ ਹੋ ਜਾਵੇਗਾ। ਜੇ ਤੁਸੀਂ
> `REDIS_BIND_HOST=0.0.0.0` ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਰਵਿਸ ਦੇ `command:` ਵਿੱਚ `--requirepass` ਵੀ ਸ਼ਾਮਲ ਕਰੋ।

**Redis ਨੂੰ ਅਸਮਰੱਥ ਕਰਨਾ** ਸਿਫ਼ਾਰਸ਼ੀ ਨਹੀਂ ਹੈ (ਰੇਟ ਲਿਮਿਟਰ ਇਨ-ਮੈਮੋਰੀ ਫਾਲਬੈਕ 'ਤੇ ਆ ਜਾਵੇਗਾ)। ਜੇ ਇਹ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਾਂ ਜਾਂ `docker-compose.yml` ਵਿੱਚੋਂ `redis:` ਸਰਵਿਸ ਬਲਾਕ ਹਟਾਓ/ਕਮੈਂਟ ਕਰੋ ਜਾਂ ਇਸਨੂੰ ਸਿਫ਼ਰ ਤੱਕ ਸਕੇਲ ਕਰੋ:

```bash
docker compose up -d --scale redis=0
```

## ਪ੍ਰੋਡਕਸ਼ਨ ਕੰਪੋਜ਼

ਡਿਵੈਲਪਮੈਂਟ ਦੇ ਨਾਲ-ਨਾਲ ਚੱਲਣ ਵਾਲੇ ਇੱਕ ਅਲੱਗ ਪ੍ਰੋਡਕਸ਼ਨ ਸਨੈਪਸ਼ਾਟ ਲਈ `docker-compose.prod.yml` ਵਰਤੋ।

| ਵੇਰਵਾ                | ਮੁੱਲ                                                                                        |
| -------------------- | ------------------------------------------------------------------------------------------- |
| ਫ਼ਾਈਲ                | `docker-compose.prod.yml`                                                                   |
| ਡਿਫਾਲਟ ਡੈਸ਼ਬੋਰਡ ਪੋਰਟ | `PROD_DASHBOARD_PORT=20130` (ਅੰਦਰੂਨੀ `${DASHBOARD_PORT:-20128}` ਨਾਲ ਮੈਪ ਕੀਤਾ)               |
| ਡਿਫਾਲਟ API ਪੋਰਟ      | `PROD_API_PORT=20131`                                                                       |
| ਇਮੇਜ                 | `omniroute:prod` (`runner-cli` ਟਾਰਗੇਟ ਤੋਂ ਬਿਲਡ ਕੀਤਾ)                                        |
| Redis ਕੰਟੇਨਰ         | `omniroute-redis-prod` (`redis:8.6.2`, ਸਮਰਪਿਤ `redis-prod-data` ਵਾਲਿਊਮ)                     |
| ਡਾਟਾ ਵਾਲਿਊਮ          | `omniroute-prod-data` (ਨਾਮਿਤ, ਮੁੜ ਬਿਲਡ ਕਰਨ ਦੌਰਾਨ ਵੀ ਕਾਇਮ ਰਹਿੰਦਾ ਹੈ)                         |
| ਹੈਲਥਚੈੱਕ             | `node healthcheck.mjs` + `redis-cli ping`, ਜਿਸ ਵਿੱਚ `depends_on` Redis ਦੀ ਸਿਹਤ 'ਤੇ ਨਿਰਭਰ ਹੈ |

ਵਰਤਣ ਦਾ ਤਰੀਕਾ:

```bash
# ਪ੍ਰੋਡਕਸ਼ਨ ਸਟੈਕ ਨੂੰ ਬਿਲਡ ਅਤੇ ਸ਼ੁਰੂ ਕਰੋ
docker compose -f docker-compose.prod.yml up -d --build

# ਲੌਗਾਂ ਨੂੰ ਸਟ੍ਰੀਮ ਕਰੋ
docker compose -f docker-compose.prod.yml logs -f

# ਬੰਦ ਕਰੋ (ਵਾਲਿਊਮ ਕਾਇਮ ਰੱਖੋ)
docker compose -f docker-compose.prod.yml down
```

ਪ੍ਰੋਡ ਸਟੈਕ ਡਿਵੈਲਪਮੈਂਟ ਕੰਪੋਜ਼ ਦੇ ਸਮਾਂਤਰ ਚੱਲਦਾ ਹੈ (ਕੰਟੇਨਰਾਂ ਦੇ ਨਾਮ, ਪੋਰਟ ਅਤੇ ਵਾਲਿਊਮ ਵੱਖਰੇ ਹਨ), ਇਸ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਚਾਲੂ ਰੱਖਦੇ ਹੋਏ ਤੁਸੀਂ ਲੋਕਲ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ।

## Dockerfile ਪੜਾਅ

ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਬਹੁ-ਪੜਾਅ Dockerfile (`Dockerfile`) ਸ਼ਾਮਲ ਹੈ। ਚਾਰ ਪੜਾਅ ਉਪਲਬਧ ਹਨ; ਆਪਣੀ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਲਈ ਸਹੀ `target` ਚੁਣੋ।

| ਪੜਾਅ          | ਬੇਸ ਇਮੇਜ              | ਉਦੇਸ਼                                                                                                                                                                                                                                                                                         |
| ------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `builder`     | `node:26-trixie-slim` | ਨਿਰਭਰਤਾਵਾਂ ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ (`npm ci --legacy-peer-deps`) ਅਤੇ `npm run build` ਚਲਾਉਂਦਾ ਹੈ (ਮੂਲ ਰੂਪ ਵਿੱਚ Turbopack — ਹੇਠਾਂ ਬਿਲਡ-ਸਮੇਂ ਦੇ ਸਰੋਤ ਵੇਖੋ)                                                                                                                                                |
| `runner-base` | `node:26-trixie-slim` | Next.js ਦੇ ਸਟੈਂਡਅਲੋਨ ਆਉਟਪੁੱਟ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ ਰਨਟਾਈਮ। **ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ CLI ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ।**                                                                                                                                                                                                       |
| `runner-cli`  | `runner-base`         | `git`, `docker.io`, `docker-compose` ਅਤੇ ਗਲੋਬਲ CLI ਜੋੜਦਾ ਹੈ: `@openai/codex`, `@anthropic-ai/claude-code`, `droid`, `openclaw`। **ਏਜੰਟ-ਅਧਾਰਿਤ ਵਰਕਫ਼ਲੋ ਲਈ ਇਹ ਚੁਣੋ।**                                                                                                                           |
| `runner-web`  | `runner-base`         | ਵੈੱਬ-ਸੈਸ਼ਨ ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ Playwright + ਇੱਕ Chromium ਬ੍ਰਾਊਜ਼ਰ (`--with-deps`) ਜੋੜਦਾ ਹੈ: `gemini-web`, `claude-web`, `claude-turnstile`। **ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਪ੍ਰੋਵਾਈਡਰ ਵਰਤਦੇ ਹੋ ਤਾਂ ਇਹ ਚੁਣੋ** — ਇਸ ਤੋਂ ਬਿਨਾਂ ਸਧਾਰਨ ਇਮੇਜ ਬੇਨਤੀ ਦੇ ਸਮੇਂ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ (ਰਿਲੀਜ਼ ਚੈਨਲਾਂ ਹੇਠਾਂ ਦਿੱਤਾ `-web` ਨੋਟ ਵੇਖੋ)। |

ਕਿਸੇ ਖ਼ਾਸ ਟਾਰਗੇਟ ਨੂੰ ਹੱਥੀਂ ਬਿਲਡ ਕਰੋ:

```bash
docker build --target runner-base -t omniroute:base .
docker build --target runner-cli  -t omniroute:cli  .
docker build --target runner-web  -t omniroute:web  .
```

### ਬਿਲਡ-ਸਮੇਂ ਦੇ ਸਰੋਤ

ਤਿੰਨ ਬਿਲਡ ਆਰਗੂਮੈਂਟ ਇਹ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ ਕਿ `builder` ਪੜਾਅ ਕਿੰਨੇ ਸਰੋਤ ਵਰਤਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਬਿਲਡ ਸਮੇਂ ਲਈ ਹਨ —
`OMNIROUTE_MEMORY_MB` (ਹੇਠਾਂ) ਇੱਕ ਵੱਖਰੀ ਰਨਟਾਈਮ ਸੈਟਿੰਗ ਹੈ।

| ਬਿਲਡ ਆਰਗੂਮੈਂਟ               | ਮੂਲ ਮੁੱਲ | ਪ੍ਰਭਾਵ                                                                                               |
| --------------------------- | -------- | ---------------------------------------------------------------------------------------------------- |
| `OMNIROUTE_USE_TURBOPACK`   | `0`      | `0` webpack ਨਾਲ ਬਿਲਡ ਕਰਦਾ ਹੈ: ਘੱਟ ਅਧਿਕਤਮ ਮੈਮੋਰੀ, ਪਰ ਹੌਲੀ। `1` Turbopack ਦੀ ਵਰਤੋਂ ਚੁਣਦਾ ਹੈ।           |
| `OMNIROUTE_BUILD_MEMORY_MB` | `6144`   | ਸ਼ੁਰੂ ਕੀਤੇ `next build` ਲਈ V8 ਹੀਪ ਸੀਮਾ (`--max-old-space-size`)।                                     |
| `OMNIROUTE_BUILD_WORKERS`   | `2`      | `CIRCLE_NODE_TOTAL` ਨੂੰ ਮੁੱਲ ਦਿੰਦਾ ਹੈ; Next ਪੇਜ-ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ `workers = N - 1` ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। |

ਵੱਡੇ ਬਿਲਡਰ ਉੱਤੇ `OMNIROUTE_BUILD_WORKERS` ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਦੋਂ
ਸੀਮਤ ਸਰੋਤਾਂ ਵਾਲਾ ਬਿਲਡ `✓ Compiled successfully` **ਤੋਂ ਬਾਅਦ** ਬੰਦ ਹੋ ਜਾਵੇ, ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਸੇ ਉੱਤੇ
ਸ਼ੱਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਹਰ ਪੇਜ-ਡਾਟਾ ਵਰਕਰ ਆਪਣੀ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਅਤੇ ਮੂਲ `next build` ਵੀ
ਆਪਣੀ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਹੈ; ਇੱਕ ਲਾਈਵ VPS ਪੁਨਰ-ਨਿਰਮਾਣ (ਮੁੱਦਾ #7518) ਵਿੱਚ ਹਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਅਧਿਕਤਮ RSS
~4.5 GB ਮਾਪਿਆ ਗਿਆ, ਜੋ `NODE_OPTIONS` ਹੀਪ ਫਲੈਗ ਤੋਂ ਸੁਤੰਤਰ ਸੀ (Turbopack, V8 ਹੀਪ ਤੋਂ ਬਾਹਰ
ਨੇਟਿਵ/Rust ਮੈਮੋਰੀ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ)। `2` ਦਾ ਮੂਲ ਮੁੱਲ (→ 1 ਵਰਕਰ, ਕੁੱਲ 2
ਪ੍ਰਕਿਰਿਆਵਾਂ) ਉਹਨਾਂ 16 GB / 4 vCPU GitHub-ਹੋਸਟ ਕੀਤੇ ਰਨਰਾਂ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ
ਪਬਲਿਸ਼ ਪਾਈਪਲਾਈਨ ਵਰਤਦੀ ਹੈ। `8` ਉੱਤੇ (→ 7 ਵਰਕਰ) ਉਸ ਰਨਰ ਦੀ ਮੈਮੋਰੀ ਖ਼ਤਮ ਹੋ ਗਈ ਅਤੇ
buildkit ਨੇ `ResourceExhausted: ... cannot allocate memory` ਨਾਲ ਪੜਾਅ ਅਸਫਲ ਕਰ ਦਿੱਤਾ;
ਜਦੋਂ ਪ੍ਰਤੀ-ਪ੍ਰਕਿਰਿਆ RSS ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਸਿੱਧਾ ਮਾਪਿਆ ਗਿਆ, ਤਾਂ `3` (→ 2 ਵਰਕਰ) ਵੀ ਫਿੱਟ ਨਹੀਂ ਹੋਇਆ।
`tests/unit/docker-build-memory-budget.test.ts`
ਮਾਪੇ ਗਏ ਅੰਕੜੇ ਦੇ ਆਧਾਰ 'ਤੇ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਕੋਈ ਵੀ ਸੈਟਿੰਗ
ਰਨਰ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ।

Turbopack ਨੇਟਿਵ Rust ਮੈਮੋਰੀ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ, ਜੋ V8 ਹੀਪ ਦੇ **ਬਾਹਰ** ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ
`OMNIROUTE_BUILD_MEMORY_MB` ਇਸ ਨੂੰ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦਾ। ਮੈਮੋਰੀ ਸੀਮਾ ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ
OOM killer ਫਿਰ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ-ਸੁਨੇਹੇ ਦੇ SIGKILL ਰਾਹੀਂ ਬਿਲਡ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ — ਇਹ ਸਿਰਫ਼
`Creating an optimized production build` ਦੇ ਵਿਚਕਾਰ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਜੋ
ਮੈਮੋਰੀ ਖ਼ਤਮ ਹੋਣ ਦੀ ਬਜਾਏ ਅਟਕਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਇਸੇ ਲਈ `Dockerfile` ਦਾ ਮੂਲ ਵਿਕਲਪ webpack
(`OMNIROUTE_USE_TURBOPACK=0`) ਹੈ, ਜਦਕਿ `npm run dev` / `npm run build` ਵਿੱਚ
ਕੋਡ ਦਾ ਮੂਲ ਵਿਕਲਪ Turbopack ਹੈ: ਬਿਨਾਂ ਕਿਸੇ ਬਿਲਡ ਆਰਗੂਮੈਂਟ ਦੇ ਸਧਾਰਨ `docker build .` (ਜੋ
Railway ਅਤੇ ਹੋਰ ਇੱਕ-ਕਲਿੱਕ ਹੋਸਟ ਚਲਾਉਂਦੇ ਹਨ) ਨੂੰ ਮੈਮੋਰੀ-ਸੀਮਤ ਬਿਲਡਰ ਉੱਤੇ ਚੁੱਪਚਾਪ ਬੰਦ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਪ੍ਰਕਾਸ਼ਿਤ ਇਮੇਜਾਂ ਪਹਿਲਾਂ ਹੀ `docker-publish.yml` ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ
`OMNIROUTE_USE_TURBOPACK=0` ਪਾਸ ਕਰਦੀਆਂ ਹਨ। ਵੱਧ RAM ਵਾਲੇ ਬਿਲਡਰ ਉੱਤੇ ਤੇਜ਼ ਬਿਲਡ ਲਈ
Turbopack ਚੁਣੋ:

```bash
docker build --target runner-base \
  --build-arg OMNIROUTE_USE_TURBOPACK=1 \
  -t omniroute:base .
```

`webpackBuildWorker` ਸਮਰੱਥ ਹੈ, ਇਸ ਲਈ `next build` ਇੱਕ ਮੂਲ **ਅਤੇ** ਇੱਕ ਵਰਕਰ
ਪ੍ਰਕਿਰਿਆ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਵੱਖਰੇ ਤੌਰ 'ਤੇ `OMNIROUTE_BUILD_MEMORY_MB` ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। ਕੰਟੇਨਰ ਦੀ
ਸੀਮਾ ਨੂੰ ਇਸ ਮੁੱਲ ਦੇ ਲਗਭਗ ਦੁੱਗਣੇ ਤੋਂ ਵੱਧ ਰੱਖੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਗੁਣਾ।

ਇਸ ਟ੍ਰੀ ਉੱਤੇ ਮਾਪਿਆ ਗਿਆ (`--target runner-base`, `OMNIROUTE_BUILD_MEMORY_MB=6144`):

| ਬੰਡਲਰ     | ਕੰਟੇਨਰ ਸੀਮਾ    | ਨਤੀਜਾ                                     |
| --------- | -------------- | ----------------------------------------- |
| Turbopack | 8 GiB / 16 GiB | ਦੋਵਾਂ ਉੱਤੇ OOM ਦੁਆਰਾ ਚੁੱਪਚਾਪ ਬੰਦ ਕੀਤਾ ਗਿਆ |
| webpack   | 8 GiB          | ਬਿਲਡ ਵਰਕਰ ਨੂੰ SIGKILL ਰਾਹੀਂ ਬੰਦ ਕੀਤਾ ਗਿਆ  |
| webpack   | 12 GiB         | ਸਫਲ, ਅਧਿਕਤਮ ਵਰਤੋਂ 11.1 GiB ਰਹੀ            |

### ਰਨਟਾਈਮ ਦੇ ਮੂਲ ਮੁੱਲ

`runner-base` ਵੱਲੋਂ ਐਕਸਪੋਰਟ ਕੀਤੇ ਮੂਲ ਮੁੱਲ: `PORT=20128`, `HOSTNAME=0.0.0.0`, `OMNIROUTE_MEMORY_MB=1024`, `NODE_OPTIONS=--max-old-space-size=1024`, `DATA_DIR=/app/data`, `OMNIROUTE_MIGRATIONS_DIR=/app/migrations`।

Docker ਵਿੱਚ ਮੈਮੋਰੀ ਦਾ ਵਿਹਾਰ:

- ਇਮੇਜ `OMNIROUTE_MEMORY_MB=1024` ਸੈੱਟ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਤੋਂ `NODE_OPTIONS=--max-old-space-size=1024` ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
- ਅਸਲ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ standalone launcher ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ `OMNIROUTE_MEMORY_MB` ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ `--max-old-space-size=<OMNIROUTE_MEMORY_MB>` ਜੋੜਦਾ ਹੈ।
- Node ਦੁਹਰਾਏ ਗਏ `--max-old-space-size` ਦਾ ਆਖਰੀ ਮੁੱਲ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ `OMNIROUTE_MEMORY_MB` ਸੈੱਟ ਕਰਨਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ Docker heap ਸੀਮਾ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ।
- ਕਿਉਂਕਿ ਇਮੇਜ ਇਸਨੂੰ ਹਮੇਸ਼ਾ ਸੈੱਟ ਕਰਦੀ ਹੈ, launcher ਦਾ ਆਪਣਾ RAM-ਅਨੁਸਾਰ ਕੈਲੀਬਰੇਟ ਕੀਤਾ fallback Docker ਅਧੀਨ ਕਦੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਵਰਕਲੋਡ ਲਈ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਧਾਓ (ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ)। coding-agent `/v1/responses` ਲਈ `2048` ਅਜੇ ਵੀ ਬਹੁਤ ਘੱਟ ਹੈ।

### ਕੋਡਿੰਗ ਏਜੰਟਾਂ ਲਈ ਰਨਟਾਈਮ RAM

1 GiB Docker ਡਿਫਾਲਟ dashboard/ਹਲਕੀ-chat ਲਈ ਘੱਟੋ-ਘੱਟ ਸੀਮਾ ਹੈ, production ਆਕਾਰ ਨਹੀਂ। ਲੰਬੀਆਂ `POST /v1/responses` ਬਾਡੀਆਂ (ਸੈਂਕੜੇ ਸੁਨੇਹੇ, ਦਰਜਨਾਂ ਟੂਲ) compression ਦੌਰਾਨ ਕਈ in-memory graphs ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੀਆਂ ਹਨ। ਇੱਕੋ ਸਮੇਂ ਚੱਲ ਰਹੀਆਂ ਲਗਭਗ 3 MiB / ਲਗਭਗ 750k-token ਦੀਆਂ ਦੋ overlapping ਬੇਨਤੀਆਂ ਨੇ **12 GiB** old-space 'ਤੇ V8 ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਹੈ (`FATAL ERROR: Reached heap limit`) ਅਤੇ 16 GiB cgroup OOM ਸੀਮਾ ਨੂੰ ਵੀ ਛੂਹਿਆ ਹੈ। [#7849](https://github.com/diegosouzapw/OmniRoute/issues/7849) ਵੇਖੋ।

**cgroup `--memory` ਦਾ ਆਕਾਰ heap ਤੋਂ ਵੱਧ ਰੱਖੋ** — native buffers, SQLite, ਅਤੇ compression intermediates V8 ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ।

| ਵਰਕਲੋਡ                               | `OMNIROUTE_MEMORY_MB`    | ਕੰਟੇਨਰ / cgroup       | ਟਿੱਪਣੀਆਂ                                                                                       |
| ------------------------------------ | ------------------------ | --------------------- | ---------------------------------------------------------------------------------------------- |
| Dashboard, ਇੱਕ ਹਲਕੀ chat             | `1024` (ਇਮੇਜ ਡਿਫਾਲਟ)     | ≥2 GiB                |                                                                                                |
| ਇੱਕ ਕੋਡਿੰਗ ਏਜੰਟ (Claude/Codex/Grok)  | `8192`                   | ≥10 GiB               | ਆਮ single-session `/v1/responses`                                                              |
| ਇੱਕੋ ਸਮੇਂ ਦੋ ਲੰਬੀਆਂ `/v1/responses`  | `10240`–`12288`          | ≥12–16 GiB            | ਲਗਭਗ 12 GiB heap 'ਤੇ ਮਾਪਿਆ ਗਿਆ V8 abort                                                        |
| ਇੱਕੋ ਸਮੇਂ ਤਿੰਨ ਜਾਂ ਵੱਧ ਲੰਬੇ contexts | ਇੱਕ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਨਾ ਚਲਾਓ | ਲੜੀਵਾਰ ਚਲਾਓ / ਹੋਰ RAM | ਡਿਫਾਲਟ heavyweight admission 1 in-flight ਹੈ; RAM ਤੋਂ ਬਿਨਾਂ ਇਸਨੂੰ ਵਧਾਉਣ ਨਾਲ abort ਮੁੜ ਵਾਪਰਦਾ ਹੈ |

bare metal 'ਤੇ `omniroute serve`, ਜਦੋਂ `OMNIROUTE_MEMORY_MB` **ਸੈੱਟ ਨਾ ਹੋਵੇ**, RAM ਦੇ ਲਗਭਗ 35% ਅਨੁਸਾਰ ਕੈਲੀਬਰੇਟ ਕਰਦਾ ਹੈ (`[512, 4096]` ਤੱਕ ਸੀਮਿਤ)। Docker ਹਮੇਸ਼ਾ `1024` ਸੈੱਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅਧਿਕਾਰਤ ਇਮੇਜ ਵਿੱਚ ਉਹ calibration ਕਦੇ ਨਹੀਂ ਚੱਲਦੀ।

```bash
docker run -d --name omniroute --restart unless-stopped --stop-timeout 40 \
  -e OMNIROUTE_MEMORY_MB=8192 --memory=10g \
  -p 127.0.0.1:20128:20128 -v omniroute-data:/app/data diegosouzapw/omniroute:latest
```

## ਅਹਿਮ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ

[ENVIRONMENT.md](../reference/ENVIRONMENT.md) ਵਿੱਚ ਦਰਜ ਡਿਫਾਲਟਾਂ ਤੋਂ ਇਲਾਵਾ, Docker ਅਧੀਨ ਚਲਾਉਂਦੇ ਸਮੇਂ ਹੇਠਾਂ ਦਿੱਤੇ ਵੇਰੀਏਬਲ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ:

| ਵੇਰੀਏਬਲ                       | ਉਦੇਸ਼                                                                                                                                                                                                                                                                         | ਡਿਫਾਲਟ                     |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| `OMNIROUTE_WS_BRIDGE_SECRET`  | WebSocket ਬ੍ਰਿਜ ਲਈ ਸਾਂਝਾ ਗੁਪਤ ਮੁੱਲ। **ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲਾਜ਼ਮੀ** — ਇਸਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਤਰਤੀਬ ਸਟ੍ਰਿੰਗ 'ਤੇ ਸੈੱਟ ਕਰੋ।                                                                                                                                                                | ਸੈੱਟ ਨਹੀਂ (ਦੇਣਾ ਲਾਜ਼ਮੀ ਹੈ) |
| `REDIS_URL`                   | ਰੇਟ ਲਿਮਿਟਰ / ਕੈਸ਼ ਬੈਕਐਂਡ ਲਈ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ                                                                                                                                                                                                                                   | `redis://redis:6379`       |
| `REDIS_PORT`                  | ਨਾਲ ਸ਼ਾਮਲ Redis ਕੰਟੇਨਰ ਲਈ ਹੋਸਟ-ਸਾਈਡ ਪੋਰਟ                                                                                                                                                                                                                                      | `6379`                     |
| `REDIS_BIND_HOST`             | ਉਹ ਹੋਸਟ ਇੰਟਰਫੇਸ ਜਿਸ 'ਤੇ ਨਾਲ ਸ਼ਾਮਲ Redis ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ AUTH ਨਹੀਂ ਜੋੜਦੇ, ਲੂਪਬੈਕ)                                                                                                                                                                 | `127.0.0.1`                |
| `AUTO_UPDATE_HOST_REPO_DIR`   | ਸਵੈ-ਅੱਪਡੇਟ ਵਰਕਫ਼ਲੋ ਲਈ `/workspace/omniroute` 'ਤੇ `cli` ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਮਾਊਂਟ ਕੀਤਾ ਹੋਸਟ ਪਾਥ                                                                                                                                                                                     | `.` (ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ)     |
| `OMNIROUTE_MEMORY_MB`         | Docker ਸਟੈਂਡਅਲੋਨ ਸਰਵਰ ਲਈ ਰਨਟਾਈਮ Node ਹੀਪ ਸੀਮਾ; ਉੱਪਰ ਦਿੱਤੇ ਇਮੇਜ ਡਿਫਾਲਟ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦੀ ਹੈ। ਕੋਡਿੰਗ ਏਜੰਟ: `8192`+ ([ਰਨਟਾਈਮ RAM](#runtime-ram-for-coding-agents) ਵੇਖੋ)।                                                                                                          | `1024`                     |
| `DASHBOARD_PORT` / `API_PORT` | ਡੈਸ਼ਬੋਰਡ (20128) ਅਤੇ API (20129) ਲਈ ਉਪਲਬਧ ਕਰਵਾਏ ਪੋਰਟਾਂ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰੋ                                                                                                                                                                                                        | `20128` / `20129`          |
| `APP_BIND_HOST`               | ਉਹ ਹੋਸਟ ਇੰਟਰਫੇਸ ਜਿਸ 'ਤੇ docker-compose ਡੈਸ਼ਬੋਰਡ/API/live-WS ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। `REQUIRE_API_KEY=false` (ਡਿਫਾਲਟ) ਨਾਲ, `0.0.0.0` ਅਗਿਆਤ `/v1` ਪ੍ਰਾਕਸੀ ਨੂੰ LAN ਲਈ ਉਪਲਬਧ ਕਰਦਾ ਹੈ — ਇਸਨੂੰ ਸਿਰਫ਼ `REQUIRE_API_KEY=true` ਨਾਲ ਜਾਂ ਸਾਹਮਣੇ ਇੱਕ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਹੋਣ 'ਤੇ ਹੀ ਵਿਸਤਾਰ ਦਿਓ। | `127.0.0.1`                |
| `CLIPROXY_BIND_HOST`          | ਉਹ ਹੋਸਟ ਇੰਟਰਫੇਸ ਜਿਸ 'ਤੇ docker-compose `cliproxyapi` ਸਾਈਡਕਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ — ਇਸਦੇ ਡਾਟਾ ਵਾਲਿਊਮ ਵਿੱਚ ਪ੍ਰਦਾਤਾ ਕ੍ਰਿਡੈਂਸ਼ਲ ਹੁੰਦੇ ਹਨ।                                                                                                                                           | `127.0.0.1`                |
| `OMNIROUTE_PLUGINS_DIR`       | ਉਹ ਡਾਇਰੈਕਟਰੀ ਜਿਸਨੂੰ ਰਨਟਾਈਮ ਪਲੱਗਇਨ ਸਕੈਨਰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਜਿਸ ਵਿੱਚ ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਪਲੱਗਇਨ bind-mount ਕੀਤੇ ਹੋਣ ਤਾਂ ਇਸਨੂੰ ਸੈੱਟ ਕਰੋ: ਡਿਫਾਲਟ `HOME` ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਕਿਸੇ ਇਮੇਜ ਵੱਲੋਂ ਐਕਸਪੋਰਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ।                                                        | `~/.omniroute/plugins`     |
| `OMNIROUTE_BASE_PATH`         | ਜਦੋਂ ਐਪ ਨੂੰ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਦੇ ਪਿੱਛੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ URL ਸਬਪਾਥ (ਉਦਾਹਰਨ ਲਈ `/omniroute`)                                                                                                                                                                             | _(ਖਾਲੀ = ਰੂਟ)_             |
| `NEXT_PUBLIC_BASE_URL`        | ਸਬਪਾਥ ਸਮੇਤ ਜਨਤਕ ਬ੍ਰਾਊਜ਼ਰ ਮੂਲ (ਉਦਾਹਰਨ ਲਈ `https://host/omniroute`)                                                                                                                                                                                                             | ਸੈੱਟ ਨਹੀਂ                  |
| `PROD_DASHBOARD_PORT`         | `docker-compose.prod.yml` ਲਈ ਹੋਸਟ-ਸਾਈਡ ਡੈਸ਼ਬੋਰਡ ਪੋਰਟ                                                                                                                                                                                                                          | `20130`                    |
| `CLIPROXYAPI_PORT`            | `cliproxyapi` ਸਾਈਡਕਾਰ ਲਈ ਹੋਸਟ-ਸਾਈਡ ਪੋਰਟ                                                                                                                                                                                                                                       | `8317`                     |

## ਸਬਪਾਥ ਉੱਤੇ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (Traefik / nginx)

Next.js `basePath` ਨੂੰ standalone bundle ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। OmniRoute ਐਪ ਰੂਟ ਉੱਤੇ ਇੱਕ sentinel ਫ਼ਾਈਲ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਸ਼ਾਮਲ ਕੀਤੇ ਮੁੱਲ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ (`npm run build` ਦੌਰਾਨ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ; `scripts/docker/ensure-docker-base-path.mjs` ਵੱਲੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ) ਅਤੇ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਇਸ ਦੀ ਤੁਲਨਾ `OMNIROUTE_BASE_PATH` ਨਾਲ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇਮੇਜ ਡੋਮੇਨ ਰੂਟ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਤਾਂ `node dev/run-standalone.mjs` ਦੇ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ entrypoint standalone manifests, embedded `basePath`/`assetPrefix` literals (Next 16 SSR asset URLs ਨੂੰ ਸਿਰਫ਼ `assetPrefix` ਤੋਂ ਰੈਂਡਰ ਕਰਦਾ ਹੈ — patcher ਸਬਪਾਥ ਨੂੰ ਇਸ ਵਿੱਚ ਵੀ ਪ੍ਰਤੀਬਿੰਬਤ ਕਰਦਾ ਹੈ), ਪਹਿਲਾਂ ਤੋਂ ਸ਼ਾਮਲ `/_next/static` asset URLs (client-reference manifests, media imports, prerendered error pages) ਅਤੇ client `process.env` shim ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ।

### Compose ਬਿਲਡ (ਸਿਫ਼ਾਰਸ਼ੀ)

ਦੋਵੇਂ ਵੇਰੀਏਬਲ `.env` ਵਿੱਚ ਸੈੱਟ ਕਰੋ, ਫਿਰ ਮੁੜ ਬਿਲਡ ਕਰੋ ਤਾਂ ਜੋ ਇਮੇਜ ਅਤੇ runtime ਇੱਕੋ ਸੰਰਚਨਾ ਵਰਤਣ:

```bash
# .env
OMNIROUTE_BASE_PATH=/omniroute
NEXT_PUBLIC_BASE_URL=https://myhostname.example.com/omniroute
```

```bash
docker compose --profile base up -d --build
```

`docker-compose.yml`, `OMNIROUTE_BASE_PATH` ਨੂੰ Docker build-arg ਅਤੇ runtime environment variable ਦੋਵਾਂ ਵਜੋਂ ਅੱਗੇ ਭੇਜਦਾ ਹੈ।

### ਪਹਿਲਾਂ ਤੋਂ ਬਣਿਆ root image + runtime subpath

ਪ੍ਰਕਾਸ਼ਿਤ `diegosouzapw/omniroute:*` images ਡੋਮੇਨ ਰੂਟ ਲਈ ਬਣਾਏ ਗਏ ਹਨ। ਤੁਸੀਂ ਫਿਰ ਵੀ runtime ਵੇਲੇ `OMNIROUTE_BASE_PATH` ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ; ਕੰਟੇਨਰ startup ਉੱਤੇ bundle ਨੂੰ ਇੱਕ ਵਾਰ patch ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਮੇਲ ਖਾਂਦੇ public origin ਨਾਲ ਜੋੜੋ:

```yaml
services:
  omniroute:
    image: diegosouzapw/omniroute:latest
    environment:
      OMNIROUTE_BASE_PATH: /omniroute
      NEXT_PUBLIC_BASE_URL: https://myhostname.example.com/omniroute
```

ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਨੂੰ **ਪੂਰਾ** ਬਾਹਰੀ ਪਾਥ ਅੱਗੇ ਭੇਜਣ ਲਈ ਸੰਰਚਿਤ ਕਰੋ (prefix ਨਾ ਹਟਾਓ)। Traefik ਨੂੰ `StripPrefix` ਤੋਂ ਬਿਨਾਂ `PathPrefix(`/omniroute`)` ਨੂੰ ਕੰਟੇਨਰ ਵੱਲ route ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ Next.js ਨੂੰ `/omniroute/...` ਮਿਲੇ ਅਤੇ ਉਹ assets ਨੂੰ `/omniroute/_next/...` ਤੋਂ serve ਕਰੇ।

Docker healthcheck, ਸਰਗਰਮ `OMNIROUTE_BASE_PATH` ਨਾਲ prefix ਕੀਤੇ ਹਲਕੇ `/healthz` lifecycle endpoint ਨੂੰ probe ਕਰਦਾ ਹੈ। ਮਨੁੱਖੀ/dashboard diagnostics ਲਈ `/api/monitoring/health` ਉਪਲਬਧ ਰਹਿੰਦਾ ਹੈ; ਕੰਟੇਨਰ HEALTHCHECK ਨੂੰ ਮੁੜ ਇਸ ਵੱਲ ਦਰਸਾਉਣ ਲਈ (ਉਦਾਹਰਨ ਵਜੋਂ, ਡੂੰਘੀ health enforcement ਲਈ), `OMNIROUTE_HEALTHCHECK_PATH=/api/monitoring/health` ਸੈੱਟ ਕਰੋ। ਇਹ ਪਾਥ ਇੱਕ **ਡੂੰਘੀ** ਜਾਂਚ ਹੈ (DB + monitoring summary) — ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਮੁੜ ਚੁਣਦੇ ਹੋ ਤਾਂ ਇਹ Docker ਦੇ ਘੱਟ-ਵਾਰ ਚੱਲਣ ਵਾਲੇ `HEALTHCHECK` ਲਈ ਢੁਕਵਾਂ ਹੈ, ਪਰ Kubernetes `livenessProbe` intervals ਲਈ **ਨਹੀਂ**।

orchestrators (Kubernetes, Nomad ਆਦਿ) ਲਈ:

| Probe           | ਤਰਜੀਹ ਦਿਓ                                                           | ਬਚੋ                                                        |
| --------------- | ------------------------------------------------------------------- | ---------------------------------------------------------- |
| Liveness        | HTTP `GET /livez`, ਜਾਂ ਮੁੱਖ port (`PORT`, default `20128`) ਉੱਤੇ TCP | liveness ਵਜੋਂ `/api/monitoring/health`                     |
| Readiness       | HTTP `GET /healthz`                                                 | ਛੋਟੇ timeouts, ਜੋ event-loop ਦੇ busy ਹੋਣ ਨੂੰ dead ਮੰਨਦੇ ਹਨ |
| Deep / blackbox | `/api/monitoring/health`                                            | —                                                          |

`/healthz` process lifecycle (`ok` / `starting` / `stopping`) ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। `/livez` ਸਿਰਫ਼ process-alive ਹੈ (ਜਦੋਂ ਵੀ handler ਚੱਲ ਸਕਦਾ ਹੈ, 200; ਇਹ readiness ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ)। ਦੋਵੇਂ ਹਾਲੇ ਵੀ request handling ਵਾਲੇ ਉਸੇ Node event loop ਉੱਤੇ ਚੱਲਦੇ ਹਨ, ਇਸ ਲਈ CPU-bound catalog ਜਾਂ compression ਦਾ ਕੰਮ ਉਨ੍ਹਾਂ ਵਿੱਚ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ — busy ≠ dead। ਜੇ HTTP probes time out ਹੋ ਜਾਣ ਤਾਂ TCP liveness ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਪੂਰੀ probe ਸੇਧ:
[Monitoring guide — Kubernetes probe recommendations](../ops/MONITORING_GUIDE.md#kubernetes-probe-recommendations)।

## Caddy ਨਾਲ Docker Compose (HTTPS Auto-TLS)

OmniRoute ਨੂੰ Caddy ਦੀ ਆਟੋਮੈਟਿਕ SSL ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਉਪਲਬਧ ਕਰਵਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦਾ DNS A ਰਿਕਾਰਡ ਤੁਹਾਡੇ ਸਰਵਰ ਦੇ IP ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

```yaml
services:
  omniroute:
    image: diegosouzapw/omniroute:latest
    container_name: omniroute
    restart: unless-stopped
    volumes:
      - omniroute-data:/app/data
    environment:
      - PORT=20128
      # OAuth ਕਾਲਬੈਕਾਂ, ਡੈਸ਼ਬੋਰਡ ਲਿੰਕਾਂ ਅਤੇ ਤਿਆਰ ਕੀਤੇ ਜਨਤਕ URLs ਲਈ ਬ੍ਰਾਊਜ਼ਰ-ਮੁਖੀ ਮੂਲ।
      - NEXT_PUBLIC_BASE_URL=https://your-domain.com
      # ਨਿਯਤ ਕਾਰਜਾਂ / ਸਵੈ-ਫੈਚਾਂ ਲਈ ਅੰਦਰੂਨੀ ਸਰਵਰ-ਤੋਂ-ਸਰਵਰ URL।
      - BASE_URL=http://omniroute:20128
      - AUTH_COOKIE_SECURE=true

  caddy:
    image: caddy:latest
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    command: caddy reverse-proxy --from https://your-domain.com --to http://omniroute:20128

volumes:
  omniroute-data:
```

Caddy ਅੱਪਸਟ੍ਰੀਮ ਕੰਟੇਨਰ ਲਈ ਮਿਆਰੀ ਫਾਰਵਰਡਿੰਗ ਹੈਡਰ ਸੈੱਟ ਕਰਦਾ ਹੈ। OmniRoute,
`NEXT_PUBLIC_BASE_URL` ਨੂੰ OAuth ਕਾਲਬੈਕਾਂ ਅਤੇ ਤਿਆਰ ਕੀਤੇ ਜਨਤਕ ਲਿੰਕਾਂ ਲਈ ਕੈਨੋਨਿਕਲ ਜਨਤਕ ਮੂਲ ਵਜੋਂ ਵਰਤਦਾ ਹੈ;
ਪ੍ਰਮਾਣਿਤ ਡੈਸ਼ਬੋਰਡ ਰਾਈਟਾਂ ਸਮਾਨ-ਮੂਲ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਸੈਸ਼ਨ-ਬੱਧ CSRF ਸੁਰੱਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।
`OMNIROUTE_TRUST_PROXY` ਨੂੰ ਕੇਵਲ ਉਹਨਾਂ ਉੱਨਤ ਡਿਪਲੌਇਮੈਂਟਾਂ ਲਈ ਸਮਰੱਥ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਣਬੁੱਝ ਕੇ
ਚਾਹੁੰਦੇ ਹੋ ਕਿ OmniRoute ਸਪਸ਼ਟ ਸੰਰਚਨਾ ਦੀ ਬਜਾਏ ਭਰੋਸੇਯੋਗ ਫਾਰਵਰਡ ਕੀਤੇ ਹੈਡਰਾਂ ਤੋਂ ਜਨਤਕ ਮੂਲ ਨਿਰਧਾਰਤ ਕਰੇ।

## Cloudflare Quick Tunnel

Docker ਡਿਪਲੌਇਮੈਂਟਾਂ ਲਈ ਡੈਸ਼ਬੋਰਡ ਸਹਾਇਤਾ ਵਿੱਚ `Dashboard → Endpoints` ਉੱਤੇ ਇੱਕ-ਕਲਿੱਕ **Cloudflare Quick Tunnel** ਸ਼ਾਮਲ ਹੈ। ਪਹਿਲੀ ਵਾਰ ਸਮਰੱਥ ਕਰਨ ਉੱਤੇ `cloudflared` ਕੇਵਲ ਲੋੜ ਪੈਣ 'ਤੇ ਡਾਊਨਲੋਡ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੇ ਮੌਜੂਦਾ `/v1` ਐਂਡਪੌਇੰਟ ਲਈ ਇੱਕ ਅਸਥਾਈ ਟਨਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਤਿਆਰ ਕੀਤਾ `https://*.trycloudflare.com/v1` URL ਤੁਹਾਡੇ ਸਧਾਰਨ ਜਨਤਕ URL ਦੇ ਸਿੱਧੇ ਹੇਠਾਂ ਦਿਖਾਉਂਦਾ ਹੈ।

ਐਂਡਪੌਇੰਟ ਟਨਲ ਪੈਨਲਾਂ (Cloudflare, Tailscale, ngrok) ਨੂੰ ਸਰਗਰਮ ਟਨਲ ਦੀ ਸਥਿਤੀ ਬਦਲੇ ਬਿਨਾਂ `Settings → Appearance` ਤੋਂ ਦਿਖਾਇਆ ਜਾਂ ਲੁਕਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

### ਟਨਲ ਸੰਬੰਧੀ ਨੋਟਸ

- Quick Tunnel URLs ਅਸਥਾਈ ਹੁੰਦੇ ਹਨ ਅਤੇ ਹਰ ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ ਬਦਲ ਜਾਂਦੇ ਹਨ।
- OmniRoute ਜਾਂ ਕੰਟੇਨਰ ਦੇ ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ Quick Tunnels ਆਪਣੇ ਆਪ ਮੁੜ-ਬਹਾਲ ਨਹੀਂ ਹੁੰਦੇ। ਲੋੜ ਪੈਣ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਮੁੜ ਸਮਰੱਥ ਕਰੋ।
- ਪ੍ਰਬੰਧਿਤ ਇੰਸਟਾਲ ਇਸ ਵੇਲੇ `x64` / `arm64` ਉੱਤੇ Linux, macOS ਅਤੇ Windows ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
- ਸੀਮਤ ਕੰਟੇਨਰ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਸ਼ੋਰ-ਭਰੀਆਂ QUIC UDP ਬਫਰ ਚੇਤਾਵਨੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਪ੍ਰਬੰਧਿਤ Quick Tunnels ਮੂਲ ਰੂਪ ਵਿੱਚ HTTP/2 ਟ੍ਰਾਂਸਪੋਰਟ ਵਰਤਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਈ ਵੱਖਰਾ ਟ੍ਰਾਂਸਪੋਰਟ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ `CLOUDFLARED_PROTOCOL=quic` ਜਾਂ `auto` ਸੈੱਟ ਕਰੋ।
- Docker ਇਮੇਜਾਂ ਵਿੱਚ ਸਿਸਟਮ CA ਰੂਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ `cloudflared` ਤੱਕ ਪਹੁੰਚਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਟਨਲ ਬੂਟਸਟਰੈਪ ਹੋਣ ਵੇਲੇ TLS ਭਰੋਸਾ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ।
- ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ OmniRoute ਕੋਈ ਬਾਈਨਰੀ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਬਜਾਏ ਮੌਜੂਦਾ ਬਾਈਨਰੀ ਦੀ ਵਰਤੋਂ ਕਰੇ, ਤਾਂ `CLOUDFLARED_BIN=/absolute/path/to/cloudflared` ਸੈੱਟ ਕਰੋ।

## ਇਮੇਜ ਟੈਗ

| ਇਮੇਜ                     | ਟੈਗ      | ਆਕਾਰ   | ਵੇਰਵਾ                                                   |
| ------------------------ | -------- | ------ | ------------------------------------------------------- |
| `diegosouzapw/omniroute` | `latest` | ~250MB | ਸਭ ਤੋਂ ਉੱਚਾ **ਪ੍ਰਕਾਸ਼ਿਤ** ਸਥਿਰ SemVer (git `main` ਨਹੀਂ) |
| `diegosouzapw/omniroute` | `3.8.0`  | ~250MB | GitOps ਲਈ ਇਸ ਸ਼੍ਰੇਣੀ ਦੇ ਟੈਗ ਨੂੰ ਪਿੰਨ ਕਰੋ                |

ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਮੈਨੀਫੈਸਟ: ਮੂਲ `linux/amd64` + `linux/arm64` (Apple Silicon, AWS Graviton, Raspberry Pi)। Docker ਆਪਣੇ ਆਪ ਮੇਲ ਖਾਂਦਾ ਆਰਕੀਟੈਕਚਰ ਚੁਣਦਾ ਹੈ; ਜੇ ਤੁਹਾਨੂੰ ARM ਹੋਸਟਾਂ ਉੱਤੇ AMD64 ਇਮੂਲੇਸ਼ਨ ਲਾਜ਼ਮੀ ਕਰਨੀ ਹੋਵੇ ਤਾਂ `--platform linux/amd64` ਪਾਸ ਕਰੋ।

### ਰਿਲੀਜ਼ ਚੈਨਲ

OmniRoute ਸਥਿਰ ਰਿਲੀਜ਼ਾਂ, ਸਰਗਰਮ ਰਿਲੀਜ਼-ਬ੍ਰਾਂਚ ਟੈਸਟਿੰਗ ਅਤੇ ਡਿਵੈਲਪਮੈਂਟ ਬਿਲਡਾਂ ਲਈ ਵੱਖਰੇ Docker ਚੈਨਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।

| ਚੈਨਲ                            | ਸਰੋਤ                                  | ਬਦਲਣਯੋਗਤਾ                   | ਸਿਫ਼ਾਰਸ਼ੀ ਵਰਤੋਂ                                                                                                                          |
| ------------------------------- | ------------------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `:<version>` / `:<version>-web` | ਦਸਤਖ਼ਤਸ਼ੁਦਾ/ਵਰਜਨਬੱਧ ਰਿਲੀਜ਼            | ਅਬਦਲਣਯੋਗ                    | ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੌਇਮੈਂਟ ਜੋ ਕਿਸੇ ਸਟੀਕ ਰਿਲੀਜ਼ ਨੂੰ ਪਿੰਨ ਕਰਦੇ ਹਨ                                                                                |
| `:latest` / `:latest-web`       | ਸਭ ਤੋਂ ਉੱਚਾ **ਪ੍ਰਕਾਸ਼ਿਤ** ਸਥਿਰ SemVer | ਬਦਲਣਯੋਗ ਸਥਿਰ ਪੁਆਇੰਟਰ        | SemVer ਪ੍ਰਕਾਸ਼ਨ ਕਾਰਜ ਤੋਂ **ਬਾਅਦ** ਸਥਿਰ ਰਿਲੀਜ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ — `main` ਜਾਂ ਅਣਰਿਲੀਜ਼ ਕੀਤੀਆਂ `release/v*` ਕਮਿਟਾਂ ਨੂੰ ਟਰੈਕ **ਨਹੀਂ** ਕਰਦਾ |
| `:next` / `:next-web`           | ਮੌਜੂਦਾ ਡਿਫਾਲਟ `release/v*` ਬ੍ਰਾਂਚ     | ਬਦਲਣਯੋਗ ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਪੁਆਇੰਟਰ | ਉਹਨਾਂ ਸੁਧਾਰਾਂ ਦੀ ਜਾਂਚ ਜੋ ਸਰਗਰਮ ਰਿਲੀਜ਼ ਬ੍ਰਾਂਚ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਚੁੱਕੇ ਹਨ ਪਰ ਹਾਲੇ ਕਿਸੇ ਸਥਿਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਨਹੀਂ ਹਨ                                |
| `:main` / `:main-web`           | `main` ਬ੍ਰਾਂਚ                         | ਬਦਲਣਯੋਗ ਡਿਵੈਲਪਮੈਂਟ ਪੁਆਇੰਟਰ  | ਕੇਵਲ ਡਿਵੈਲਪਮੈਂਟ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ ਲਈ                                                                                               |

#### ਵੈੱਬ-ਸੈਸ਼ਨ ਪ੍ਰਦਾਤਾ: `-web` ਇਮੇਜਾਂ

ਉਪਰੋਕਤ ਹਰ ਚੈਨਲ ਇੱਕ `-web` ਟੈਗ (`:latest-web`, `:<version>-web`, `:next-web`, `:main-web`) ਵਜੋਂ ਵੀ ਉਪਲਬਧ ਹੈ, ਜੋ `runner-web` ਪੜਾਅ ਤੋਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ — ਉਹੀ ਇਮੇਜ, ਨਾਲ Playwright ਅਤੇ ਇੱਕ Chromium ਬ੍ਰਾਊਜ਼ਰ। ਸਧਾਰਨ ਇਮੇਜ Chromium ਤੋਂ **ਬਿਨਾਂ** ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; `gemini-web`, `claude-web` ਅਤੇ `claude-turnstile` ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਅਸਫਲਤਾ ਸਟਾਰਟਅੱਪ ਵੇਲੇ ਨਹੀਂ, ਸਗੋਂ ਬਾਅਦ ਲਈ ਟਾਲੀ ਜਾਂਦੀ ਹੈ: ਇਹ ਪ੍ਰਦਾਤਾ ਆਪਣੇ ਮਾਡਲਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦੇ ਹਨ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਕਨੈਕਟ ਹੋਏ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਕੇਵਲ ਪਹਿਲੀ ਬੇਨਤੀ ਇਸ ਸੁਨੇਹੇ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀ ਹੈ

```
[500]: Failed to load external module playwright: Error: Cannot find module
'/app/node_modules/playwright/node_modules/playwright-core/browsers.json'
```

ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਸੇ ਚੈਨਲ ਦਾ `-web` ਟੈਗ ਪੁੱਲ ਕਰੋ ਜਿਸ ਉੱਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਹੋ — ਹੋਰ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। npm/CLI ਇੰਸਟਾਲ (ਕੋਈ Docker ਇਮੇਜ ਨਹੀਂ) ਉੱਤੇ ਇਸਦੇ ਬਰਾਬਰ ਗੁੰਮ ਹਿੱਸਾ ਬ੍ਰਾਊਜ਼ਰ ਬਾਈਨਰੀ ਹੈ: ਹੋਸਟ ਉੱਤੇ `npx playwright install chromium` ਚਲਾਓ।

#### ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਚੈਨਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

`next` ਚੈਨਲ ਨੂੰ ਮੌਜੂਦਾ ਡਿਫਾਲਟ `release/v*` ਬ੍ਰਾਂਚ ਉੱਤੇ ਹਰ push ਨਾਲ ਮੁੜ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ AMD64 ਅਤੇ ARM64 ਦੋਵਾਂ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪੁਰਾਣੀਆਂ maintenance ਬ੍ਰਾਂਚਾਂ ਇਸਨੂੰ overwrite ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਇਹ ਚੈਨਲ ਉਹਨਾਂ fixes ਲਈ pull ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ image ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ ਜੋ ਅਗਲਾ stable tag ਬਣਾਏ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਗਰਮ release ਬ੍ਰਾਂਚ ਵਿੱਚ merge ਹੋ ਚੁੱਕੀਆਂ ਹਨ।

```bash
docker pull diegosouzapw/omniroute:next
docker pull diegosouzapw/omniroute:next-web
```

Docker Compose ਲਈ, ਚੁਣੇ ਹੋਏ profile ਵੱਲੋਂ ਵਰਤੇ ਜਾਂਦੇ image tag ਨੂੰ override ਕਰੋ, ਫਿਰ service ਨੂੰ pull ਕਰਕੇ ਮੁੜ ਬਣਾਓ:

```yaml
services:
  omniroute:
    image: diegosouzapw/omniroute:next
```

```bash
docker compose pull
docker compose up -d
```

#### ਸੁਰੱਖਿਆ ਅਤੇ ਰੋਲਬੈਕ

`next` ਇੱਕ ਬਦਲਦਾ ਰਹਿਣ ਵਾਲਾ pre-release ਚੈਨਲ ਹੈ। ਸਰਗਰਮ release ਬ੍ਰਾਂਚ ਉੱਤੇ ਕਿਸੇ ਵੀ push ਨਾਲ ਇਹ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ **production ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ**। ਕਿਸੇ ਖ਼ਾਸ build ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ image digest ਨੂੰ pin ਕਰੋ:

```bash
docker pull diegosouzapw/omniroute:next
docker image inspect diegosouzapw/omniroute:next --format '{{index .RepoDigests 0}}'
```

ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, OmniRoute data volume ਜਾਂ bind-mounted data directory ਦਾ backup ਲਓ। ਰੋਲਬੈਕ ਕਰਨ ਲਈ, ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ stable version ਜਾਂ digest ਨੂੰ restore ਕਰੋ ਅਤੇ container ਨੂੰ ਮੁੜ ਬਣਾਓ:

```bash
docker pull diegosouzapw/omniroute:<stable-version>
docker compose up -d
```

ਕਿਸੇ release-branch build ਨਾਲ `latest` ਕਦੇ ਵੀ ਅੱਗੇ ਨਹੀਂ ਵੱਧ ਸਕਦਾ; ਕੇਵਲ ਇੱਕ ਯੋਗ stable semantic version ਹੀ stable pointer ਨੂੰ promote ਕਰ ਸਕਦਾ ਹੈ। `next` images ਵਿੱਚ release image inspection ਅਤੇ ਰੋਕ ਲਗਾਉਣ ਵਾਲਾ CRITICAL-vulnerability gate ਬਰਕਰਾਰ ਰਹਿੰਦਾ ਹੈ।

**`latest`, git ਲਈ ਨਵੀਨਤਮ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ।** `main` ਜਾਂ ਸਰਗਰਮ `release/v*` ਬ੍ਰਾਂਚ ਉੱਤੇ merge ਕੀਤੀਆਂ fixes ਉਦੋਂ ਤੱਕ `:latest` ਵਿੱਚ **ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀਆਂ**, ਜਦੋਂ ਤੱਕ ਇੱਕ stable SemVer image ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਅਤੇ publish job `:latest` ਨੂੰ promote ਨਹੀਂ ਕਰਦੀ (ਉਸ SemVer ਵਾਲਾ ਹੀ digest)। ਜੇ GitHub ਉੱਤੇ fix ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਈ ਦੇ ਰਹੀ ਹੈ ਪਰ `latest` ਰੁਕਿਆ ਹੋਇਆ ਲੱਗਦਾ ਹੈ, ਤਾਂ release ਬ੍ਰਾਂਚ ਨੂੰ ਟੈਸਟ ਕਰਨ ਲਈ `:next` pull ਕਰੋ ਜਾਂ SemVer tag ਦੀ ਉਡੀਕ ਕਰੋ।

| ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ                                                                | ਵਰਤੋ                                    |
| ---------------------------------------------------------------------------------- | --------------------------------------- |
| GitOps / production ਜਿਸ ਵਿੱਚ drift ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ                                | `:X.Y.Z` (ਜਾਂ image digest) ਨੂੰ pin ਕਰੋ |
| ਪ੍ਰਕਾਸ਼ਿਤ stable releases ਨੂੰ follow ਕਰਨਾ ਅਤੇ ਹਰ release ਉੱਤੇ recreate ਸਵੀਕਾਰ ਕਰਨਾ | `:latest`                               |
| ਅਪ੍ਰਕਾਸ਼ਿਤ `release/v*` commits ਨੂੰ ਟੈਸਟ ਕਰਨਾ                                      | `:next` (production ਲਈ ਨਹੀਂ)            |
| `main` ਨੂੰ ਟੈਸਟ ਕਰਨਾ                                                               | `:main` (production ਲਈ ਨਹੀਂ)            |

## Docker ਵਿੱਚ ਡੈਸ਼ਬੋਰਡ ਅੱਪਡੇਟ

ਪ੍ਰਕਾਸ਼ਿਤ ਇਮੇਜ ਵਾਲਾ ਕੰਟੇਨਰ ਆਪਣੇ ਆਪ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦਾ। ਜਦੋਂ OmniRoute ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ
ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਚੱਲ ਰਿਹਾ ਹੈ (`.git` ਚੈੱਕਆਉਟ ਨਹੀਂ, npm ਇੰਸਟਾਲ ਨਹੀਂ), ਤਾਂ ਹੋਮ ਡੈਸ਼ਬੋਰਡ ਦਾ ਅੱਪਡੇਟ ਬੈਨਰ
npm/git ਹਦਾਇਤਾਂ ਦੀ ਬਜਾਏ ਚਲਾਉਣ ਲਈ ਹੋਸਟ ਕਮਾਂਡ, ਕਾਪੀ ਬਟਨ ਸਮੇਤ, ਦਿਖਾਉਂਦਾ ਹੈ:

```bash
docker compose pull omniroute && docker compose up -d --force-recreate omniroute
```

ਸੇਵਾ ਦਾ ਨਾਮ `AUTO_UPDATE_SERVICE` ਤੋਂ ਆਉਂਦਾ ਹੈ (ਡਿਫਾਲਟ `omniroute`, ਜੋ
`docker-compose.selfhost.yml` ਵਿੱਚ ਸੇਵਾ ਹੈ)। `pull` ਸਿਰਫ਼ ਇੱਕ ਬਦਲਦੇ ਟੈਗ (`latest`, `next`) ਨੂੰ ਅੱਗੇ ਵਧਾਉਂਦਾ ਹੈ; ਪਿੰਨ ਕੀਤੇ
`:X.Y.Z` ਟੈਗ ਨਾਲ, ਪਹਿਲਾਂ ਟੈਗ ਸੋਧੋ।

### ਹੋਸਟ ਟ੍ਰਿਗਰ ਫ਼ਾਈਲ ਨਾਲ ਇੱਕ-ਕਲਿੱਕ ਅੱਪਡੇਟ

`/var/run/docker.sock` ਨੂੰ ਮਾਊਂਟ ਕੀਤੇ ਬਿਨਾਂ **ਹੁਣੇ ਅੱਪਡੇਟ ਕਰੋ** ਨੂੰ ਕਾਰਜਸ਼ੀਲ ਰੱਖਣ ਲਈ (ਜੋ ਕੰਟੇਨਰ ਨੂੰ
ਹੋਸਟ ਉੱਤੇ root ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ — ਉੱਪਰ ਦਿੱਤੀ `cli` ਪ੍ਰੋਫ਼ਾਈਲ ਚੇਤਾਵਨੀ ਵੇਖੋ), OmniRoute ਸੇਵਾ ਉੱਤੇ
`DOCKER_UPDATE_TRIGGER_FILE` ਸੈੱਟ ਕਰੋ ਅਤੇ ਹੋਸਟ ਉੱਤੇ ਇੱਕ ਵਾਚਰ ਚਲਾਓ:

```yaml
services:
  omniroute:
    environment:
      DOCKER_UPDATE_TRIGGER_FILE: /app/data/update/docker-update.request
    volumes:
      - ./data:/app/data
```

ਪਾਥ `DATA_DIR` ਦੇ ਅੰਦਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਸਾਪੇਖ ਮੁੱਲ ਇਸਦੇ ਮੁਤਾਬਕ ਰਿਜ਼ਾਲਵ ਹੁੰਦੇ ਹਨ); ਹੋਰ ਕੁਝ ਵੀ
ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਫਿਰ **ਹੁਣੇ ਅੱਪਡੇਟ ਕਰੋ** ਉਸ ਫ਼ਾਈਲ ਵਿੱਚ `{ "requestedAt": "...", "targetVersion": "X.Y.Z" }`
ਲਿਖਦਾ ਹੈ, `202` ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਨਵਾਂ ਵਰਜਨ ਲਾਈਵ ਹੋਣ ਤੱਕ
`/api/system/version` ਨੂੰ ਪੋਲ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਰੀਲੋਡ ਹੁੰਦਾ ਹੈ। ਇਸ ਮੋਡ ਵਿੱਚ OmniRoute ਕਦੇ ਵੀ ਕੋਈ ਸ਼ੈੱਲ ਜਾਂ Docker ਕਮਾਂਡ ਨਹੀਂ ਚਲਾਉਂਦਾ।
ਹਰ ਅੱਪਡੇਟ ਕਾਰਵਾਈ ਵਾਂਗ, ਬੇਨਤੀ ਸਿਰਫ਼ ਲੂਪਬੈਕ/LAN ਕਲਾਇੰਟਾਂ ਤੋਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਬਾਇਂਡ-ਮਾਊਂਟ ਕੀਤੀ ਡਾਟਾ ਡਾਇਰੈਕਟਰੀ ਹੋਸਟ ਨੂੰ ਨਿਗਰਾਨੀ ਲਈ ਇੱਕ ਸਥਿਰ ਪਾਥ ਦਿੰਦੀ ਹੈ। ਨਮੂਨਾ `systemd` ਯੂਨਿਟ
(`/srv/omniroute` ਨੂੰ ਉਸ ਡਾਇਰੈਕਟਰੀ ਅਨੁਸਾਰ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੀ compose ਫ਼ਾਈਲ ਅਤੇ `data/` ਮੌਜੂਦ ਹਨ):

```ini
# /etc/systemd/system/omniroute-update.path
[Unit]
Description=Watch for OmniRoute dashboard update requests

[Path]
PathExists=/srv/omniroute/data/update/docker-update.request

[Install]
WantedBy=multi-user.target
```

```ini
# /etc/systemd/system/omniroute-update.service
[Unit]
Description=Pull and recreate the OmniRoute container

[Service]
Type=oneshot
WorkingDirectory=/srv/omniroute
ExecStartPre=/usr/bin/rm -f /srv/omniroute/data/update/docker-update.request
ExecStart=/bin/sh -c 'docker compose pull omniroute || (sleep 15 && docker compose pull omniroute)'
ExecStart=/usr/bin/docker compose up -d --force-recreate omniroute
```

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now omniroute-update.path
```

ਸੇਵਾ ਪੁੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਨੂੰ ਹਟਾਉਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਅਸਫਲ ਰਨ ਲੂਪ ਵਿੱਚ ਨਾ ਪਵੇ।
`DOCKER_UPDATE_TRIGGER_FILE` ਤੋਂ ਬਿਨਾਂ ਡੈਸ਼ਬੋਰਡ ਮੈਨੁਅਲ ਕਮਾਂਡ ਪ੍ਰਵਾਹ ਨੂੰ ਜਾਰੀ ਰੱਖਦਾ ਹੈ।

## ਉਪਲਬਧਤਾ: ਡਿਫਾਲਟ SQLite ਇੱਕੋ ਰੈਪਲਿਕਾ ਵਾਲਾ ਹੈ

ਮਿਆਰੀ Docker / Kubernetes OmniRoute ਵਿੱਚ **ਇੱਕ Node ਪ੍ਰੋਸੈੱਸ + ਇੱਕ SQLite ਰਾਈਟਰ** ਹੁੰਦਾ ਹੈ। ਇਸ ਟੋਪੋਲੋਜੀ ਉੱਤੇ ਉੱਚ ਉਪਲਬਧਤਾ **ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ**।

| ਪਾਬੰਦੀ                                 | ਨਤੀਜਾ                                                                                                                                                                                                                                                                                                             |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ਇੱਕੋ ਰਾਈਟਰ                             | ਇੱਕੋ SQLite ਫ਼ਾਈਲ ਲਈ ਕਈ ਰੈਪਲਿਕਾ **ਨਾ** ਚਲਾਓ। ਇਸ ਨਾਲ DB ਖ਼ਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ।                                                                                                                                                                                                                                         |
| ਮੁੜ ਬਣਾਉਣਾ / ਰੀਸਟਾਰਟ / HEALTHCHECK ਕਿਲ | ਚੱਲ ਰਹੇ SSE, ਡੈਸ਼ਬੋਰਡ ਸੈਸ਼ਨਾਂ ਅਤੇ ਇਨ-ਮੈਮੋਰੀ ਸਥਿਤੀ ਦੀ **ਪੂਰੀ ਬੰਦਸ਼**। ਹਰ ਕਨੈਕਟ ਕੀਤਾ ਕਲਾਇੰਟ ਡਿਸਕਨੈਕਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਖ਼ਾਲੀ-ਐਂਡਪੌਇੰਟ ਵਿੰਡੋ ਦੌਰਾਨ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰਿਵਰਸ-ਪ੍ਰੌਕਸੀ **`502 Bad Gateway: Unknown error`** ਮਿਲਦਾ ਹੈ, OmniRoute JSON ਨਹੀਂ — ਕਲਾਇੰਟ ਇਸਨੂੰ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਅਸਫਲਤਾ ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ (#11015)। |
| `/healthz` ਵਾਲਾ ਹੀ ਇਵੈਂਟ ਲੂਪ           | ਰੁੱਝਿਆ ਹੋਇਆ ਕੈਟਾਲੌਗ ਜਾਂ ਕੰਪ੍ਰੈਸ਼ਨ ਟਿੱਕ ਪ੍ਰੋਬਾਂ ਨੂੰ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ; ਫਿਰ ਛੋਟਾ ਟਾਈਮਆਉਟ **ਇੱਕੋ-ਇੱਕ** ਰੈਪਲਿਕਾ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰ ਦਿੰਦਾ ਹੈ।                                                                                                                                                                                |

**ਪ੍ਰੋਬ ਮੈਟ੍ਰਿਕਸ** ([Kubernetes ਪ੍ਰੋਬ ਸਿਫ਼ਾਰਸ਼ਾਂ](../ops/MONITORING_GUIDE.md#kubernetes-probe-recommendations) ਵੀ ਵੇਖੋ):

| ਪ੍ਰੋਬ            | ਟਾਰਗੇਟ                                                      | ਇਸਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ                                            |
| ---------------- | ----------------------------------------------------------- | ------------------------------------------------------------ |
| ਲਾਈਵਨੈੱਸ         | `PORT` ਉੱਤੇ TCP (ਡਿਫਾਲਟ `20128`), ਜਾਂ ਸੌਫ਼ਟ HTTP `/healthz` | `/api/monitoring/health`                                     |
| ਰੈਡੀਨੈੱਸ         | HTTP `GET /healthz`                                         | ਸਖ਼ਤ ਟਾਈਮਆਉਟ ਜੋ ਇਵੈਂਟ ਲੂਪ ਦੇ ਰੁੱਝੇ ਹੋਣ ਨੂੰ ਬੰਦ ਹੋਣਾ ਮੰਨਦੇ ਹਨ |
| ਡੀਪ / ਮਨੁੱਖਾਂ ਲਈ | `/api/monitoring/health`                                    | ਸਵੈਚਾਲਿਤ kubelet ਲਾਈਵਨੈੱਸ                                    |

**ਅੱਪਗ੍ਰੇਡ:** ਹਰ ਸੈਸ਼ਨ ਦੇ ਡਿਸਕਨੈਕਟ ਹੋਣ ਦੀ ਉਮੀਦ ਰੱਖੋ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਡ੍ਰੇਨ ਕਰੋ; ਡਿਫਾਲਟ SQLite ਉੱਤੇ ਕੋਈ ਰੋਲਿੰਗ ਅੱਪਡੇਟ ਨਹੀਂ ਹੈ। Compose `restart: unless-stopped` ਅਤੇ Docker `HEALTHCHECK` ਵੀ ਕੰਟੇਨਰ ਦੇ Unhealthy ਹੋਣ ਉੱਤੇ ਇੱਕੋ-ਇੱਕ ਪ੍ਰੋਸੈੱਸ ਨੂੰ ਬਦਲ ਦੇਣਗੇ — ਪ੍ਰਭਾਵ ਦਾ ਘੇਰਾ ਉਹੀ ਰਹੇਗਾ।

**ਇੱਕੋ ਰੈਪਲਿਕਾ** ਲਈ Kubernetes ਸਨਿੱਪਟ (Recreate ਲਾਜ਼ਮੀ ਹੈ; ਇੱਕ SQLite ਫ਼ਾਈਲ ਲਈ `replicas` ਨਾ ਵਧਾਓ):

```yaml
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    spec:
      terminationGracePeriodSeconds: 90
      containers:
        - name: omniroute
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sleep", "15"]
          readinessProbe:
            httpGet:
              path: /healthz
              port: 20128
            periodSeconds: 5
          livenessProbe:
            tcpSocket:
              port: 20128
            periodSeconds: 20
```

`preStop` sleep, SIGTERM ਤੋਂ ਪਹਿਲਾਂ kube ਨੂੰ Service endpoints ਹਟਾਉਣ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਜੋ **ਨਵਾਂ** ਟ੍ਰੈਫ਼ਿਕ ਬੰਦ ਹੋ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਪਹੁੰਚਣਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਚੱਲ ਰਹੀ `/v1/responses` SSE ਨੂੰ heavyweight admission leases (#11015) ਰਾਹੀਂ `SHUTDOWN_TIMEOUT_MS` (ਮੂਲ ਰੂਪ ਵਿੱਚ 30s) ਤੱਕ ਪੂਰਾ ਹੋਣ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜਿਹੜੀਆਂ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਫਿਰ ਵੀ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ `503` + `Retry-After: 5` ਮਿਲਦਾ ਹੈ। ਬਦਲਵਾਂ Ready ਹੋਣ ਤੱਕ Recreate ਕਾਰਨ ਬਣਿਆ ਖ਼ਾਲੀ-endpoint ਅੰਤਰਾਲ ਪੂਰੀ ਸੇਵਾ-ਬੰਦੀ ਹੀ ਰਹਿੰਦਾ ਹੈ — ਇਹ SQLite ਟੋਪੋਲੋਜੀ ਦਾ ਨਤੀਜਾ ਹੈ, probe ਦੀ ਗ਼ਲਤ ਸੰਰਚਨਾ ਨਹੀਂ।

External Postgres / multi-writer HA ਕੋਈ **ਦਸਤਾਵੇਜ਼ਬੱਧ** ਮਿਆਰੀ ਰਾਹ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ HA ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕੋ replica ਰੱਖੋ ਜਾਂ ਅਜਿਹੀ ਟੋਪੋਲੋਜੀ ਚਲਾਓ ਜਿਸਦੀ ਪ੍ਰੋਜੈਕਟ ਨੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕੀਤਾ ਹੋਵੇ। Postgres/MySQL ਸੰਬੰਧੀ ਕੰਮ [#8075](https://github.com/diegosouzapw/OmniRoute/issues/8075) ਵਿੱਚ ਹੈ। ਜਦੋਂ ਤੱਕ ਇਹ ਜਾਰੀ ਨਹੀਂ ਹੁੰਦਾ, **ਵੱਡੀਆਂ** `/v1/responses` ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣ ਦਾ ਇਕੱਲਾ ਸਮਰਥਿਤ ਤਰੀਕਾ N ਸੁਤੰਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਅਗਲਾ ਭਾਗ) ਹਨ, ਨਾ ਕਿ ਇੱਕ volume ਉੱਤੇ `replicas > 1`।

## ਸਕੇਲ-ਆਉਟ: N ਸੁਤੰਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ

ਇੱਕ Node ਪ੍ਰਕਿਰਿਆ **ਇੱਕ V8 ਹੀਪ** ਹੁੰਦੀ ਹੈ। ਦੋ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਓਵਰਲੈਪ ਕਰਦੀਆਂ ~3 MiB / ~750k-token ਕੋਡਿੰਗ-ਏਜੰਟ `POST /v1/responses` ਬੇਨਤੀਆਂ (RTK + Caveman) ਲਗਭਗ ~12 Gi ਉੱਤੇ ਉਸ ਹੀਪ ਨੂੰ ਰੋਕ ਦਿੰਦੀਆਂ ਹਨ (`FATAL ERROR: Reached heap limit`) ਅਤੇ 16 Gi cgroup ਨੂੰ OOM ਕਰ ਸਕਦੀਆਂ ਹਨ। [#7849](https://github.com/diegosouzapw/OmniRoute/issues/7849) ਵੇਖੋ। ਇਹ ਮਾਪ ਇੱਕ **ਮੈਮੋਰੀ-ਬਜਟ** ਚੇਤਾਵਨੀ ਹੈ, ਦੋ ਸਮਕਾਲੀ ਲੰਬੀਆਂ `/v1/responses` ਦੀ ਉਤਪਾਦ-ਪੱਧਰੀ ਸਖ਼ਤ ਅਧਿਕਤਮ ਸੀਮਾ ਨਹੀਂ। ਭਾਰੀ ਚੈਟ ਲਈ ਦਾਖ਼ਲਾ, ਆਪਣੇ-ਆਪ ਨਿਰਧਾਰਤ ਹੋਣ ਵਾਲੇ ਇਨਜੈਸਟ ਬਾਈਟ ਬਜਟ (`OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES`, `src/shared/middleware/admissionBudget.ts`) ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੁੰਦਾ ਹੈ, ਜਿਸਦਾ ਆਕਾਰ ਉਸੇ V8/cgroup ਸੀਮਾ ਤੋਂ ਤੈਅ ਹੁੰਦਾ ਹੈ — ਪਹਿਲਾਂ ਹੀ ਉਚਿਤ ਆਕਾਰ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਉੱਤੇ ਇਸਨੂੰ ਵਧਾ ਕੇ ਓਵਰਰਾਈਡ ਕਰਨਾ (ਜਾਂ ਪੁਰਾਣੀ `OMNIROUTE_CHAT_MAX_HEAVY_IN_FLIGHT` ਬੇਨਤੀ-ਗਿਣਤੀ ਸੀਮਾ ਸੈੱਟ ਕਰਨਾ) ਮੁੜ ਅਬੋਰਟ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਛੋਟੀਆਂ ਚੈਟਾਂ, `/healthz`, `/v1/models`, ਅਤੇ MCP ਇਸ ਸੀਮਾ ਵਿੱਚ **ਸ਼ਾਮਲ ਨਹੀਂ** ਹਨ।

### ਇੱਕ ਪ੍ਰਕਿਰਿਆ: ਦੋ ਤੋਂ ਵੱਧ ਲੰਬੀਆਂ `/v1/responses`

ਇੱਕ **ਸਿਹਤਮੰਦ** ਪ੍ਰਕਿਰਿਆ (ਹੀਪ `OMNIROUTE_CHAT_ADMISSION_HEAP_SHED_RATIO` ਤੋਂ ਹੇਠਾਂ, ਡਿਫੌਲਟ `0.75`) ਦੋ ਤੋਂ ਵੱਧ ਸਮਕਾਲੀ ਲੰਬੀਆਂ `POST /v1/responses` ਬੇਨਤੀਆਂ ਚਲਾ **ਸਕਦੀ ਹੈ**, ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ-ਵਿਆਪੀ ਇਨਫਲਾਈਟ-ਬਾਈਟ ਬਜਟ (`OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES` / #10110) ਵਿੱਚ ਅਜੇ ਵੀ ਜਗ੍ਹਾ ਹੋਵੇ। `OMNIROUTE_CHAT_LARGE_BODY_BYTES` (ਡਿਫੌਲਟ 256 KiB) ਦੇ ਬਰਾਬਰ ਜਾਂ ਇਸ ਤੋਂ ਵੱਡੀਆਂ ਬਾਡੀਆਂ, ਸੰਰਚਨਾ-ਭਾਰੀ ਬੇਨਤੀਆਂ ਵਾਂਗ ਹੀ ਹੈਵੀਵੇਟ ਲੀਜ਼ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ ਉਹੀ [#10437](https://github.com/diegosouzapw/OmniRoute/pull/10437) `tryAcquireHealthyHeadroom` ਐਸਕੇਪ (`OMNIROUTE_CHAT_ADMISSION_HEALTHY_HEADROOM`) ਵਰਤਦੀਆਂ ਹਨ। ਦਰਜਨਾਂ ਸਮਕਾਲੀ ਲੰਬੇ SSE ਕਲਾਇੰਟ (ਓਪਰੇਟਰਾਂ ਨੂੰ ਅਕਸਰ 40–50 ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ) ਇੱਕ **ਮੈਮੋਰੀ-ਬਜਟ** ਦਾ ਸਵਾਲ ਹੈ — ਹੀਪ + ਪ੍ਰਾਇਮਰੀ/ਹੈੱਡਰੂਮ ਸਲਾਟ + `OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES` ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੋ — ਇਹ ਉਤਪਾਦ ਦੀ ਸਖ਼ਤ “ਅਧਿਕਤਮ 2” ਸੀਮਾ ਨਹੀਂ ਹੈ। ਦਬਾਅ ਹੇਠਲਾ ਹੀਪ ਫਿਰ ਵੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਯੋਗ `503` ਨਾਲ ਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਤਾਂ ਜੋ #7849 ਮੁੜ ਨਾ ਵਾਪਰੇ।

**ਹੀਪਾਂ ਨੂੰ ਗੁਣਾ ਕਰਨ** (ਸੁਤੰਤਰ V8 old-spaces) ਲਈ **ਅੱਜ**:

| ਇਹ ਕਰੋ                                                                                                                                             | ਇਹ ਨਾ ਕਰੋ                                                  |
| -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **N containers/pods** ਚਲਾਓ, ਹਰੇਕ ਦੇ ਆਪਣੇ **ਵੱਖਰੇ** `DATA_DIR` / volume ਨਾਲ                                                                         | ਇੱਕ SQLite ਫ਼ਾਈਲ ਲਈ `replicas > 1` ਸੈੱਟ ਕਰੋ                |
| ਭਾਰੀ ਇਨ-ਫਲਾਈਟ + ਸਿਹਤਮੰਦ-ਹੈੱਡਰੂਮ ਦਾ ਆਕਾਰ ਹੀਪ / ਇਨਫਲਾਈਟ-ਬਾਈਟ ਬਜਟ ਦੇ ਆਧਾਰ ’ਤੇ ਨਿਰਧਾਰਤ ਕਰੋ; 1–2 ਸੰਭਾਲੂ #7849 ਡਿਫੌਲਟ ਹੈ, ਉਤਪਾਦ ਦੀ ਸਖ਼ਤ ਅਧਿਕਤਮ ਸੀਮਾ ਨਹੀਂ | ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ 8× RAM ਅਤੇ ਬੇਹੱਦ ਗਿਣਤੀ ਸੀਮਾ ਦਿਓ           |
| ਵਿਕਲਪਿਕ: **ਸਾਂਝੇ ਕੋਟਾ ਕਾਊਂਟਰਾਂ** ਲਈ `QUOTA_STORE_DRIVER=redis` + `QUOTA_STORE_REDIS_URL`                                                           | Redis ਨੂੰ ਸਾਂਝੀ SQLite ਸਮਝੋ — ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਹੈ             |
| ਪ੍ਰਦਾਤਾ ਸੀਕ੍ਰੇਟ ਹਰ ਇੰਸਟੈਂਸ ਵਿੱਚ ਨਕਲ ਕਰੋ (ਜਾਂ ਵੰਡੇ ਹੋਏ ਡੈਸ਼ਬੋਰਡ ਸਵੀਕਾਰ ਕਰੋ)                                                                         | ਸਾਰੇ ਇੰਸਟੈਂਸਾਂ ਵਿੱਚ ਇੱਕ ਡੈਸ਼ਬੋਰਡ / ਇੱਕ ਕਾਲ-ਲੌਗ ਦੀ ਉਮੀਦ ਕਰੋ |
| ਅੱਗੇ ਕੋਈ ਵੀ ਲੋਡ ਬੈਲੈਂਸਰ ਲਗਾਓ; API ਕੁੰਜੀ ਜਾਂ ਸੈਸ਼ਨ ਅਨੁਸਾਰ ਸਟਿੱਕੀ ਹੋਣਾ ਕਾਫ਼ੀ ਹੈ                                                                      | ਵਿਕਰੇਤਾ-ਵਿਸ਼ੇਸ਼ ਆਕਾਰ-ਸਚੇਤ ਮਿਡਲਵੇਅਰ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ         |

ਹਾਰਡਵੇਅਰ: ਪ੍ਰਤੀ-ਇੰਸਟੈਂਸ ਸਮਕਾਲੀ ਲੰਬੀਆਂ `/v1/responses` ਇੱਕ **ਮੈਮੋਰੀ-ਬਜਟ** ਦਾ ਸਵਾਲ ਹਨ (ਹੀਪ + ਇਨਫਲਾਈਟ-ਬਾਈਟ / #10110)। `N` ਸੁਤੰਤਰ `DATA_DIR`s ਫਿਰ ਵੀ ਹੀਪਾਂ ਨੂੰ ਗੁਣਾ ਕਰਦੇ ਹਨ: ਹੋਸਟ RAM ਨੂੰ `N × cgroup` ਸੰਭਾਲਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਨਾ ਕਿ “N=8 ਵਾਲਾ ਇੱਕ 16 Gi pod।” ਇੱਕ SQLite ਫ਼ਾਈਲ ਉੱਤੇ ਕਦੇ ਵੀ `replicas > 1` ਨਾ ਵਰਤੋ।

Compose ਖਾਕਾ (ਦੋ ਹੀਪ, ਦੋ ਵਾਲਿਊਮ — `deploy.replicas: 2` ਨਹੀਂ):

```yaml
services:
  omniroute-a:
    image: diegosouzapw/omniroute:3.8.49
    environment:
      DATA_DIR: /app/data
      OMNIROUTE_MEMORY_MB: "12288"
      QUOTA_STORE_DRIVER: redis
      QUOTA_STORE_REDIS_URL: redis://redis:6379
    volumes: [omniroute-a-data:/app/data]
    ports: ["20128:20128"]
  omniroute-b:
    image: diegosouzapw/omniroute:3.8.49
    environment:
      DATA_DIR: /app/data
      OMNIROUTE_MEMORY_MB: "12288"
      QUOTA_STORE_DRIVER: redis
      QUOTA_STORE_REDIS_URL: redis://redis:6379
    volumes: [omniroute-b-data:/app/data]
    ports: ["20138:20128"]
volumes:
  omniroute-a-data:
  omniroute-b-data:
```

ਇਨ-ਪ੍ਰੋਸੈਸ ਘਣਤਾ (HTTP isolate ਤੋਂ ਬਾਹਰ ਕੰਪ੍ਰੈਸ਼ਨ) [#11023](https://github.com/diegosouzapw/OmniRoute/issues/11023) ਹੈ। ਸਾਂਝੀ ਟਿਕਾਊ ਸਟੇਟ ਉੱਤੇ ਇੱਕ ਲੌਜਿਕਲ ਕਲੱਸਟਰ [#8075](https://github.com/diegosouzapw/OmniRoute/issues/8075) ਹੈ।

## Docker ਦੇ ਅੰਦਰ Gemini ਖੇਤਰੀ ਤਰੁੱਟੀਆਂ

Google AI Studio / Gemini API, FAILED_PRECONDITION ਦੇ ਨਾਲ HTTP 400 ਅਤੇ
`User location is not supported for the API use.` ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਹੋਸਟ ਉੱਤੇ ਸਫਲ ਬੇਨਤੀ
ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕੰਟੇਨਰ ਵੀ ਉਹੀ ਆਉਟਬਾਊਂਡ ਰੂਟ ਵਰਤਦਾ ਹੈ। DNS ਕ੍ਰਮ,
IPv4/IPv6 ਕਨੈਕਟਿਵਿਟੀ, VPN ਰੂਟਿੰਗ ਅਤੇ ਸੰਰਚਿਤ ਪ੍ਰਾਕਸੀਆਂ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
[Google ਦੇ ਸਮਰਥਿਤ ਖੇਤਰਾਂ](https://ai.google.dev/gemini-api/docs/available-regions)
ਦੇ ਨਾਲ-ਨਾਲ ਅਸਲ ਕਨੈਕਸ਼ਨ ਰੂਟ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ; ਸਿਰਫ਼ ਇਹ ਤਰੁੱਟੀ ਕਿਸੇ ਖ਼ਰਾਬ API ਕੁੰਜੀ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦੀ।

### ਕਨੈਕਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਪ੍ਰਾਕਸੀ ਨੂੰ ਤਰਜੀਹ ਦਿਓ

ਪ੍ਰਭਾਵਿਤ Gemini ਕਨੈਕਸ਼ਨ ਲਈ OmniRoute ਦੀ
[ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਪ੍ਰਾਕਸੀ ਸੰਰਚਨਾ](../ops/PROXY_GUIDE.md#4-level-proxy-system)
ਵਰਤੋ, ਫਿਰ ਉਸੇ ਮਾਡਲ ਨਾਲ **ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ** ਅਤੇ ਇੱਕ ਛੋਟੀ ਬੇਨਤੀ ਦੁਹਰਾਓ।
ਇਸ ਨਾਲ ਰੂਟਿੰਗ ਤਬਦੀਲੀ ਉਸੇ ਕਨੈਕਸ਼ਨ ਤੱਕ ਸੀਮਿਤ ਰਹਿੰਦੀ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰਾਕਸੀ ਤੱਕ
ਕੰਟੇਨਰ ਤੋਂ ਪਹੁੰਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਵਾਸਤਵ ਵਿੱਚ ਉਸੇ ਨੂੰ ਚੁਣਦਾ ਹੈ।
ਰੂਟ ਬਦਲਣ ਨਾਲ ਅੱਪਸਟ੍ਰੀਮ ਖੇਤਰੀ ਯੋਗਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਮਿਲਦੀ।

### ਹੋਸਟ ਅਤੇ ਕੰਟੇਨਰ ਨੈੱਟਵਰਕਿੰਗ ਦੀ ਤੁਲਨਾ ਕਰੋ

ਪ੍ਰਮਾਣਿਤ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ ਕੁੰਜੀ, ਮਾਡਲ ਅਤੇ ਬੇਨਤੀ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ; ਕਿਸੇ ਮੁੱਦੇ ਵਿੱਚ
ਕਦੇ ਵੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ, ਪ੍ਰਾਕਸੀ ਪਾਸਵਰਡ ਜਾਂ ਪੂਰੇ ਪ੍ਰਮਾਣੀਕਰਨ ਹੈਡਰ ਪੇਸਟ ਨਾ ਕਰੋ।
ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ OS ਰਿਜ਼ਾਲਵਰ ਕਿਹੜੇ ਐਡਰੈੱਸ ਪਰਿਵਾਰ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਹੋਸਟ ਅਤੇ
ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਇੱਕੋ ਕਮਾਂਡ ਵਰਤਦੇ ਹੋਏ:

```bash
node -e 'require("node:dns").lookup("generativelanguage.googleapis.com", {all: true}, (error, addresses) => { if (error) { console.error(error.code); process.exitCode = 1; return; } console.log(addresses.map(({family}) => family)); })'
docker compose exec omniroute node -e 'require("node:dns").lookup("generativelanguage.googleapis.com", {all: true}, (error, addresses) => { if (error) { console.error(error.code); process.exitCode = 1; return; } console.log(addresses.map(({family}) => family)); })'
```

`omniroute` ਨੂੰ ਉਸ ਸੇਵਾ ਨਾਲ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, `omniroute-web`)।
ਇਹ ਕਮਾਂਡਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਜਾਂ IP ਐਡਰੈੱਸਾਂ ਤੋਂ ਬਿਨਾਂ ਐਡਰੈੱਸ ਪਰਿਵਾਰ ਪ੍ਰਿੰਟ ਕਰਦੀਆਂ ਹਨ।
ਵਾਪਸ ਆਇਆ `6` ਸਿਰਫ਼ IPv6 DNS ਨਤੀਜਾ ਦਰਸਾਉਂਦਾ ਹੈ: ਇਹ ਵਰਤਣਯੋਗ IPv6 ਰੂਟ ਜਾਂ
API ਪਹੁੰਚ ਨੂੰ **ਸਾਬਤ ਨਹੀਂ** ਕਰਦਾ। ਜਿੱਥੇ `curl` ਇੰਸਟਾਲ ਹੈ, ਦੋਵੇਂ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ
`curl -4 -I https://generativelanguage.googleapis.com` ਦੀ ਤੁਲਨਾ
`curl -6 -I https://generativelanguage.googleapis.com` ਨਾਲ ਕਰੋ।
HTTP ਜਵਾਬ ਉਸ ਜਾਂਚ ਲਈ ਕਨੈਕਟਿਵਿਟੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਗੈਰ-ਪ੍ਰਮਾਣਿਤ
ਤਰੁੱਟੀ ਹੋਵੇ; ਕੇਵਲ ਪ੍ਰਮਾਣਿਤ ਮਾਡਲ ਬੇਨਤੀ ਹੀ Gemini ਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ।

### ਹੋਸਟ-ਪੱਧਰੀ ਵਿਕਲਪ: ਕਾਰਜਸ਼ੀਲ IPv6 ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਨੀਤੀ

[#12762](https://github.com/diegosouzapw/OmniRoute/issues/12762) ਦੇ ਰਿਪੋਰਟਰ ਨੇ
ਆਪਣੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਕੰਟੇਨਰ IPv6 ਸਮਰੱਥ ਕਰਕੇ ਅਤੇ glibc ਐਡਰੈੱਸ ਚੋਣ ਬਦਲ ਕੇ ਪਹੁੰਚ
ਮੁੜ ਬਹਾਲ ਕੀਤੀ। ਇਸਨੂੰ ਵਾਤਾਵਰਨ-ਵਿਸ਼ੇਸ਼ ਵਿਕਲਪ ਵਜੋਂ ਲਓ। ਰਿਜ਼ਾਲਵਰ ਤਰਜੀਹਾਂ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ
ਕਾਰਜਸ਼ੀਲ ਹੋਸਟ IPv6, ਕੰਟੇਨਰ ਈਗ੍ਰੈੱਸ/ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਨਿੱਜੀ ULA ਐਡਰੈੱਸ ਜਨਤਕ IPv6 ਕਨੈਕਟਿਵਿਟੀ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ।

Compose ਦੇ ਡਿਫਾਲਟ ਨੈੱਟਵਰਕ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਜੁੜੀਆਂ ਸੇਵਾਵਾਂ ਲਈ, ਇਹ ਫ੍ਰੈਗਮੈਂਟ
ਉਸ ਨੈੱਟਵਰਕ ਉੱਤੇ IPv6 ਸਮਰੱਥ ਕਰਦਾ ਹੈ; ਆਪਣੀ ਸੇਵਾ, ਪੋਰਟਾਂ, ਵਾਲੀਅਮਾਂ ਅਤੇ ਸੰਰਚਨਾ ਦਾ
ਬਾਕੀ ਹਿੱਸਾ ਬਰਕਰਾਰ ਰੱਖੋ:

```yaml
networks:
  default:
    enable_ipv6: true
```

ਨਾਮਿਤ ਨੈੱਟਵਰਕ ਲਈ, ਇਸਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਸਮਰੱਥ ਕਰੋ ਜਿਸ ਨਾਲ ਸੇਵਾ ਵਾਸਤਵ ਵਿੱਚ ਜੁੜਦੀ ਹੈ।
Docker ਇੱਕ ULA ਸਬਨੈੱਟ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ; ਸਪਸ਼ਟ, ਨਾ-ਓਵਰਲੈਪ ਹੋਣ ਵਾਲਾ ਸਬਨੈੱਟ
ਸਿਰਫ਼ ਉਦੋਂ ਚੁਣੋ ਜਦੋਂ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੋਵੇ।
[Docker IPv6 ਨੈੱਟਵਰਕਿੰਗ](https://docs.docker.com/engine/daemon/ipv6/)
ਅਤੇ [Compose ਨੈੱਟਵਰਕ ਵਿਕਲਪ](https://docs.docker.com/reference/compose-file/networks/#enable_ipv6) ਵੇਖੋ।

ਇੱਕ **glibc-ਅਧਾਰਿਤ ਇਮੇਜ** ਉੱਤੇ, `/etc/gai.conf` ਐਡਰੈੱਸ ਚੋਣ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ।
ਮੌਜੂਦਾ ਰਿਪੋਜ਼ਟਰੀ Dockerfile Debian ਵਰਤਦੀ ਹੈ; ਕਸਟਮ musl-ਅਧਾਰਿਤ ਇਮੇਜਾਂ ਇਹ ਪ੍ਰਣਾਲੀ
ਸਾਂਝੀ ਨਹੀਂ ਕਰਦੀਆਂ। ਰਿਪੋਰਟ ਕੀਤੀ ਤਬਦੀਲੀ ULA ਲੇਬਲ ਨੂੰ `label fc00::/7 6` ਤੋਂ
`label fc00::/7 1` ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਇਮੇਜ ਦੀ ਪੂਰੀ ਨੀਤੀ ਸਾਰਣੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਇਸ ਦੀਆਂ
ਹੋਰ ਐਂਟਰੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਇੱਕ `label` ਜਾਂ `precedence` ਐਂਟਰੀ ਜੋੜਨ ਨਾਲ ਉਹ
ਡਿਫਾਲਟ ਸਾਰਣੀ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਬਦਲੀ ਹੋਈ ਲਾਈਨ ਵਾਲੀ ਫਾਇਲ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।
[glibc ਸੰਰਚਨਾ ਹਵਾਲਾ](https://github.com/bminor/glibc/blob/master/posix/gai.conf)
ਉਨ੍ਹਾਂ ਅਰਥ-ਨਿਯਮਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਸਮੀਖਿਆ ਕੀਤੀ ਫਾਇਲ ਨੂੰ `/etc/gai.conf`
ਉੱਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ ਢੰਗ ਨਾਲ ਬਾਈਂਡ-ਮਾਊਂਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸੇਵਾ ਮੁੜ ਬਣਾਓ।

ਇਹ ਉਸ ਕੰਟੇਨਰ ਦੇ **ਸਾਰੇ ਆਉਟਬਾਊਂਡ ਟ੍ਰੈਫਿਕ** ਲਈ OS ਐਡਰੈੱਸ ਚੋਣ ਬਦਲਦਾ ਹੈ।
ਇਹ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ IPv6 ਚੁਣਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ: Node ਦਾ DNS ਕ੍ਰਮ ਅਤੇ
ਕਨੈਕਸ਼ਨ ਚੋਣ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਖ਼ਾਸ ਤੌਰ ਉੱਤੇ, `--dns-result-order=ipv4first`
IPv4 ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਅਤੇ IPv4-ਮਾਤਰ ਅਸਫਲਤਾ ਲਈ ਉਪਾਅ ਨਹੀਂ ਹੈ।
[Node DNS ਕ੍ਰਮ](https://nodejs.org/api/dns.html#dnssetdefaultresultorderorder) ਵੇਖੋ।

ਹੋਸਟ-ਪੱਧਰੀ ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ Gemini ਅਤੇ ਆਪਣੇ ਹੋਰ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਮੁੜ ਜਾਂਚ ਕਰੋ।
ਵਾਪਸ ਪਿਛਲੀ ਸਥਿਤੀ ਵਿੱਚ ਜਾਣ ਲਈ, ਕਸਟਮ `gai.conf` ਮਾਊਂਟ ਹਟਾਓ, ਪਿਛਲੀ ਨੈੱਟਵਰਕ ਸੰਰਚਨਾ
ਮੁੜ ਬਹਾਲ ਕਰੋ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਅੰਤਰਾਲ ਦੌਰਾਨ ਪ੍ਰਭਾਵਿਤ ਸੇਵਾ/ਨੈੱਟਵਰਕ ਨੂੰ ਮੁੜ ਬਣਾਓ।
ਨੈੱਟਵਰਕ ਮੁੜ ਬਣਾਉਣ ਨਾਲ ਇਸ ਨਾਲ ਜੁੜੇ ਹੋਰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਵਿਘਨ ਪੈ ਸਕਦਾ ਹੈ;
ਸਥਾਈ ਡਾਟਾ ਵਾਲੀਅਮ ਨੂੰ ਨਾ ਮਿਟਾਓ।

## ਮਹੱਤਵਪੂਰਨ ਨੋਟਸ

- **SQLite WAL ਮੋਡ:** `docker stop` ਨੂੰ ਪੂਰਾ ਹੋਣ ਦਿਓ ਤਾਂ ਜੋ OmniRoute ਨਵੀਨਤਮ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ `storage.sqlite` ਵਿੱਚ ਚੈਕਪੌਇੰਟ ਕਰ ਸਕੇ। ਨਾਲ ਸ਼ਾਮਲ Compose ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ 40s ਦੀ ਸਟਾਪ ਗ੍ਰੇਸ ਮਿਆਦ ਸੈੱਟ ਕੀਤੀ ਹੋਈ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਮੇਜ ਨੂੰ ਸਿੱਧਾ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ `--stop-timeout 40` ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ।
- **`DISABLE_SQLITE_AUTO_BACKUP`:** ਜੇ ਨਿਯਮਤ/ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਲੇ ਬੈਕਅੱਪ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਸ ਨੂੰ `true` 'ਤੇ ਸੈੱਟ ਕਰੋ। ਮੌਜੂਦਾ ਡੇਟਾਬੇਸ ਦੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਫਿਰ ਵੀ ਆਪਣਾ ਟਿਕਾਊ ਸੁਰੱਖਿਆ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਵਿਆਪਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਰਡ ਲੋੜੀਂਦਾ ਹੈ।
- **ਡੇਟਾ ਸਥਿਰਤਾ:** ਕੰਟੇਨਰ ਰੀਸਟਾਰਟਾਂ ਦੌਰਾਨ ਆਪਣੇ ਡੇਟਾਬੇਸ, ਕੁੰਜੀਆਂ ਅਤੇ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਹਮੇਸ਼ਾ `/app/data` 'ਤੇ ਇੱਕ ਵਾਲਿਊਮ ਮਾਊਂਟ ਕਰੋ।
- **ਪੋਰਟ ਸੰਰਚਨਾ:** ਡਿਫੌਲਟ `20128` ਪੋਰਟ ਨੂੰ ਬਦਲਣ ਲਈ `PORT` ਇਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰੋ।

## ਇਹ ਵੀ ਵੇਖੋ

- [VM ਡਿਪਲੌਇਮੈਂਟ ਗਾਈਡ](../ops/VM_DEPLOYMENT_GUIDE.md) — VM + nginx + Cloudflare ਸੈੱਟਅੱਪ
- [Fly.io ਡਿਪਲੌਇਮੈਂਟ ਗਾਈਡ](../ops/FLY_IO_DEPLOYMENT_GUIDE.md) — Fly.io 'ਤੇ ਡਿਪਲੌਇ ਕਰੋ
- [ਇਨਵਾਇਰਨਮੈਂਟ ਸੰਰਚਨਾ](../reference/ENVIRONMENT.md) — ਪੂਰਾ `.env` ਹਵਾਲਾ