Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Docker Compose

Any Linux, macOS or Windows host with Docker. Five minutes.

Cualquier host Linux, macOS o Windows con Docker. Cinco minutos.

Docker が入っている Linux、macOS、Windows のホストなら何でも。5 分です。

Любой хост с Docker: Linux, macOS или Windows. Пять минут.

Docker رکھنے والا کوئی بھی Linux، macOS یا Windows ہوسٹ۔ پانچ منٹ۔

任何装了 Docker 的 Linux、macOS 或 Windows 主机。五分钟。

任何裝了 Docker 的 Linux、macOS 或 Windows 主機。五分鐘。

Dowolny host z Dockerem: Linux, macOS albo Windows. Pięć minut.

N'importe quel hôte Linux, macOS ou Windows avec Docker. Cinq minutes.

Un host Linux, macOS o Windows qualsiasi con Docker. Cinque minuti.

Jeder Linux-, macOS- oder Windows-Host mit Docker. Fünf Minuten.

Host Linux, macOS atau Windows mana pun yang punya Docker. Lima menit.

Qualquer host Linux, macOS ou Windows com Docker. Cinco minutos.

Docker Compose is the path I used to capture this guide, so it is the one described in most detail.

Docker Compose es el camino que usé para capturar esta guía, así que es el que describo con más detalle.

このガイドを作るのに使ったのは Docker Compose なので、いちばん詳しく書いてあるのもこれです。

Docker Compose является тем путём, которым я снимал это руководство, поэтому он и описан подробнее всех.

یہ رہنما میں نے Docker Compose کے ذریعے تیار کیا، اس لیے سب سے تفصیل سے بھی یہی راستہ بیان ہوا ہے۔

这份指南是我用 Docker Compose 做出来的，所以它也是写得最详细的一条路径。

這份指南是我用 Docker Compose 做出來的，所以它也是寫得最詳細的一條路徑。

Na Docker Compose zbierałem materiały do tego przewodnika, więc tę ścieżkę opisuję najdokładniej.

Docker Compose est le chemin que j'ai emprunté pour capturer ce guide, c'est donc celui qui est décrit le plus en détail.

Docker Compose è la strada che ho seguito per realizzare questa guida, quindi è quella descritta più nel dettaglio.

Docker Compose ist der Weg, über den ich diesen Leitfaden aufgenommen habe, deshalb ist er am ausführlichsten beschrieben.

Docker Compose adalah jalur yang saya pakai untuk menyusun panduan ini, jadi jalur inilah yang dijelaskan paling rinci.

O Docker Compose foi o caminho que usei para capturar este guia, então é o descrito com mais detalhe.

What you need

Qué necesitas

必要なもの

Что нужно

آپ کو کیا درکار ہے

你需要什么

你需要什麼

Czego potrzebujesz

Ce qu'il vous faut

Cosa ti serve

Was du brauchst

Yang Anda perlukan

O que você precisa

Docker with the Compose plugin, and a free port. That is the whole list. You do not need to clone the repository, and nothing is built from source.

Docker con el plugin Compose, y un puerto libre. Esa es toda la lista. No necesitas clonar el repositorio, y no se compila nada desde el código.

Compose プラグイン入りの Docker と、空いているポート。必要なのはこれだけです。リポジトリを clone する必要はなく、ソースから何かをビルドすることもありません。

Docker с плагином Compose и свободный порт. Это весь список. Клонировать репозиторий не нужно, и ничего не собирается из исходников.

Compose پلگ اِن کے ساتھ Docker، اور ایک خالی پورٹ۔ فہرست بس اتنی ہے۔ نہ ریپازٹری clone کرنی ہے، نہ کچھ سورس سے بنتا ہے۔

带 Compose 插件的 Docker，外加一个空闲端口。清单就这些。你不用 clone 仓库，也没有任何东西要从源码构建。

帶 Compose 外掛的 Docker，外加一個空閒連接埠。清單就這些。你不用 clone 儲存庫，也沒有任何東西要從原始碼建置。

Dockera z wtyczką Compose i wolnego portu. To cała lista. Nie musisz klonować repozytorium, nic też nie jest budowane ze źródeł.

Docker avec le plugin Compose, et un port libre. Voilà toute la liste. Vous n'avez pas besoin de cloner le dépôt, et rien n'est compilé depuis les sources.

Docker con il plugin Compose, e una porta libera. La lista è tutta qui. Non devi clonare il repository, e non si compila niente dai sorgenti.

Docker mit dem Compose-Plugin und einen freien Port. Das ist die ganze Liste. Du musst das Repository nicht klonen, und nichts wird aus dem Quellcode gebaut.

Docker dengan plugin Compose, dan satu port yang kosong. Itu seluruh daftarnya. Anda tidak perlu meng-clone repository, dan tidak ada yang dibangun dari source.

Docker com o plugin Compose, e uma porta livre. A lista é essa. Você não precisa clonar o repositório, e nada é compilado a partir do código-fonte.

The shortest possible start

El arranque más corto posible

いちばん短い始め方

Самый короткий старт

سب سے مختصر آغاز

最短的开始方式

最短的開始方式

Najkrótszy możliwy start

Le démarrage le plus court possible

L'avvio più breve possibile

Der kürzestmögliche Start

Cara memulai yang sesingkat mungkin

O começo mais curto possível

If you only want to look at it, one command is enough:

Si solo quieres echarle un vistazo, basta con un comando:

とりあえず見てみたいだけなら、コマンド一つで足ります。

Если вы просто хотите посмотреть, хватит одной команды:

اگر آپ صرف دیکھنا چاہتے ہیں تو ایک ہی کمانڈ کافی ہے:

如果你只想先看看，一条命令就够了：

如果你只想先看看，一條命令就夠了：

Jeśli chcesz tylko rzucić okiem, wystarczy jedno polecenie:

Si vous voulez seulement y jeter un œil, une commande suffit :

Se vuoi solo dargli un'occhiata, basta un comando:

Wenn du es dir nur ansehen willst, reicht ein Befehl:

Kalau Anda hanya ingin melihat-lihat, satu perintah sudah cukup:

Se você só quer dar uma olhada, um comando basta:

docker run -p 3000:3000 ghcr.io/libredb/libredb-studio:0.17.0

Open http://localhost:3000. On a first run with no credentials set, the app generates an administrator password and prints it to the container log. Read it with docker logs.

Abre http://localhost:3000. En la primera ejecución, sin credenciales configuradas, la aplicación genera una contraseña de administrador y la imprime en el log del contenedor. Léela con docker logs.

http://localhost:3000 を開きます。認証情報を何も設定していない初回起動では、アプリが管理者パスワードを生成してコンテナのログに出力します。docker logs で読み取ってください。

Откройте http://localhost:3000. При первом запуске без заданных учётных данных приложение генерирует пароль администратора и печатает его в лог контейнера. Прочитайте его через docker logs.

http://localhost:3000 کھولیں۔ پہلی بار چلانے پر، جب کوئی سندات مقرر نہ ہوں، ایپ ایک ایڈمنسٹریٹر پاس ورڈ بناتی ہے اور اسے کنٹینر کے لاگ میں چھاپ دیتی ہے۔ اسے docker logs سے پڑھ لیں۔

打开 http://localhost:3000。首次运行且未设置任何凭据时，应用会生成一个管理员密码并打印到容器日志里。用 docker logs 读出来。

打開 http://localhost:3000。首次執行且未設定任何認證資訊時，應用會產生一個管理員密碼並印到容器日誌裡。用 docker logs 讀出來。

Otwórz http://localhost:3000. Przy pierwszym uruchomieniu, gdy nie ustawiłeś żadnych danych logowania, aplikacja generuje hasło administratora i wypisuje je do logu kontenera. Odczytasz je poleceniem docker logs.

Ouvrez http://localhost:3000. Au premier lancement, sans identifiants définis, l'application génère un mot de passe administrateur et l'écrit dans le log du container. Lisez-le avec docker logs.

Apri http://localhost:3000. Al primo avvio, senza credenziali impostate, l'app genera una password di amministratore e la stampa nel log del container. Leggila con docker logs.

Öffne http://localhost:3000. Beim ersten Start ohne gesetzte Zugangsdaten erzeugt die App ein Administrator-Passwort und schreibt es ins Container-Log. Lies es mit docker logs aus.

Buka http://localhost:3000. Pada run pertama tanpa kredensial yang diset, aplikasi membuat password administrator dan mencetaknya ke log container. Baca lewat docker logs.

Abra http://localhost:3000. Na primeira execução, sem credenciais definidas, o app gera uma senha de administrador e imprime no log do container. Leia com docker logs.

The version you actually want to keep

La versión que de verdad quieres conservar

実際に残しておきたいほうの構成

Та версия, которую вы действительно захотите оставить

وہ ترتیب جو آپ واقعی رکھنا چاہیں گے

你真正想留下来的那个版本

你真正想留下來的那個版本

Wersja, którą naprawdę chcesz u siebie zostawić

La version que vous voudrez vraiment garder

La versione che poi vuoi davvero tenere

Die Variante, die du wirklich behalten willst

Versi yang sebenarnya ingin Anda simpan

A versão que você vai querer mesmo manter

For anything that outlives the afternoon, give it a compose file so the settings and the stored connections survive a restart. This is close to the stack I ran while writing the guide:

Para cualquier cosa que dure más de una tarde, dale un fichero compose para que los ajustes y las conexiones guardadas sobrevivan a un reinicio. Esto se parece mucho a la pila que tuve en marcha mientras escribía la guía:

その日限りで終わらないものには compose ファイルを用意して、設定と保存済みの接続が再起動をまたいで残るようにしてください。以下は、このガイドを書いている間に私が動かしていた構成とほぼ同じです。

Для всего, что переживёт этот вечер, дайте приложению compose-файл, чтобы настройки и сохранённые подключения пережили перезапуск. Это почти тот стек, который у меня работал, пока я писал руководство:

جو چیز آج کی شام سے آگے چلنی ہو، اسے ایک compose فائل دیں تاکہ ترتیبات اور محفوظ کیے گئے کنکشن ری اسٹارٹ کے بعد بھی باقی رہیں۔ یہ اس اسٹیک کے بہت قریب ہے جو رہنما لکھتے وقت میرے پاس چل رہا تھا:

只要是能活过今天下午的部署，就给它一个 compose 文件，让配置和已保存的连接能熬过重启。下面这份和我写指南时跑的那套几乎一样：

只要是能活過今天下午的部署，就給它一個 compose 檔案，讓設定和已儲存的連線能熬過重啟。下面這份和我寫指南時跑的那套幾乎一樣：

Jeśli ma przeżyć dłużej niż jedno popołudnie, daj mu plik compose, żeby ustawienia i zapisane połączenia przetrwały restart. To jest blisko stacka, na którym pracowałem, pisząc ten przewodnik:

Pour tout ce qui doit survivre à l'après-midi, donnez-lui un fichier compose afin que les réglages et les connexions enregistrées survivent à un redémarrage. Voici à peu de chose près la stack que j'ai fait tourner en écrivant ce guide :

Per qualsiasi cosa che duri più di un pomeriggio, dagli un file compose così le impostazioni e le connessioni salvate sopravvivono a un riavvio. Questo è vicino allo stack che ho fatto girare mentre scrivevo la guida:

Für alles, was den Nachmittag überdauert, gib ihm eine Compose-Datei, damit die Einstellungen und die gespeicherten Verbindungen einen Neustart überleben. Das kommt dem Stack nahe, den ich beim Schreiben des Leitfadens laufen hatte:

Untuk apa pun yang umurnya lebih panjang dari satu sore, beri ia compose file supaya setelan dan koneksi yang tersimpan selamat dari restart. Ini mendekati stack yang saya jalankan saat menulis panduan ini:

Para qualquer coisa que dure mais que uma tarde, dê a ele um arquivo compose para que as configurações e as conexões salvas sobrevivam a um restart. Isto é parecido com a stack que rodei enquanto escrevia o guia:

# compose.yaml
services:
  studio:
    image: ghcr.io/libredb/libredb-studio:0.17.0
    container_name: libredb-studio
    ports: ["3000:3000"]
    environment:
      ADMIN_EMAIL: admin@libredb.org
      ADMIN_PASSWORD: choose-something-long
      JWT_SECRET: "CHANGE_ME"   # openssl rand -base64 32
    volumes:
      - studio-data:/app/data
    restart: unless-stopped

volumes:
  studio-data:

The JWT_SECRET above is deliberately too short to work. Paste the real output of openssl rand -base64 32 in its place. Leave the placeholder and the app refuses to start and tells you why: JWT_SECRET is too short. That refusal is the behaviour you want, because a secret printed in a guide is a secret everybody has.

El JWT_SECRET de arriba es deliberadamente demasiado corto para funcionar. Pega en su lugar la salida real de openssl rand -base64 32. Si dejas el marcador, la aplicación se niega a arrancar y te dice por qué: JWT_SECRET is too short. Ese rechazo es justo el comportamiento que quieres, porque un secreto impreso en una guía es un secreto que tiene todo el mundo.

上の JWT_SECRET は、わざと短すぎて通らないようにしてあります。openssl rand -base64 32 の実際の出力を貼り付けてください。仮の値のままにするとアプリは起動を拒み、理由も告げます。JWT_SECRET is too short と。この拒否こそ望ましい挙動です。ガイドに印刷された秘密は、誰もが持っている秘密だからです。

JWT_SECRET выше намеренно слишком короткий, чтобы работать. Вставьте вместо него настоящий вывод openssl rand -base64 32. Если оставите заглушку, приложение откажется запускаться и скажет почему: JWT_SECRET is too short. Этот отказ и есть нужное поведение, потому что секрет, напечатанный в руководстве, есть у всех.

اوپر والا JWT_SECRET جان بوجھ کر اتنا چھوٹا رکھا گیا ہے کہ چل نہ سکے۔ اس کی جگہ openssl rand -base64 32 کا اصل نتیجہ چسپاں کریں۔ اگر یہ عارضی قدر وہیں چھوڑ دی تو ایپ چلنے سے انکار کر دے گی اور وجہ بھی بتا دے گی: JWT_SECRET is too short۔ یہی انکار وہ رویہ ہے جو آپ کو چاہیے، کیونکہ رہنما میں چھپا ہوا راز وہ راز ہے جو سب کے پاس ہے۔

上面那个 JWT_SECRET 是故意写得太短、跑不起来的。请把 openssl rand -base64 32 的真实输出粘贴到那里。要是把占位符留着，应用会拒绝启动，并且告诉你原因：JWT_SECRET is too short。这个拒绝正是你想要的行为，因为印在指南里的密钥，是人人都有的密钥。

上面那個 JWT_SECRET 是故意寫得太短、跑不起來的。請把 openssl rand -base64 32 的真實輸出貼到那裡。要是把佔位符留著，應用會拒絕啟動，並且告訴你原因：JWT_SECRET is too short。這個拒絕正是你想要的行為，因為印在指南裡的金鑰，是人人都有的金鑰。

Powyższy JWT_SECRET jest celowo za krótki, żeby zadziałać. Wklej w jego miejsce prawdziwe wyjście polecenia openssl rand -base64 32. Zostaw zaślepkę, a aplikacja odmówi startu i powie dlaczego: JWT_SECRET is too short. Ta odmowa to zachowanie, którego chcesz, bo sekret wydrukowany w przewodniku to sekret, który ma każdy.

Le JWT_SECRET ci-dessus est délibérément trop court pour fonctionner. Collez à sa place la vraie sortie de openssl rand -base64 32. Laissez la valeur d'exemple et l'application refuse de démarrer en vous disant pourquoi : JWT_SECRET is too short. Ce refus est le comportement que vous voulez, parce qu'un secret imprimé dans un guide est un secret que tout le monde possède.

Il JWT_SECRET qui sopra è volutamente troppo corto per funzionare. Al suo posto incolla l'output vero di openssl rand -base64 32. Se lasci il segnaposto l'app si rifiuta di partire e ti dice perché: JWT_SECRET is too short. Quel rifiuto è il comportamento che vuoi, perché un segreto stampato in una guida è un segreto che hanno tutti.

Das JWT_SECRET oben ist absichtlich zu kurz, um zu funktionieren. Setz an seine Stelle die echte Ausgabe von openssl rand -base64 32. Lässt du den Platzhalter stehen, startet die App nicht und sagt dir auch warum: JWT_SECRET is too short. Diese Verweigerung ist das Verhalten, das du willst, denn ein Secret, das in einem Leitfaden abgedruckt ist, ist ein Secret, das alle haben.

JWT_SECRET di atas sengaja dibuat terlalu pendek supaya tidak berfungsi. Tempelkan output asli dari openssl rand -base64 32 di tempatnya. Biarkan placeholder itu dan aplikasi menolak start sambil memberi tahu alasannya: JWT_SECRET is too short. Penolakan itu justru perilaku yang Anda inginkan, karena secret yang dicetak di sebuah panduan adalah secret milik semua orang.

O JWT_SECRET acima é curto demais de propósito para funcionar. Cole no lugar dele a saída real de openssl rand -base64 32. Deixe o placeholder e o app se recusa a subir e te diz por quê: JWT_SECRET is too short. Essa recusa é o comportamento que você quer, porque um segredo impresso num guia é um segredo que todo mundo tem.

docker compose up -d
docker compose logs -f studio

Which image to pin

Qué imagen fijar

どのイメージを固定するか

Какой образ закреплять

کون سی امیج پن کریں

该钉住哪个镜像

該釘住哪個映像檔

Który obraz przypiąć

Quelle image fixer

Quale immagine fissare

Welches Image du festnageln solltest

Image mana yang dipaku

Qual imagem fixar

The image line above names the default tag, and two siblings are published beside it. All three are the same application. ghcr.io/libredb/libredb-studio:0.17.0 is built on Debian and carries every driver, including Oracle's Thick mode, which needs Oracle Instant Client and has no musl build. :0.17.0-alpine is the same product on musl and gives up only that: Oracle Thin still connects. :0.17.0-alpine-slim is the smallest and the only one that trades a feature for size. It ships without the DuckDB driver, whose shared library is the largest removable thing in the image, and opening a DuckDB connection there does not fail as though the engine were unreachable: it answers DuckDB is not available in this deployment and then names the remedy: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Pulled on the machine that wrote this page, Docker reports the three at 903 MB, 530 MB and 259 MB, so the smallest is under a third of the default; your own figures will differ with the architecture you pull for. latest, latest-alpine and latest-alpine-slim move with each release, and the immutable sha- tags carry the same suffixes. The Helm chart's default stays the Debian tag; set image.tag to pin a variant.

La línea de la imagen de arriba nombra la etiqueta por defecto, y junto a ella se publican dos hermanas. Las tres son la misma aplicación. ghcr.io/libredb/libredb-studio:0.17.0 está construida sobre Debian y lleva todos los controladores, incluido el modo Thick de Oracle, que necesita Oracle Instant Client y no tiene compilación para musl. :0.17.0-alpine es el mismo producto sobre musl y renuncia solo a eso: Oracle Thin sigue conectando. :0.17.0-alpine-slim es la más pequeña y la única que cambia una función por tamaño. Sale sin el controlador de DuckDB, cuya biblioteca compartida es lo más grande que se puede quitar de la imagen, y abrir allí una conexión DuckDB no falla como si el motor estuviera inalcanzable: responde DuckDB is not available in this deployment y después nombra el remedio: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Descargadas en la máquina donde escribí esta página, las tres las da Docker en 903 MB, 530 MB y 259 MB, así que la más pequeña no llega a un tercio de la de por defecto; tus propias cifras cambiarán según la arquitectura para la que descargues. latest, latest-alpine y latest-alpine-slim se mueven con cada versión, y las etiquetas inmutables sha- llevan los mismos sufijos. El valor por defecto del chart de Helm sigue siendo la etiqueta de Debian; pon image.tag para fijar una variante.

上のイメージ行が名指ししているのは既定のタグで、その隣には兄弟が二つ公開されています。三つとも同じアプリケーションです。ghcr.io/libredb/libredb-studio:0.17.0 は Debian の上に建てられ、ドライバーをすべて積んでいます。Oracle の Thick モードも含みます。これは Oracle Instant Client を必要とし、musl 向けのビルドがありません。:0.17.0-alpine は musl に載せた同じ製品で、手放すのはそこだけです。Oracle の Thin モードなら変わらず接続できます。:0.17.0-alpine-slim はいちばん小さく、機能を容量と引き換えにする唯一のイメージです。DuckDB のドライバーを積んでいません。その共有ライブラリが、イメージから外せるもののうちいちばん大きいからです。しかもそこで DuckDB の接続を開いても、エンジンに届かないかのような落ち方はしません。DuckDB is not available in this deployment と答え、続けて手当ても名指しします。the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it と。このページを書いたマシンで pull したところ、Docker は三つを 903 MB、530 MB、259 MB と報告しました。いちばん小さいものは既定の三分の一を切ります。手元の数字は pull するアーキテクチャによって変わります。latest、latest-alpine、latest-alpine-slim はリリースごとに動き、変わらない sha- のタグは同じ接尾辞を持ちます。Helm チャートの既定は Debian のタグのままです。変種を固定したければ image.tag を設定してください。

Строка с образом выше называет тег по умолчанию, а рядом с ним опубликованы ещё два. Все три являются одним и тем же приложением. ghcr.io/libredb/libredb-studio:0.17.0 собран на Debian и несёт все драйверы, включая режим Thick у Oracle, которому нужен Oracle Instant Client и у которого нет сборки под musl. :0.17.0-alpine представляет собой тот же продукт на musl, и отдаёт он только это: Oracle в режиме Thin подключается по-прежнему. :0.17.0-alpine-slim является самым маленьким и единственным, кто меняет возможность на размер. Он выходит без драйвера DuckDB, чья разделяемая библиотека остаётся самым крупным, что вообще можно вынуть из образа, и попытка открыть подключение к DuckDB там не падает так, будто движок недоступен. Приложение отвечает DuckDB is not available in this deployment, а потом называет и лекарство: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. На машине, где я писал эту страницу, Docker показывает скачанную тройку как 903 МБ, 530 МБ и 259 МБ, то есть самый маленький занимает менее трети объёма образа по умолчанию; ваши собственные цифры будут другими, в зависимости от архитектуры, под которую вы скачиваете. latest, latest-alpine и latest-alpine-slim двигаются с каждым выпуском, а неизменяемые теги sha- несут те же суффиксы. Значением по умолчанию в чарте Helm остаётся тег Debian; чтобы закрепить вариант, задайте image.tag.

اوپر والی امیج کی سطر طے شدہ ٹیگ کا نام لیتی ہے، اور اس کے پہلو میں دو اور امیجیں بھی شائع ہوتی ہیں۔ تینوں ایک ہی ایپ ہیں۔ ghcr.io/libredb/libredb-studio:0.17.0 Debian پر بنی ہے اور ہر ڈرائیور ساتھ لاتی ہے، بشمول Oracle کا Thick موڈ، جسے Oracle Instant Client درکار ہے اور جس کا musl والا بلڈ سرے سے نہیں ہے۔ :0.17.0-alpine وہی چیز ہے، بس musl پر، اور صرف اتنا ہی چھوڑتی ہے: Oracle کا Thin موڈ پھر بھی جُڑ جاتا ہے۔ :0.17.0-alpine-slim سب سے چھوٹی ہے اور واحد ہے جو ایک خوبی حجم کے بدلے دے دیتی ہے۔ یہ DuckDB ڈرائیور کے بغیر آتی ہے، جس کی مشترکہ لائبریری امیج میں سے نکالی جا سکنے والی سب سے بڑی چیز ہے، اور وہاں DuckDB کا کنکشن کھولنے پر ایسی ناکامی نہیں ہوتی جیسے انجن تک پہنچ ہی نہ ہو۔ ایپ جواب دیتی ہے DuckDB is not available in this deployment اور پھر علاج کا نام بھی لے دیتی ہے: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it۔ جس مشین پر میں نے یہ صفحہ لکھا، وہاں کھینچنے پر Docker ان تینوں کو 903 MB، 530 MB اور 259 MB بتاتا ہے، یعنی سب سے چھوٹی طے شدہ امیج کے تہائی سے بھی کم ہے؛ آپ کے اپنے اعداد اُس آرکیٹیکچر کے ساتھ بدلیں گے جس کے لیے آپ کھینچتے ہیں۔ latest، latest-alpine اور latest-alpine-slim ہر ریلیز کے ساتھ سرکتے رہتے ہیں، اور نہ بدلنے والے sha- ٹیگ وہی لاحقے اٹھاتے ہیں۔ Helm چارٹ کی طے شدہ قدر Debian والا ٹیگ ہی رہتی ہے؛ کسی ایک قسم کو پن کرنا ہو تو image.tag مقرر کریں۔

上面那行镜像写的是默认标签，旁边还发布着两个兄弟。三个都是同一个应用。ghcr.io/libredb/libredb-studio:0.17.0 建在 Debian 上，带着每一个驱动，包括 Oracle 的 Thick 模式：它需要 Oracle Instant Client，而且没有 musl 版的构建。:0.17.0-alpine 是同一个产品换到 musl 上，放弃的也只有这一点：Oracle 的 Thin 模式照样连得上。:0.17.0-alpine-slim 最小，也是唯一一个拿功能换体积的。它不带 DuckDB 驱动，那个共享库是镜像里能拿掉的东西里最大的一个；而在那里打开 DuckDB 连接，并不会像引擎连不上那样失败，而是回答 DuckDB is not available in this deployment，然后点出补救的办法：the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it。在写这一页的机器上拉下来，Docker 报的三个大小是 903 MB、530 MB 和 259 MB，所以最小的那个不到默认那个的三分之一；你自己的数字会随你拉取的架构而不同。latest、latest-alpine 和 latest-alpine-slim 会随每次发布移动，而不可变的 sha- 标签带着同样的后缀。Helm chart 的默认值仍然是 Debian 那个标签；想钉住某个变体，就设 image.tag。

上面那行映像檔寫的是預設標籤，旁邊還發布著兩個兄弟。三個都是同一個應用。ghcr.io/libredb/libredb-studio:0.17.0 建在 Debian 上，帶著每一個驅動程式，包括 Oracle 的 Thick 模式：它需要 Oracle Instant Client，而且沒有 musl 版的建置。:0.17.0-alpine 是同一個產品換到 musl 上，放棄的也只有這一點：Oracle 的 Thin 模式照樣連得上。:0.17.0-alpine-slim 最小，也是唯一一個拿功能換體積的。它不帶 DuckDB 驅動程式，那個共享函式庫是映像檔裡能拿掉的東西裡最大的一個；而在那裡打開 DuckDB 連線，並不會像引擎連不上那樣失敗。它回答 DuckDB is not available in this deployment，然後點出補救的辦法：the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it。在寫這一頁的機器上拉下來，Docker 報的三個大小是 903 MB、530 MB 和 259 MB，所以最小的那個不到預設那個的三分之一；你自己的數字會隨你拉取的架構而不同。latest、latest-alpine 和 latest-alpine-slim 會隨每次發布移動，而不可變的 sha- 標籤帶著同樣的後綴。Helm chart 的預設值仍然是 Debian 那個標籤；想釘住某個變體，就設 image.tag。

Wiersz z obrazem powyżej nazywa domyślny tag, a obok niego wystawione są dwa bratnie obrazy. Wszystkie trzy to ta sama aplikacja. ghcr.io/libredb/libredb-studio:0.17.0 stoi na Debianie i niesie każdy sterownik, łącznie z trybem Thick Oracle'a, który wymaga Oracle Instant Client i nie ma buildu pod musl. :0.17.0-alpine to ten sam produkt na musl i oddaje tylko to jedno: Oracle w trybie Thin nadal się łączy. :0.17.0-alpine-slim jest najmniejszy i jako jedyny wymienia funkcję na rozmiar. Wychodzi bez sterownika DuckDB, którego biblioteka współdzielona jest największą rzeczą, jaką da się z obrazu wyjąć, a otwarcie połączenia z DuckDB nie kończy się tam błędem, jakby silnik był nieosiągalny. Aplikacja odpowiada DuckDB is not available in this deployment, a potem nazywa lekarstwo: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Ściągnięte na maszynie, na której pisałem tę stronę, wszystkie trzy pokazują się w Dockerze jako 903 MB, 530 MB i 259 MB, więc najmniejszy ma poniżej jednej trzeciej domyślnego; twoje własne liczby będą inne, zależnie od architektury, pod którą ściągasz. latest, latest-alpine i latest-alpine-slim przesuwają się z każdym wydaniem, a niezmienne tagi sha- noszą te same przyrostki. Domyślną wartością w charcie Helma pozostaje tag Debiana; ustaw image.tag, żeby przypiąć wariant.

La ligne d'image ci-dessus nomme le tag par défaut, et deux sœurs sont publiées à côté de lui. Toutes les trois sont la même application. ghcr.io/libredb/libredb-studio:0.17.0 est construite sur Debian et porte tous les pilotes, y compris le mode Thick d'Oracle, qui réclame Oracle Instant Client et n'a pas de build musl. :0.17.0-alpine est le même produit sur musl et n'abandonne que cela : Oracle Thin se connecte toujours. :0.17.0-alpine-slim est la plus petite et la seule à échanger une fonctionnalité contre de la taille. Elle sort sans le pilote DuckDB, dont la bibliothèque partagée est la plus grosse chose que l'on puisse retirer de l'image, et y ouvrir une connexion DuckDB n'échoue pas comme si le moteur était injoignable. Elle répond DuckDB is not available in this deployment puis nomme le remède : the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Tirées sur la machine où j'ai écrit cette page, Docker les donne à 903 Mo, 530 Mo et 259 Mo, donc la plus petite tient sous le tiers de celle par défaut ; vos propres chiffres varieront selon l'architecture pour laquelle vous les tirez. latest, latest-alpine et latest-alpine-slim bougent à chaque release, et les tags immuables sha- portent les mêmes suffixes. La valeur par défaut du chart Helm reste le tag Debian ; définissez image.tag pour fixer une variante.

La riga dell'immagine qui sopra nomina il tag predefinito, e accanto ne vengono pubblicate due sorelle. Tutte e tre sono la stessa applicazione. ghcr.io/libredb/libredb-studio:0.17.0 è costruita su Debian e porta tutti i driver, compresa la modalità Thick di Oracle, che ha bisogno di Oracle Instant Client e non ha una build musl. :0.17.0-alpine è lo stesso prodotto su musl e rinuncia solo a quella: Oracle Thin si collega ancora. :0.17.0-alpine-slim è la più piccola e l'unica che scambia una funzione con la dimensione. Esce senza il driver DuckDB, la cui libreria condivisa è la cosa più grande che si possa togliere dall'immagine, e aprire lì una connessione DuckDB non fallisce come se il motore fosse irraggiungibile: risponde DuckDB is not available in this deployment e poi nomina il rimedio: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Scaricate sulla macchina su cui ho scritto questa pagina, Docker le riporta a 903 MB, 530 MB e 259 MB, quindi la più piccola sta sotto un terzo di quella predefinita; i tuoi numeri cambieranno con l'architettura per cui scarichi. latest, latest-alpine e latest-alpine-slim si spostano a ogni release, e i tag immutabili sha- portano gli stessi suffissi. Il valore predefinito del chart Helm resta il tag Debian; imposta image.tag per fissare una variante.

Die Image-Zeile oben nennt den Standard-Tag, und zwei Geschwister sind daneben veröffentlicht. Alle drei sind dieselbe Anwendung. ghcr.io/libredb/libredb-studio:0.17.0 ist auf Debian gebaut und trägt jeden Treiber, auch Oracles Thick-Modus, der den Oracle Instant Client braucht und keinen musl-Build hat. :0.17.0-alpine ist dasselbe Produkt auf musl und gibt nur das auf: Oracle Thin verbindet sich weiterhin. :0.17.0-alpine-slim ist das kleinste und das einzige, das eine Funktion gegen Größe eintauscht. Es kommt ohne den DuckDB-Treiber, dessen Shared Library das Größte ist, was sich aus dem Image entfernen lässt, und eine DuckDB-Verbindung scheitert dort nicht so, als wäre die Engine nicht erreichbar. Es antwortet DuckDB is not available in this deployment und nennt dann die Abhilfe: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Auf der Maschine gezogen, auf der ich diese Seite geschrieben habe, meldet Docker die drei mit 903 MB, 530 MB und 259 MB, das kleinste liegt also unter einem Drittel des Standards; deine eigenen Zahlen fallen je nach Architektur, für die du ziehst, anders aus. latest, latest-alpine und latest-alpine-slim wandern mit jedem Release, und die unveränderlichen sha--Tags tragen dieselben Suffixe. Die Voreinstellung des Helm-Charts bleibt der Debian-Tag; setz image.tag, um eine Variante festzunageln.

Baris image di atas menyebut tag default, dan dua saudara diterbitkan di sebelahnya. Ketiganya adalah aplikasi yang sama. ghcr.io/libredb/libredb-studio:0.17.0 dibangun di atas Debian dan membawa semua driver, termasuk mode Thick milik Oracle, yang butuh Oracle Instant Client dan tidak punya build musl. :0.17.0-alpine adalah produk yang sama di atas musl dan hanya melepaskan itu: Oracle Thin tetap terhubung. :0.17.0-alpine-slim adalah yang paling kecil dan satu-satunya yang menukar sebuah fitur dengan ukuran. Ia keluar tanpa driver DuckDB, yang shared library-nya adalah benda terbesar yang bisa dibuang dari image, dan membuka koneksi DuckDB di sana tidak gagal seolah-olah engine-nya tidak terjangkau: ia menjawab DuckDB is not available in this deployment lalu menyebut obatnya: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Ditarik di mesin tempat saya menulis halaman ini, Docker melaporkan ketiganya di 903 MB, 530 MB dan 259 MB, jadi yang paling kecil ada di bawah sepertiga dari yang default; angka Anda sendiri akan berbeda mengikuti arsitektur yang Anda tarik. latest, latest-alpine dan latest-alpine-slim bergerak mengikuti setiap rilis, dan tag sha- yang tidak berubah membawa akhiran yang sama. Default chart Helm tetap tag Debian; set image.tag untuk memaku sebuah varian.

A linha da imagem acima nomeia a tag padrão, e duas irmãs são publicadas ao lado dela. As três são a mesma aplicação. ghcr.io/libredb/libredb-studio:0.17.0 é construída sobre Debian e carrega todos os drivers, incluindo o modo Thick da Oracle, que precisa do Oracle Instant Client e não tem build para musl. :0.17.0-alpine é o mesmo produto sobre musl e abre mão só disso: o Oracle Thin continua conectando. :0.17.0-alpine-slim é a menor e a única que troca um recurso por tamanho. Ela sai sem o driver do DuckDB, cuja biblioteca compartilhada é a maior coisa removível da imagem, e abrir ali uma conexão DuckDB não falha como se a engine estivesse inalcançável: ela responde DuckDB is not available in this deployment e então nomeia o remédio: the libredb-studio -alpine-slim image leaves it out to stay small; the default and -alpine tags ship it. Baixadas na máquina em que escrevi esta página, as três aparecem no Docker com 903 MB, 530 MB e 259 MB, então a menor não chega a um terço da padrão; os seus números vão mudar conforme a arquitetura para a qual você baixar. latest, latest-alpine e latest-alpine-slim andam a cada release, e as tags imutáveis sha- levam os mesmos sufixos. O padrão do chart Helm continua sendo a tag Debian; defina image.tag para fixar uma variante.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

The container picks its own bind address before Next.js prints anything, so the first line of the log is about the socket rather than the app. It prefers ::, which serves IPv4 and IPv6 through one listener, and prints http://[::1]:3000 for the local address rather than the word localhost. Set HOSTNAME to pin it. The log settles within a few seconds and the health endpoint answers:

El contenedor elige su dirección de escucha antes de que Next.js imprima nada, así que la primera línea del log habla del socket y no de la aplicación. Prefiere ::, que sirve IPv4 e IPv6 por un solo listener, e imprime http://[::1]:3000 como dirección local en lugar de la palabra localhost. Pon HOSTNAME para fijarla. El log se asienta en unos segundos y el endpoint de salud responde:

コンテナは Next.js が何かを出力する前に自分の待ち受けアドレスを決めるので、ログの一行目はアプリではなくソケットの話です。既定では :: を選び、ひとつのリスナーで IPv4 と IPv6 の両方を受けます。ローカルアドレスとしては localhost という語ではなく http://[::1]:3000 を表示します。固定したい場合は HOSTNAME を設定してください。ログは数秒で落ち着き、ヘルスエンドポイントはこう答えます。

Контейнер выбирает адрес прослушивания раньше, чем Next.js что-либо напечатает, поэтому первая строка лога говорит о сокете, а не о приложении. Он предпочитает ::, который обслуживает IPv4 и IPv6 через один слушатель, и печатает http://[::1]:3000 вместо слова localhost. Чтобы закрепить адрес, задайте HOSTNAME. Лог успокаивается за несколько секунд, и эндпоинт здоровья отвечает:

کنٹینر اپنا bind پتہ Next.js کے کچھ چھاپنے سے پہلے چن لیتا ہے، سو لاگ کی پہلی سطر ایپ کی نہیں، ساکٹ کی بات کرتی ہے۔ یہ :: کو ترجیح دیتا ہے، جو ایک ہی listener سے IPv4 اور IPv6 دونوں سنتا ہے، اور مقامی پتے کے طور پر localhost لکھنے کے بجائے http://[::1]:3000 چھاپتا ہے۔ اسے جمانا ہو تو HOSTNAME مقرر کریں۔ لاگ چند سیکنڈ میں ٹھہر جاتا ہے اور ہیلتھ اینڈ پوائنٹ یہ جواب دیتا ہے:

容器在 Next.js 打印任何东西之前就先挑好了自己的监听地址，所以日志第一行讲的是 socket，不是应用。它优先选 ::，用一个监听器同时服务 IPv4 和 IPv6，并且本地地址打印的是 http://[::1]:3000 而不是 localhost 这个词。想钉死就设 HOSTNAME。日志几秒内安定下来，健康检查端点这样回答：

容器在 Next.js 印出任何東西之前就先挑好了自己的監聽位址，所以日誌第一行講的是 socket，不是應用。它優先選 ::，用一個監聽器同時服務 IPv4 和 IPv6，並且本機位址印出的是 http://[::1]:3000 而不是 localhost 這個詞。想釘死就設 HOSTNAME。日誌幾秒內安定下來，健康檢查端點這樣回答：

Kontener wybiera sobie adres nasłuchu, zanim Next.js cokolwiek wypisze, więc pierwsza linia logu dotyczy socketu, a nie aplikacji. Woli ::, który obsługuje IPv4 i IPv6 jednym listenerem, i jako adres lokalny wypisuje http://[::1]:3000 zamiast słowa localhost. Ustaw HOSTNAME, żeby to przypiąć. Log uspokaja się w kilka sekund, a endpoint zdrowia odpowiada:

Le container choisit lui-même son adresse d'écoute avant que Next.js n'affiche quoi que ce soit, donc la première ligne du log parle du socket et non de l'application. Il préfère ::, qui sert IPv4 et IPv6 par un seul listener, et affiche http://[::1]:3000 comme adresse locale plutôt que le mot localhost. Définissez HOSTNAME pour le fixer. Le log se stabilise en quelques secondes et l'endpoint de santé répond :

Il container sceglie il proprio indirizzo di bind prima che Next.js stampi qualsiasi cosa, quindi la prima riga del log riguarda il socket e non l'app. Preferisce ::, che serve IPv4 e IPv6 con un solo listener, e per l'indirizzo locale stampa http://[::1]:3000 invece della parola localhost. Imposta HOSTNAME per fissarlo. Il log si assesta in pochi secondi e l'endpoint di health risponde:

Der Container wählt seine Bind-Adresse, bevor Next.js irgendetwas ausgibt, deshalb geht es in der ersten Zeile des Logs um den Socket und nicht um die App. Er bevorzugt ::, was IPv4 und IPv6 über einen Listener bedient, und gibt als lokale Adresse http://[::1]:3000 aus statt des Worts localhost. Setz HOSTNAME, um sie festzunageln. Das Log beruhigt sich nach wenigen Sekunden, und der Health-Endpunkt antwortet:

Container memilih bind address-nya sendiri sebelum Next.js mencetak apa pun, jadi baris pertama log berbicara soal socket, bukan soal aplikasi. Ia lebih memilih ::, yang melayani IPv4 dan IPv6 lewat satu listener, dan mencetak http://[::1]:3000 sebagai alamat lokal alih-alih kata localhost. Set HOSTNAME untuk memakukannya. Log tenang dalam beberapa detik dan endpoint health menjawab:

O container escolhe o próprio endereço de bind antes de o Next.js imprimir qualquer coisa, então a primeira linha do log é sobre o socket e não sobre o app. Ele prefere ::, que serve IPv4 e IPv6 por um único listener, e imprime http://[::1]:3000 como endereço local em vez da palavra localhost. Defina HOSTNAME para fixar isso. O log se acalma em poucos segundos e o endpoint de health responde:

libredb-studio: bind address :: (dual-stack verified)
▲ Next.js 16.3.4
- Local:         http://[::1]:3000
- Network:       http://[::]:3000
✓ Ready in 0ms

$ curl -s localhost:3000/api/db/health
{"status":"healthy","timestamp":"...","service":"libredb-studio"}

Then open http://localhost:3000, sign in with the email and password you set, and skip ahead to the tour.

Después abre http://localhost:3000, entra con el correo y la contraseña que configuraste y salta al recorrido.

あとは http://localhost:3000 を開き、設定したメールアドレスとパスワードでサインインして、ツアーへ進んでください。

Затем откройте http://localhost:3000, войдите с почтой и паролем, которые вы задали, и переходите к туру.

پھر http://localhost:3000 کھولیں، اپنی مقرر کردہ ای میل اور پاس ورڈ سے سائن اِن کریں، اور سیدھا ٹور پر چلے جائیں۔

然后打开 http://localhost:3000，用你设置的邮箱和密码登录，直接跳到导览部分。

然後打開 http://localhost:3000，用你設定的電子郵件和密碼登入，直接跳到導覽部分。

Potem otwórz http://localhost:3000, zaloguj się e-mailem i hasłem, które ustawiłeś, i przeskocz od razu do przeglądu ekranów.

Ouvrez ensuite http://localhost:3000, connectez-vous avec l'e-mail et le mot de passe que vous avez définis, et passez directement à la visite.

Poi apri http://localhost:3000, accedi con l'email e la password che hai impostato, e passa direttamente al tour.

Dann öffne http://localhost:3000, melde dich mit der E-Mail-Adresse und dem Passwort an, die du gesetzt hast, und spring vor zur Führung.

Lalu buka http://localhost:3000, masuk dengan email dan password yang Anda set, dan lompat ke bagian tur.

Então abra http://localhost:3000, entre com o e-mail e a senha que você definiu e pule direto para o tour.

Two more things worth setting

Dos cosas más que merece la pena configurar

ほかに設定しておく価値のある二つ

Ещё две вещи, которые стоит задать

دو اور چیزیں جو مقرر کرنے کے قابل ہیں

还有两项值得设置

還有兩項值得設定

Jeszcze dwie rzeczy warto ustawić

Deux réglages de plus qui valent la peine

Altre due cose che vale la pena impostare

Zwei weitere Dinge, die sich zu setzen lohnen

Dua hal lagi yang layak diset

Mais duas coisas que vale definir

JWT_SECRET has to be at least 32 characters. A shorter value is fatal on purpose: the server refuses to start rather than serve a deployment where every login fails. On the server-side stores, sqlite and postgres, it also derives the key that encrypts saved database passwords, so rotating it leaves those connections in place with the password field dropped. Set STORAGE_ENCRYPTION_KEY if you want to rotate one without disturbing the other.

JWT_SECRET tiene que tener al menos 32 caracteres. Un valor más corto es fatal a propósito: el servidor se niega a arrancar en lugar de servir un despliegue donde todos los inicios de sesión fallan. En los almacenes del servidor, sqlite y postgres, también deriva la clave que cifra las contraseñas de base de datos guardadas, así que rotarlo deja esas conexiones en su sitio con el campo de contraseña vacío. Pon STORAGE_ENCRYPTION_KEY si quieres rotar uno sin tocar el otro.

JWT_SECRET は最低 32 文字です。それより短い値は意図的に致命的で、ログインがすべて失敗する状態で動き続けるより、サーバーは起動を拒みます。サーバー側のストア、つまり sqlite と postgres では、保存したデータベースのパスワードを暗号化する鍵もここから導かれます。そのため入れ替えると、接続そのものは残り、パスワードの項目だけが落ちます。片方だけ入れ替えたいなら STORAGE_ENCRYPTION_KEY を設定してください。

JWT_SECRET должен быть не короче 32 символов. Более короткое значение намеренно фатально: сервер откажется стартовать, вместо того чтобы работать там, где любой вход провалится. На серверных хранилищах, sqlite и postgres, из него же выводится ключ, которым шифруются сохранённые пароли к базам, поэтому его замена оставляет подключения на месте, но поле пароля пропадает. Задайте STORAGE_ENCRYPTION_KEY, если хотите менять одно, не трогая другое.

JWT_SECRET کم از کم 32 حروف کا ہونا چاہیے۔ اس سے چھوٹی قدر جان بوجھ کر مہلک ہے: سرور ایسا نظام چلانے کے بجائے کہ جہاں ہر لاگ اِن ناکام ہو، چلنے سے ہی انکار کر دیتا ہے۔ سرور والے اسٹورز، یعنی sqlite اور postgres پر، محفوظ کیے گئے ڈیٹابیس پاس ورڈز کو خفیہ کرنے والی کلید بھی اسی سے نکلتی ہے، چنانچہ اسے بدلنے پر وہ کنکشن اپنی جگہ رہتے ہیں مگر پاس ورڈ کا خانہ گر جاتا ہے۔ ایک کو دوسرے کو چھیڑے بغیر بدلنا ہو تو STORAGE_ENCRYPTION_KEY مقرر کریں۔

JWT_SECRET 至少要 32 个字符。更短的值是故意致命的：与其让一个所有登录都失败的部署继续跑着，服务器宁可拒绝启动。在服务端存储上，也就是 sqlite 和 postgres，加密已保存数据库密码的密钥也是由它派生的，所以更换它会让那些连接留在原地，只是密码字段没了。想只换其中一个而不动另一个，就设置 STORAGE_ENCRYPTION_KEY。

JWT_SECRET 至少要 32 個字元。更短的值是故意致命的：與其讓一個所有登入都失敗的部署繼續跑著，伺服器寧可拒絕啟動。在伺服器端儲存上，也就是 sqlite 和 postgres，加密已儲存資料庫密碼的金鑰也是由它派生的，所以更換它會讓那些連線留在原地，只是密碼欄位沒了。想只換其中一個而不動另一個，就設定 STORAGE_ENCRYPTION_KEY。

JWT_SECRET musi mieć co najmniej 32 znaki. Krótsza wartość jest zabójcza celowo: serwer woli odmówić startu, niż serwować wdrożenie, w którym każde logowanie kończy się porażką. Przy magazynach po stronie serwera, sqlite i postgres, wyprowadza się z niego też klucz szyfrujący zapisane hasła do baz danych, więc jego rotacja zostawia te połączenia na miejscu, ale z wyczyszczonym polem hasła. Ustaw STORAGE_ENCRYPTION_KEY, jeśli chcesz rotować jedno bez ruszania drugiego.

JWT_SECRET doit faire au moins 32 caractères. Une valeur plus courte est fatale à dessein : le serveur refuse de démarrer plutôt que de servir un déploiement où chaque connexion échoue. Sur les stores côté serveur, sqlite et postgres, il dérive aussi la clé qui chiffre les mots de passe de base de données enregistrés, si bien qu'une rotation laisse ces connexions en place avec le champ mot de passe vidé. Définissez STORAGE_ENCRYPTION_KEY si vous voulez effectuer la rotation de l'une sans toucher à l'autre.

JWT_SECRET deve avere almeno 32 caratteri. Un valore più corto è fatale di proposito: il server si rifiuta di partire invece di servire un deployment in cui ogni login fallisce. Sugli store lato server, sqlite e postgres, da lì deriva anche la chiave che cifra le password dei database salvate, quindi ruotarlo lascia quelle connessioni al loro posto ma con il campo password svuotato. Imposta STORAGE_ENCRYPTION_KEY se vuoi ruotare l'uno senza toccare l'altro.

JWT_SECRET muss mindestens 32 Zeichen haben. Ein kürzerer Wert ist mit Absicht fatal: der Server startet lieber nicht, als eine Installation auszuliefern, in der jeder Login scheitert. Bei den serverseitigen Speichern, sqlite und postgres, leitet er außerdem den Schlüssel ab, der gespeicherte Datenbankpasswörter verschlüsselt. Rotierst du ihn, bleiben diese Verbindungen bestehen, nur das Passwortfeld fällt weg. Setz STORAGE_ENCRYPTION_KEY, wenn du das eine rotieren willst, ohne das andere anzufassen.

JWT_SECRET harus minimal 32 karakter. Nilai yang lebih pendek fatal dan itu disengaja: server menolak start ketimbang melayani deployment yang setiap login-nya gagal. Pada store sisi server, sqlite dan postgres, nilai ini juga menurunkan kunci yang mengenkripsi password database yang tersimpan, jadi merotasinya meninggalkan koneksi-koneksi itu di tempatnya dengan kolom password yang hilang. Set STORAGE_ENCRYPTION_KEY kalau Anda ingin merotasi yang satu tanpa mengganggu yang lain.

JWT_SECRET tem que ter pelo menos 32 caracteres. Um valor mais curto é fatal de propósito: o servidor se recusa a subir em vez de servir um deploy onde todo login falha. Nos stores do lado do servidor, sqlite e postgres, ele também deriva a chave que criptografa as senhas de banco salvas, então rotacioná-lo deixa essas conexões no lugar com o campo de senha perdido. Defina STORAGE_ENCRYPTION_KEY se quiser rotacionar um sem mexer no outro.

STORAGE_PROVIDER decides where saved connections live. The default, local, keeps them in the browser, which is fine for one person and useless for a team. sqlite puts them on the volume. postgres puts them in a database you name with STORAGE_POSTGRES_URL. Worth knowing before you decide: credential encryption is installed on the server-side stores only, so under the default local the saved passwords sit in the browser in plain text.

STORAGE_PROVIDER decide dónde viven las conexiones guardadas. El valor por defecto, local, las mantiene en el navegador, lo cual está bien para una persona y no sirve para un equipo. sqlite las pone en el volumen. postgres las pone en una base de datos que nombras con STORAGE_POSTGRES_URL. Conviene saberlo antes de decidir: el cifrado de credenciales solo se instala en los almacenes del servidor, así que con el valor por defecto local las contraseñas guardadas están en el navegador en texto claro.

STORAGE_PROVIDER は保存済みの接続がどこに置かれるかを決めます。既定値の local はブラウザー内に保持するので、一人で使うぶんには十分ですがチームでは使い物になりません。sqlite はボリュームに置きます。postgres は STORAGE_POSTGRES_URL で指定したデータベースに置きます。決める前に知っておく価値があります。認証情報の暗号化はサーバー側のストアにしか入らないので、既定の local では保存したパスワードがブラウザーに平文で残ります。

STORAGE_PROVIDER решает, где живут сохранённые подключения. Значение по умолчанию, local, держит их в браузере: нормально для одного человека, но бесполезно для команды. sqlite кладёт их на том. postgres кладёт их в базу, которую вы указываете в STORAGE_POSTGRES_URL. Стоит знать до выбора: шифрование учётных данных ставится только на серверные хранилища, поэтому при значении по умолчанию local сохранённые пароли лежат в браузере открытым текстом.

STORAGE_PROVIDER طے کرتا ہے کہ محفوظ کیے گئے کنکشن کہاں رہیں گے۔ طے شدہ قدر local انہیں براؤزر میں رکھتی ہے، جو ایک فرد کے لیے ٹھیک اور کسی ٹیم کے لیے بےکار ہے۔ sqlite انہیں والیوم پر رکھتا ہے۔ postgres انہیں اُس ڈیٹابیس میں رکھتا ہے جو آپ STORAGE_POSTGRES_URL میں بتاتے ہیں۔ فیصلہ کرنے سے پہلے جان لینا ضروری ہے: سندات کی خفیہ کاری صرف سرور کی طرف کے ذخیروں پر لگتی ہے، اس لیے طے شدہ local کے ساتھ محفوظ پاس ورڈ براؤزر میں سادہ متن میں پڑے رہتے ہیں۔

STORAGE_PROVIDER 决定已保存的连接存放在哪里。默认值 local 把它们放在浏览器里，一个人用没问题，团队用就毫无意义。sqlite 把它们放到卷上。postgres 把它们放进你用 STORAGE_POSTGRES_URL 指定的数据库。做决定前值得知道：凭据加密只装在服务端的存储上，所以在默认的 local 下，保存的密码是以明文留在浏览器里的。

STORAGE_PROVIDER 決定已儲存的連線存放在哪裡。預設值 local 把它們放在瀏覽器裡，一個人用沒問題，團隊用就毫無意義。sqlite 把它們放到磁碟區上。postgres 把它們放進你用 STORAGE_POSTGRES_URL 指定的資料庫。做決定前值得知道：認證資訊加密只裝在伺服器端的儲存上，所以在預設的 local 下，儲存的密碼是以明文留在瀏覽器裡的。

STORAGE_PROVIDER decyduje, gdzie mieszkają zapisane połączenia. Domyślne local trzyma je w przeglądarce, co wystarczy jednej osobie i jest bezużyteczne dla zespołu. sqlite odkłada je na wolumen. postgres wkłada je do bazy danych, którą wskażesz w STORAGE_POSTGRES_URL. Zanim zdecydujesz: szyfrowanie danych logowania jest wbudowane tylko w magazyny po stronie serwera, więc przy domyślnym local zapisane hasła leżą w przeglądarce czystym tekstem.

STORAGE_PROVIDER décide où vivent les connexions enregistrées. La valeur par défaut, local, les garde dans le navigateur, ce qui convient à une personne et ne sert à rien pour une équipe. sqlite les met sur le volume. postgres les met dans une base que vous désignez avec STORAGE_POSTGRES_URL. À savoir avant de décider : le chiffrement des identifiants n'est installé que sur les stores côté serveur, donc sous le local par défaut les mots de passe enregistrés restent en clair dans le navigateur.

STORAGE_PROVIDER decide dove vivono le connessioni salvate. Il valore predefinito, local, le tiene nel browser, il che va bene per una persona ed è inutile per una squadra. sqlite le mette sul volume. postgres le mette in un database che indichi con STORAGE_POSTGRES_URL. Da sapere prima di decidere: la cifratura delle credenziali è installata solo sugli store lato server, quindi con il local predefinito le password salvate stanno nel browser in chiaro.

STORAGE_PROVIDER entscheidet, wo gespeicherte Verbindungen liegen. Die Voreinstellung local hält sie im Browser, was für eine Person reicht und für ein Team nichts taugt. sqlite legt sie auf das Volume. postgres legt sie in eine Datenbank, die du mit STORAGE_POSTGRES_URL angibst. Bevor du dich entscheidest, solltest du wissen: die Verschlüsselung der Zugangsdaten gibt es nur bei den serverseitigen Speichern, unter der Voreinstellung local liegen die gespeicherten Passwörter also im Klartext im Browser.

STORAGE_PROVIDER menentukan di mana koneksi yang tersimpan tinggal. Default-nya, local, menyimpannya di browser, yang cukup untuk satu orang dan tidak berguna untuk sebuah tim. sqlite meletakkannya di volume. postgres meletakkannya di database yang Anda tunjuk lewat STORAGE_POSTGRES_URL. Perlu diketahui sebelum Anda memutuskan: enkripsi kredensial hanya terpasang pada store sisi server, jadi di bawah default local password yang tersimpan berada di browser dalam bentuk teks biasa.

STORAGE_PROVIDER decide onde ficam as conexões salvas. O padrão, local, guarda no navegador, o que serve para uma pessoa e é inútil para um time. sqlite põe no volume. postgres põe num banco que você indica com STORAGE_POSTGRES_URL. Vale saber antes de decidir: a criptografia de credenciais existe só nos stores do lado do servidor, então no padrão local as senhas salvas ficam no navegador em texto puro.

Worth knowing before you need it: a local account can require a six-digit code as well as its password. Set ADMIN_TOTP_SECRET to a base32 secret and the password alone stops being enough, which the login answers as mfaRequired until the code arrives. USER_TOTP_SECRET does the same for the second account. Both are optional and nothing changes if you leave them out.

Conviene saberlo antes de necesitarlo: una cuenta local puede exigir un código de seis dígitos además de su contraseña. Pon ADMIN_TOTP_SECRET a un secreto base32 y la contraseña por sí sola deja de bastar, algo que el inicio de sesión responde como mfaRequired hasta que llega el código. USER_TOTP_SECRET hace lo mismo para la segunda cuenta. Ambas son opcionales y no cambia nada si las omites.

必要になる前に知っておく価値があります。ローカルアカウントは、パスワードに加えて六桁のコードを要求できます。ADMIN_TOTP_SECRET に base32 の秘密鍵を設定すると、パスワードだけでは足りなくなり、コードが届くまでログインは mfaRequired と答えます。二つめのアカウントには USER_TOTP_SECRET が同じ働きをします。どちらも任意で、設定しなければ何も変わりません。

Об этом стоит знать заранее: локальная учётная запись может требовать шестизначный код в дополнение к паролю. Задайте ADMIN_TOTP_SECRET как секрет в base32, и одного пароля станет мало: вход будет отвечать mfaRequired, пока не придёт код. USER_TOTP_SECRET делает то же самое для второй учётной записи. Обе переменные необязательны, и без них ничего не меняется.

ضرورت پڑنے سے پہلے جان لینے کے قابل: مقامی اکاؤنٹ اپنے پاس ورڈ کے ساتھ چھ ہندسوں کا کوڈ بھی مانگ سکتا ہے۔ ADMIN_TOTP_SECRET کو base32 راز پر مقرر کریں تو اکیلا پاس ورڈ کافی نہیں رہتا، اور کوڈ آنے تک لاگ اِن mfaRequired جواب دیتا ہے۔ دوسرے اکاؤنٹ کے لیے USER_TOTP_SECRET یہی کام کرتا ہے۔ دونوں اختیاری ہیں اور نہ رکھیں تو کچھ نہیں بدلتا۔

值得在用到之前就知道：本地账号除了密码之外还能要求一个六位数验证码。把 ADMIN_TOTP_SECRET 设成一个 base32 密钥，光有密码就不够了，在验证码送到之前登录会回 mfaRequired。第二个账号用 USER_TOTP_SECRET，作用一样。两者都是可选的，不设也不会有任何变化。

值得在用到之前就知道：本機帳號除了密碼之外還能要求一個六位數驗證碼。把 ADMIN_TOTP_SECRET 設成一個 base32 金鑰，光有密碼就不夠了，在驗證碼送到之前登入會回 mfaRequired。第二個帳號用 USER_TOTP_SECRET，作用一樣。兩者都是可選的，不設也不會有任何變化。

Warto to wiedzieć, zanim tego potrzebujesz: lokalne konto może wymagać sześciocyfrowego kodu obok hasła. Ustaw ADMIN_TOTP_SECRET na sekret w base32, a samo hasło przestaje wystarczać: logowanie odpowiada wtedy mfaRequired, dopóki kod nie dotrze. USER_TOTP_SECRET robi to samo dla drugiego konta. Oba są opcjonalne i nic się nie zmienia, jeśli je pominiesz.

Bon à savoir avant d'en avoir besoin : un compte local peut exiger un code à six chiffres en plus de son mot de passe. Donnez à ADMIN_TOTP_SECRET un secret base32 et le mot de passe seul cesse de suffire, ce que la connexion signale par mfaRequired jusqu'à l'arrivée du code. USER_TOTP_SECRET fait la même chose pour le second compte. Les deux sont facultatifs et rien ne change si vous les omettez.

Da sapere prima che ti serva: un account locale può chiedere un codice a sei cifre oltre alla sua password. Imposta ADMIN_TOTP_SECRET con un segreto base32 e la sola password smette di bastare, cosa che il login segnala come mfaRequired finché il codice non arriva. USER_TOTP_SECRET fa lo stesso per il secondo account. Sono entrambi facoltativi e se li ometti non cambia niente.

Gut zu wissen, bevor du es brauchst: ein lokales Konto kann neben dem Passwort einen sechsstelligen Code verlangen. Setz ADMIN_TOTP_SECRET auf ein Base32-Secret, und das Passwort allein reicht nicht mehr: der Login antwortet mit mfaRequired, bis der Code kommt. USER_TOTP_SECRET macht dasselbe für das zweite Konto. Beide sind optional, und wenn du sie weglässt, ändert sich nichts.

Layak diketahui sebelum Anda membutuhkannya: akun lokal bisa meminta kode enam digit di samping password-nya. Set ADMIN_TOTP_SECRET ke sebuah secret base32 dan password saja berhenti menjadi cukup, yang dijawab login sebagai mfaRequired sampai kodenya datang. USER_TOTP_SECRET melakukan hal yang sama untuk akun kedua. Keduanya opsional dan tidak ada yang berubah kalau Anda membiarkannya kosong.

Vale saber antes de precisar: uma conta local pode exigir um código de seis dígitos além da senha. Defina ADMIN_TOTP_SECRET com um segredo base32 e a senha sozinha deixa de bastar, o que o login responde como mfaRequired até o código chegar. USER_TOTP_SECRET faz o mesmo para a segunda conta. Os dois são opcionais e nada muda se você deixar de fora.

Two groups of variables the other panels never need are worth naming here, because every deployment on this page ends in a login page on an address somebody else can reach. The first is the rate limiter, five buckets, each a count and a window in seconds: failed logins per client address (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC) default five per three hundred seconds; failed logins per submitted account, twenty per three hundred; AI and agent requests per signed-in user, twenty per sixty; database-reaching requests per user, a hundred and twenty per sixty; and audit lines for refusals, five per three hundred. Setting a count to zero disables that bucket. The second group decides what the limiter counts against: TRUST_PROXY_HEADERS defaults to true and reads the client address from X-Forwarded-For, and TRUSTED_PROXY_HOPS defaults to zero, which takes the leftmost entry, the one the caller writes. Behind a proxy, set it to the number of proxies in front, or a caller picks their own bucket and the audit log's address field is fiction.

Merece la pena nombrar aquí dos grupos de variables que los demás paneles no necesitan, porque todos los despliegues de esta página acaban en una página de inicio de sesión en una dirección a la que llega alguien más. El primero es el limitador de peticiones, cinco cubos, cada uno con un recuento y una ventana en segundos: inicios de sesión fallidos por dirección de cliente (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC), por defecto cinco cada trescientos segundos; inicios fallidos por cuenta enviada, veinte cada trescientos; peticiones de IA y del agente por usuario identificado, veinte cada sesenta; peticiones que llegan a la base de datos por usuario, ciento veinte cada sesenta; y líneas de auditoría por denegación, cinco cada trescientos. Poner un recuento a cero desactiva ese cubo. El segundo grupo decide contra qué cuenta el limitador: TRUST_PROXY_HEADERS vale true por defecto y lee la dirección del cliente de X-Forwarded-For, y TRUSTED_PROXY_HOPS vale cero, que toma la entrada más a la izquierda, la que escribe quien llama. Detrás de un proxy, ponlo al número de proxies que hay delante, o quien llame elegirá su propio cubo y el campo de dirección del registro de auditoría será ficción.

他のパネルでは要らない変数の群れが二つあり、ここで名前を挙げておく価値があります。このページのどの配置も、他人が到達できるアドレスのログイン画面で終わるからです。一つ目はレート制限で、五つのバケツがあり、それぞれ回数と秒数の窓を持ちます。クライアントアドレスごとのログイン失敗（RATE_LIMIT_LOGIN_MAX、RATE_LIMIT_LOGIN_WINDOW_SEC）は既定で三百秒に五回、送信されたアカウントごとのログイン失敗は三百秒に二十回、サインイン済み利用者ごとの AI とエージェントの要求は六十秒に二十回、データベースに届く要求は六十秒に百二十回、そして拒否の監査行は三百秒に五回。回数をゼロにすると、そのバケツは無効になります。二つ目の群れは、制限が何を数えるかを決めます。TRUST_PROXY_HEADERS は既定が true で、クライアントアドレスを X-Forwarded-For から読みます。TRUSTED_PROXY_HOPS の既定は 0 で、いちばん左の項目、つまり呼び出した側が書いた値を採ります。プロキシの後ろに置くなら、前段のプロキシの数を入れてください。さもないと呼び出す側が自分のバケツを選べますし、監査ログのアドレス欄は作り話になります。

Здесь стоит назвать две группы переменных, которые другим панелям не нужны, потому что любое развёртывание с этой страницы заканчивается страницей входа по адресу, куда доберётся кто-то ещё. Первая представляет собой ограничитель частоты, пять корзин, у каждой счёт и окно в секундах: неудачные входы с адреса клиента (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC) по умолчанию пять на триста секунд; неудачные входы на присланную учётную запись по умолчанию двадцать на триста; запросы ИИ и агента на вошедшего пользователя по умолчанию двадцать на шестьдесят; запросы, доходящие до базы, по умолчанию сто двадцать на шестьдесят; и строки аудита об отказах по умолчанию пять на триста. Ноль в счёте отключает корзину. Вторая группа решает, по чему ограничитель считает: TRUST_PROXY_HEADERS по умолчанию true и берёт адрес клиента из X-Forwarded-For, а TRUSTED_PROXY_HOPS по умолчанию ноль, то есть берётся самая левая запись, а именно та, которую пишет сам вызывающий. За прокси поставьте число прокси впереди, иначе вызывающий сам выберет себе корзину, а поле адреса в журнале аудита станет выдумкой.

دو ایسے گروہ یہاں نام لینے کے لائق ہیں جن کی باقی پینلوں کو ضرورت نہیں، کیونکہ اس صفحے کی ہر تنصیب ایک ایسے پتے پر لاگ اِن صفحے پر ختم ہوتی ہے جہاں کوئی اور بھی پہنچ سکتا ہے۔ پہلا شرحِ حد ہے، پانچ ڈبے، ہر ایک میں ایک گنتی اور سیکنڈوں کی ایک کھڑکی: کلائنٹ کے پتے کے حساب سے ناکام لاگ اِن (RATE_LIMIT_LOGIN_MAX، RATE_LIMIT_LOGIN_WINDOW_SEC) طے شدہ طور پر تین سو سیکنڈ میں پانچ؛ بھیجے گئے اکاؤنٹ کے حساب سے ناکام لاگ اِن، تین سو میں بیس؛ داخل شدہ صارف کے حساب سے اے آئی اور ایجنٹ کی درخواستیں، ساٹھ میں بیس؛ ڈیٹابیس تک پہنچنے والی درخواستیں، ساٹھ میں ایک سو بیس؛ اور انکار کی آڈٹ سطریں، تین سو میں پانچ۔ گنتی صفر کرنے سے وہ ڈبہ بند ہو جاتا ہے۔ دوسرا گروہ طے کرتا ہے کہ حد کس چیز پر گنی جائے: TRUST_PROXY_HEADERS طے شدہ طور پر true ہے اور کلائنٹ کا پتہ X-Forwarded-For سے پڑھتا ہے، اور TRUSTED_PROXY_HOPS طے شدہ طور پر صفر ہے، یعنی سب سے بائیں اندراج لیا جاتا ہے، یعنی وہی جو بلانے والا خود لکھتا ہے۔ کسی پراکسی کے پیچھے ہوں تو اسے آگے موجود پراکسیوں کی تعداد پر رکھیں، ورنہ بلانے والا اپنا ڈبہ خود چن لے گا اور آڈٹ لاگ کا پتہ والا خانہ افسانہ بن جائے گا۔

有两组变量是别的面板用不上的，但值得在这里点名，因为这一页上的每一种部署最后都落在一个别人也能访问的地址上的登录页。第一组是限流，五个桶，每个都有一个次数和一个以秒计的窗口：按客户端地址算的失败登录（RATE_LIMIT_LOGIN_MAX、RATE_LIMIT_LOGIN_WINDOW_SEC）默认三百秒五次；按提交的账号算的失败登录，三百秒二十次；按已登录用户算的 AI 和智能体请求，六十秒二十次；能到达数据库的请求，六十秒一百二十次；以及拒绝的审计行，三百秒五次。把次数设成零就关掉那个桶。第二组决定限流按什么来计数：TRUST_PROXY_HEADERS 默认为 true，从 X-Forwarded-For 里读客户端地址；TRUSTED_PROXY_HOPS 默认是零，取最左边那一项，也就是调用方自己写的那个。放在代理后面时，请把它设成前面代理的数量，否则调用方可以自己挑桶，审计日志里的地址字段也就成了虚构。

有兩組變數是別的面板用不上的，但值得在這裡點名，因為這一頁上的每一種部署最後都落在一個別人也能存取的位址上的登入頁。第一組是速率限制，五個桶，每個都有一個次數和一個以秒計的時間窗：按用戶端位址算的失敗登入（RATE_LIMIT_LOGIN_MAX、RATE_LIMIT_LOGIN_WINDOW_SEC）預設三百秒五次；按提交的帳號算的失敗登入，三百秒二十次；按已登入使用者算的 AI 和智慧代理請求，六十秒二十次；能到達資料庫的請求，六十秒一百二十次；以及拒絕的稽核紀錄，三百秒五次。把次數設成零就關掉那個桶。第二組決定速率限制按什麼來計數：TRUST_PROXY_HEADERS 預設為 true，從 X-Forwarded-For 裡讀用戶端位址；TRUSTED_PROXY_HOPS 預設是零，取最左邊那一項，也就是呼叫方自己寫的那個。放在代理後面時，請把它設成前面代理的數量，否則呼叫方可以自己挑桶，稽核日誌裡的位址欄位也就成了虛構。

Dwie grupy zmiennych, których pozostałe panele nigdy nie potrzebują, wymieniam właśnie tutaj, bo każde wdrożenie z tej strony kończy się ekranem logowania pod adresem, do którego dosięgnie ktoś jeszcze. Pierwsza to rate limiter, pięć kubełków, każdy to liczba i okno w sekundach: nieudane logowania na adres klienta (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC) domyślnie pięć na trzysta sekund; nieudane logowania na podane konto, dwadzieścia na trzysta; żądania do AI i agenta na zalogowanego użytkownika, dwadzieścia na sześćdziesiąt; żądania sięgające do bazy danych na użytkownika, sto dwadzieścia na sześćdziesiąt; i linie audytu dla odmów, pięć na trzysta. Ustawienie liczby na zero wyłącza dany kubełek. Druga grupa decyduje, komu rate limiter to wszystko liczy: TRUST_PROXY_HEADERS ma domyślnie true i czyta adres klienta z X-Forwarded-For, a TRUSTED_PROXY_HOPS ma domyślnie zero, co bierze skrajnie lewy wpis, czyli ten, który pisze sam wołający. Za proxy ustaw tam liczbę proxy stojących z przodu, bo inaczej wołający sam wybiera sobie kubełek, a pole adresu w dzienniku audytu jest fikcją.

Deux groupes de variables dont les autres panneaux n'ont jamais besoin méritent d'être nommés ici, parce que chaque déploiement de cette page finit sur une page de connexion à une adresse que quelqu'un d'autre peut atteindre. Le premier est le limiteur de débit, cinq compartiments, chacun un nombre et une fenêtre en secondes : connexions échouées par adresse cliente (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC), par défaut cinq pour trois cents secondes ; connexions échouées par compte soumis, vingt pour trois cents ; requêtes IA et agent par utilisateur connecté, vingt pour soixante ; requêtes atteignant une base par utilisateur, cent vingt pour soixante ; et lignes d'audit pour les refus, cinq pour trois cents. Mettre un nombre à zéro désactive ce compartiment. Le second groupe décide de ce sur quoi le limiteur compte : TRUST_PROXY_HEADERS vaut true par défaut et lit l'adresse cliente dans X-Forwarded-For, et TRUSTED_PROXY_HOPS vaut zéro par défaut, ce qui prend l'entrée la plus à gauche, celle que l'appelant écrit lui-même. Derrière un proxy, mettez-y le nombre de proxys placés devant, sinon un appelant choisit le compartiment où il tombe et le champ adresse du journal d'audit est une fiction.

Due gruppi di variabili di cui gli altri pannelli non hanno mai bisogno meritano di essere nominati qui, perché ogni deployment di questa pagina finisce su una pagina di login a un indirizzo che qualcun altro può raggiungere. Il primo è il rate limiter, cinque bucket, ciascuno con un conteggio e una finestra in secondi: login falliti per indirizzo del client (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC), di default cinque ogni trecento secondi; login falliti per account inviato, venti ogni trecento; richieste AI e all'agente per utente autenticato, venti ogni sessanta; richieste che arrivano al database per utente, centoventi ogni sessanta; e righe di audit per i rifiuti, cinque ogni trecento. Mettere un conteggio a zero disattiva quel bucket. Il secondo gruppo decide su cosa il limiter fa i conti: TRUST_PROXY_HEADERS vale true di default e legge l'indirizzo del client da X-Forwarded-For, e TRUSTED_PROXY_HOPS vale zero di default, il che prende la voce più a sinistra, quella che scrive il chiamante. Dietro un proxy, mettilo al numero di proxy che stanno davanti, altrimenti un chiamante si sceglie il bucket da sé e il campo indirizzo del log di audit è una finzione.

Zwei Gruppen von Variablen, die die anderen Panels nie brauchen, gehören hier genannt, denn jede Installation auf dieser Seite endet in einer Login-Seite unter einer Adresse, die auch jemand anderes erreicht. Die erste ist der Rate Limiter, fünf Buckets, jeder mit einer Anzahl und einem Fenster in Sekunden: fehlgeschlagene Logins pro Client-Adresse (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC) standardmäßig fünf pro dreihundert Sekunden; fehlgeschlagene Logins pro angegebenem Konto, zwanzig pro dreihundert; KI- und Agent-Anfragen pro angemeldetem Benutzer, zwanzig pro sechzig; Anfragen, die eine Datenbank erreichen, pro Benutzer, hundertzwanzig pro sechzig; und Audit-Zeilen für Ablehnungen, fünf pro dreihundert. Setzt du eine Anzahl auf null, ist dieser Bucket abgeschaltet. Die zweite Gruppe entscheidet, worauf der Limiter zählt: TRUST_PROXY_HEADERS steht standardmäßig auf true und liest die Client-Adresse aus X-Forwarded-For, und TRUSTED_PROXY_HOPS steht standardmäßig auf null, was den Eintrag ganz links nimmt, den, den der Aufrufer selbst schreibt. Hinter einem Proxy setz ihn auf die Zahl der Proxys davor, sonst sucht sich ein Aufrufer seinen eigenen Bucket aus und das Adressfeld im Audit-Log ist Fiktion.

Dua kelompok variabel yang tidak pernah dibutuhkan panel lain layak disebut di sini, karena setiap deployment di halaman ini berakhir pada halaman login di alamat yang bisa dijangkau orang lain. Yang pertama adalah rate limiter, lima bucket, masing-masing satu jumlah dan satu jendela dalam detik: login gagal per alamat klien (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC) default lima per tiga ratus detik; login gagal per akun yang dikirim, dua puluh per tiga ratus; permintaan AI dan agent per pengguna yang sudah masuk, dua puluh per enam puluh; permintaan yang menyentuh database per pengguna, seratus dua puluh per enam puluh; dan baris audit untuk penolakan, lima per tiga ratus. Mengisi sebuah jumlah dengan nol mematikan bucket itu. Kelompok kedua menentukan terhadap apa limiter menghitung: TRUST_PROXY_HEADERS default-nya true dan membaca alamat klien dari X-Forwarded-For, dan TRUSTED_PROXY_HOPS default-nya nol, yang mengambil entri paling kiri, entri yang ditulis si pemanggil. Di belakang proxy, set ke jumlah proxy yang ada di depan, atau si pemanggil memilih bucket-nya sendiri dan kolom alamat di log audit jadi fiksi.

Dois grupos de variáveis de que os outros painéis nunca precisam valem ser nomeados aqui, porque todo deploy desta página termina numa tela de login num endereço que outra pessoa alcança. O primeiro é o rate limiter, cinco baldes, cada um com uma contagem e uma janela em segundos: logins falhos por endereço de cliente (RATE_LIMIT_LOGIN_MAX, RATE_LIMIT_LOGIN_WINDOW_SEC), padrão cinco a cada trezentos segundos; logins falhos por conta enviada, vinte a cada trezentos; requisições de IA e do agente por usuário logado, vinte a cada sessenta; requisições que chegam ao banco por usuário, cento e vinte a cada sessenta; e linhas de auditoria para recusas, cinco a cada trezentos. Pôr uma contagem em zero desliga aquele balde. O segundo grupo decide contra o que o limitador conta: TRUST_PROXY_HEADERS vem como true e lê o endereço do cliente de X-Forwarded-For, e TRUSTED_PROXY_HOPS vem como zero, o que pega a entrada mais à esquerda, a que o chamador escreve. Atrás de um proxy, ajuste para o número de proxies na frente, ou um chamador escolhe o próprio balde e o campo de endereço do log de auditoria é ficção.

A template in Railway's own marketplace. Nothing to fill in, and nothing you own.

Una plantilla en el propio marketplace de Railway. Nada que rellenar y nada tuyo que mantener.

Railway 自身のマーケットプレイスにあるテンプレート。入力するものはなく、自分で持つものもありません。

Шаблон в собственном маркетплейсе Railway. Заполнять нечего, и ничего своего у вас тут нет.

Railway کے اپنے مارکیٹ پلیس میں ایک ٹیمپلیٹ۔ نہ کچھ بھرنا ہے، نہ کچھ اپنا رکھنا۔

Railway 自家市场里的一个模板。没有要填的东西，也不需要你自己有什么。

Railway 自家市場裡的一個範本。沒有要填的東西，也不需要你自己有什麼。

Szablon w marketplace samego Railway. Nic do wypełnienia i nic, co byłoby twoje.

Un template dans la marketplace de Railway. Rien à remplir, et rien qui vous appartienne.

Un template nel marketplace di Railway. Niente da compilare, e niente che sia tuo.

Ein Template in Railways eigenem Marktplatz. Nichts auszufüllen, und nichts, was dir gehört.

Sebuah template di marketplace milik Railway sendiri. Tidak ada yang perlu diisi, dan tidak ada yang jadi milik Anda.

Um template no marketplace da própria Railway. Nada para preencher, e nada que seja seu.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

The template Railway serves is edited in Railway's own dashboard rather than taken from the repository, and it currently deploys 0.9.66, much older than the 0.17.0 these pages describe. That build has no database agent at all: its panel strip carries NL2SQL and Autopilot, and the /api/agent routes the agent rail needs do not exist in it. The tag still resolves, so nothing fails loudly. You get an older product than the one you are reading about.

La plantilla que sirve Railway se edita en el propio panel de Railway en lugar de tomarse del repositorio, y actualmente despliega 0.9.66, mucho más antigua que la 0.17.0 que describen estas páginas. Esa compilación no tiene agente de base de datos en absoluto: su tira de paneles lleva NL2SQL y Autopilot, y las rutas /api/agent que necesita el carril del agente no existen en ella. La etiqueta sigue resolviéndose, así que nada falla de forma ruidosa. Obtienes un producto más antiguo que el que estás leyendo.

Railway が配っているテンプレートはリポジトリから取られるのではなく Railway 自身のダッシュボードで編集されており、現在は 0.9.66 を配置します。これらのページが説明している 0.17.0 よりずっと古いものです。そのビルドにはデータベースエージェントがまったくありません。パネルの並びには NL2SQL と Autopilot があり、エージェントの領域が必要とする /api/agent のルートはそこに存在しません。タグは解決できるので、派手に失敗することもありません。読んでいるものより古い製品が手に入ります。

Шаблон, который отдаёт Railway, правится в самой панели Railway, а не берётся из репозитория, и сейчас он разворачивает 0.9.66, намного старше 0.17.0, о которой эти страницы. В той сборке агента базы данных нет вовсе: в её панели есть NL2SQL и Autopilot, а маршрутов /api/agent, нужных панели агента, в ней просто нет. Тег по-прежнему разрешается, так что ничего громко не падает. Вы получаете продукт старше того, о котором читаете.

Railway جو ٹیمپلیٹ دیتا ہے وہ ریپازٹری سے نہیں لیا جاتا بلکہ Railway کے اپنے ڈیش بورڈ میں ترتیب دیا جاتا ہے، اور اِس وقت یہ 0.9.66 تعینات کرتا ہے، اُس 0.17.0 سے بہت پرانی جو یہ صفحات بیان کرتے ہیں۔ اُس بلڈ میں ڈیٹابیس ایجنٹ سرے سے نہیں: اس کی پینل پٹی میں NL2SQL اور Autopilot ہیں، اور ایجنٹ کی پٹی کو جن /api/agent راستوں کی ضرورت ہے وہ اس میں موجود ہی نہیں۔ ٹیگ اب بھی حل ہو جاتا ہے، سو کچھ شور مچا کر ناکام نہیں ہوتا۔ آپ کو اُس سے پرانی مصنوع ملتی ہے جس کے بارے میں آپ پڑھ رہے ہیں۔

Railway 提供的模板不是从仓库取的，而是在 Railway 自己的面板里编辑的，目前部署的是 0.9.66，比这些页面讲的 0.17.0 旧得多。那个构建里根本没有数据库智能体：它的面板栏里是 NL2SQL 和 Autopilot，而智能体侧栏需要的 /api/agent 路由在它里面根本不存在。标签仍然能解析，所以不会明显报错。你拿到的是一个比你正在读的更旧的产品。

Railway 提供的範本不是從儲存庫取的，而是在 Railway 自己的面板裡編輯的，目前部署的是 0.9.66，比這些頁面講的 0.17.0 舊得多。那個建置裡根本沒有資料庫智慧代理：它的面板列裡是 NL2SQL 和 Autopilot，而智慧代理側欄需要的 /api/agent 路由在它裡面根本不存在。標籤仍然能解析，所以不會明顯出錯。你拿到的是一個比你正在讀的更舊的產品。

Szablon, który serwuje Railway, jest edytowany w panelu samego Railway, a nie brany z repozytorium, i wdraża obecnie 0.9.66, dużo starszą niż 0.17.0 opisywana na tych stronach. Ten build nie ma w ogóle agenta bazy danych: w pasku paneli ma NL2SQL i Autopilot, a tras /api/agent, których potrzebuje listwa agenta, po prostu w nim nie ma. Tag nadal się rozwiązuje, więc nic nie wysypuje się głośno. Dostajesz starszy produkt niż ten, o którym czytasz.

Le template que sert Railway est édité dans le tableau de bord de Railway plutôt que repris du dépôt, et il déploie actuellement la 0.9.66, bien plus ancienne que la 0.17.0 que ces pages décrivent. Ce build n'a aucun agent de base de données : sa barre de panneaux porte NL2SQL et Autopilot, et les routes /api/agent dont le rail de l'agent a besoin n'y existent pas. Le tag se résout quand même, donc rien n'échoue bruyamment. Vous obtenez un produit plus ancien que celui dont vous lisez la description.

Il template che Railway serve viene modificato nella dashboard di Railway invece di essere preso dal repository, e al momento distribuisce la 0.9.66, molto più vecchia della 0.17.0 che queste pagine descrivono. Quella build non ha proprio nessun agente di database: la sua striscia di pannelli porta NL2SQL e Autopilot, e le route /api/agent che servono alla barra dell'agente lì non esistono. Il tag si risolve lo stesso, quindi niente fallisce in modo rumoroso. Ti ritrovi un prodotto più vecchio di quello di cui stai leggendo.

Das Template, das Railway ausliefert, wird in Railways eigenem Dashboard gepflegt und nicht aus dem Repository genommen, und es deployt derzeit 0.9.66, viel älter als das 0.17.0, das diese Seiten beschreiben. Dieser Build hat überhaupt keinen Datenbank-Agenten: seine Panel-Leiste führt NL2SQL und Autopilot, und die /api/agent-Routen, die die Agent-Leiste braucht, gibt es darin nicht. Der Tag löst trotzdem auf, es scheitert also nichts hörbar. Du bekommst ein älteres Produkt als das, über das du hier liest.

Template yang disajikan Railway diedit di dashboard Railway sendiri, bukan diambil dari repository, dan saat ini ia men-deploy 0.9.66, jauh lebih tua daripada 0.17.0 yang dibahas halaman-halaman ini. Build itu sama sekali tidak punya agent database: strip panel-nya membawa NL2SQL dan Autopilot, dan route /api/agent yang dibutuhkan rail agent tidak ada di dalamnya. Tag-nya tetap bisa di-resolve, jadi tidak ada yang gagal dengan berisik. Anda mendapat produk yang lebih tua daripada yang sedang Anda baca.

O template que a Railway serve é editado no painel da própria Railway em vez de sair do repositório, e hoje ele faz deploy da 0.9.66, bem mais antiga que a 0.17.0 que estas páginas descrevem. Esse build não tem agente de banco de dados nenhum: a faixa de painéis dele traz NL2SQL e Autopilot, e as rotas /api/agent de que a barra do agente precisa não existem nele. A tag ainda resolve, então nada falha em voz alta. Você recebe um produto mais velho do que o que está lendo aqui.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

Open the template page, press Deploy, and Railway shows you the whole service definition before it creates anything: the image, the environment, the volume and the ports. Read that screen rather than skipping it, because it is where the version above is visible.

Abre la página de la plantilla, pulsa Deploy, y Railway te enseña toda la definición del servicio antes de crear nada: la imagen, el entorno, el volumen y los puertos. Lee esa pantalla en lugar de saltártela, porque es donde se ve la versión de la que hablo arriba.

テンプレートのページを開いて Deploy を押すと、Railway は何かを作る前にサービス定義を丸ごと見せてくれます。イメージ、環境変数、ボリューム、ポートです。この画面は飛ばさずに読んでください。上で述べたバージョンが見えるのはここです。

Откройте страницу шаблона, нажмите Deploy, и Railway покажет всё определение сервиса до того, как что-то создаст: образ, окружение, том и порты. Этот экран стоит прочитать, а не пролистать: именно там видна версия, о которой сказано выше.

ٹیمپلیٹ کا صفحہ کھولیں، Deploy دبائیں، اور Railway کچھ بھی بنانے سے پہلے پوری سروس کی تعریف دکھا دیتا ہے: امیج، ماحول، والیوم اور پورٹ۔ اس اسکرین کو چھوڑنے کے بجائے پڑھیں، کیونکہ اوپر بتایا گیا ورژن یہیں نظر آتا ہے۔

打开模板页面，按 Deploy，Railway 会在创建任何东西之前把整份服务定义摊给你看：镜像、环境变量、卷和端口。这一屏别跳过，上面说的那个版本就是在这里能看到的。

打開範本頁面，按 Deploy，Railway 會在建立任何東西之前把整份服務定義攤給你看：映像檔、環境變數、磁碟區和連接埠。這一畫面別跳過，上面說的那個版本就是在這裡能看到的。

Otwórz stronę szablonu, naciśnij Deploy, a Railway pokaże ci całą definicję usługi, zanim cokolwiek utworzy: obraz, środowisko, wolumen i porty. Przeczytaj ten ekran, zamiast go przeskakiwać, bo to na nim widać wersję, o której piszę wyżej.

Ouvrez la page du template, appuyez sur Deploy, et Railway vous montre toute la définition du service avant de rien créer : l'image, l'environnement, le volume et les ports. Lisez cet écran au lieu de le passer, parce que c'est là que la version ci-dessus est visible.

Apri la pagina del template, premi Deploy, e Railway ti mostra tutta la definizione del servizio prima di creare qualsiasi cosa: l'immagine, l'ambiente, il volume e le porte. Leggi quella schermata invece di saltarla, perché è lì che la versione qui sopra si vede.

Öffne die Template-Seite, drück auf Deploy, und Railway zeigt dir die ganze Service-Definition, bevor es irgendetwas anlegt: das Image, die Umgebung, das Volume und die Ports. Lies diesen Bildschirm, statt ihn zu überspringen, denn dort ist die Version von oben zu sehen.

Buka halaman template, tekan Deploy, dan Railway menunjukkan seluruh definisi service kepada Anda sebelum ia membuat apa pun: image, environment, volume dan port. Baca layar itu, jangan dilewati, karena di situlah versi yang disebut di atas terlihat.

Abra a página do template, aperte Deploy, e a Railway te mostra a definição inteira do serviço antes de criar qualquer coisa: a imagem, o ambiente, o volume e as portas. Leia essa tela em vez de pular, porque é nela que a versão acima fica visível.

What it handles for you

De qué se encarga por ti

向こうがやってくれること

Что он берёт на себя

یہ آپ کے لیے کیا سنبھالتا ہے

它替你处理了什么

它替你處理了什麼

Co robi za ciebie

Ce qu'il prend en charge pour vous

Di cosa si occupa al posto tuo

Was es dir abnimmt

Apa yang ia urus untuk Anda

O que ele resolve para você

The template generates its own JWT_SECRET rather than carrying one, and it mounts a volume at /app/data with STORAGE_PROVIDER set to sqlite, so saved connections are on the server and survive a redeploy. Railway serves the app over HTTPS on a generated hostname, so leave AUTH_COOKIE_SECURE alone here: the browser keeps a Secure cookie on HTTPS, and the advice in the LAN panels is the opposite case, not this one.

La plantilla genera su propio JWT_SECRET en vez de llevar uno, y monta un volumen en /app/data con STORAGE_PROVIDER puesto a sqlite, así que las conexiones guardadas están en el servidor y sobreviven a un redespliegue. Railway sirve la aplicación por HTTPS en un nombre generado, así que aquí no toques AUTH_COOKIE_SECURE: en HTTPS el navegador conserva una cookie Secure, y el consejo de los paneles de LAN es el caso contrario, no este.

このテンプレートは JWT_SECRET を自前で生成し、値を持ち回りません。また /app/data にボリュームをマウントし、STORAGE_PROVIDER を sqlite にするので、保存した接続はサーバー側にあり、再デプロイしても残ります。Railway は生成されたホスト名で HTTPS 配信するため、ここでは AUTH_COOKIE_SECURE に手を触れないでください。HTTPS ならブラウザーは Secure Cookie を保持します。LAN 向けパネルの助言は逆の状況の話で、ここには当てはまりません。

Шаблон генерирует собственный JWT_SECRET, а не носит его с собой, и монтирует том в /app/data с STORAGE_PROVIDER в значении sqlite, так что сохранённые подключения лежат на сервере и переживают передеплой. Railway отдаёт приложение по HTTPS на сгенерированном имени, поэтому AUTH_COOKIE_SECURE здесь трогать не нужно: по HTTPS браузер сохраняет Secure-куку, а совет из панелей про локальную сеть относится к обратному случаю, а не к этому.

یہ ٹیمپلیٹ اپنا JWT_SECRET خود بناتا ہے، ساتھ لے کر نہیں چلتا، اور /app/data پر ایک والیوم لگاتا ہے جس کے ساتھ STORAGE_PROVIDER کو sqlite کر دیتا ہے؛ سو محفوظ کیے گئے کنکشن سرور پر رہتے ہیں اور دوبارہ تعیناتی کے بعد بھی باقی رہتے ہیں۔ Railway ایپ کو ایک تیار شدہ ہوسٹ نام پر HTTPS سے دیتا ہے، سو یہاں AUTH_COOKIE_SECURE کو ہاتھ نہ لگائیں: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے، اور لین والے پینلوں کی نصیحت اُلٹی صورت کی ہے، اس کی نہیں۔

这个模板自己生成 JWT_SECRET，而不是带着一个走，并且在 /app/data 挂了卷、把 STORAGE_PROVIDER 设成 sqlite，所以保存的连接在服务端，重新部署也还在。Railway 用生成的主机名以 HTTPS 提供服务，所以这里别动 AUTH_COOKIE_SECURE：HTTPS 下浏览器会保留 Secure cookie，局域网那几个面板的建议说的是相反的情况，不是这里。

這個範本自己產生 JWT_SECRET，而不是帶著一個走，並且在 /app/data 掛了磁碟區、把 STORAGE_PROVIDER 設成 sqlite，所以儲存的連線在伺服器端，重新部署也還在。Railway 用產生的主機名以 HTTPS 提供服務，所以這裡別動 AUTH_COOKIE_SECURE：HTTPS 下瀏覽器會保留 Secure cookie，區域網路那幾個面板的建議說的是相反的情況，不是這裡。

Szablon generuje własny JWT_SECRET, zamiast nieść gotowy, i montuje wolumen w /app/data z STORAGE_PROVIDER ustawionym na sqlite, więc zapisane połączenia są na serwerze i przeżywają redeploy. Railway serwuje aplikację po HTTPS na wygenerowanej nazwie hosta, więc AUTH_COOKIE_SECURE zostaw tu w spokoju: przy HTTPS przeglądarka utrzyma ciasteczko Secure, a rada z paneli o sieci lokalnej dotyczy odwrotnego przypadku, nie tego.

Le template génère son propre JWT_SECRET au lieu d'en transporter un, et il monte un volume sur /app/data avec STORAGE_PROVIDER réglé sur sqlite, si bien que les connexions enregistrées sont sur le serveur et survivent à un redéploiement. Railway sert l'application en HTTPS sur un nom d'hôte généré, alors ne touchez pas à AUTH_COOKIE_SECURE ici : en HTTPS le navigateur conserve un cookie Secure, et le conseil des panneaux LAN vise le cas inverse, pas celui-ci.

Il template genera il proprio JWT_SECRET invece di portarsene dietro uno, e monta un volume su /app/data con STORAGE_PROVIDER impostato a sqlite, quindi le connessioni salvate stanno sul server e sopravvivono a un nuovo deploy. Railway serve l'app in HTTPS su un hostname generato, quindi qui lascia stare AUTH_COOKIE_SECURE: in HTTPS il browser tiene un cookie Secure, e il consiglio nei pannelli LAN riguarda il caso opposto, non questo.

Das Template erzeugt sein eigenes JWT_SECRET, statt eines mitzubringen, und es hängt ein Volume unter /app/data ein, mit STORAGE_PROVIDER auf sqlite, gespeicherte Verbindungen liegen also auf dem Server und überstehen ein Redeploy. Railway liefert die App über HTTPS unter einem generierten Hostnamen aus, lass AUTH_COOKIE_SECURE hier also in Ruhe: der Browser behält ein Secure-Cookie über HTTPS, und der Rat aus den LAN-Panels gilt dem umgekehrten Fall, nicht diesem.

Template ini membuat JWT_SECRET sendiri alih-alih membawanya, dan ia me-mount volume di /app/data dengan STORAGE_PROVIDER diset ke sqlite, jadi koneksi yang tersimpan ada di server dan selamat dari redeploy. Railway menyajikan aplikasi lewat HTTPS pada hostname yang dibuatkan, jadi biarkan AUTH_COOKIE_SECURE apa adanya di sini: browser menyimpan cookie Secure di HTTPS, dan saran di panel LAN adalah kasus sebaliknya, bukan kasus ini.

O template gera o próprio JWT_SECRET em vez de carregar um, e monta um volume em /app/data com STORAGE_PROVIDER em sqlite, então as conexões salvas ficam no servidor e sobrevivem a um redeploy. A Railway serve o app por HTTPS num hostname gerado, então deixe AUTH_COOKIE_SECURE quieto aqui: o navegador guarda um cookie Secure em HTTPS, e o conselho dos painéis de LAN é o caso oposto, não este.

A config file in the repository. You launch it from your own machine.

Un fichero de configuración en el repositorio. Lo lanzas desde tu propia máquina.

リポジトリにある設定ファイル。自分のマシンから起動します。

Файл конфигурации в репозитории. Запускаете со своей машины.

ریپازٹری میں ایک کنفیگ فائل۔ آپ اسے اپنی مشین سے چلاتے ہیں۔

仓库里的一个配置文件。你从自己的机器上启动它。

儲存庫裡的一個設定檔。你從自己的機器上啟動它。

Plik konfiguracyjny w repozytorium. Odpalasz go z własnej maszyny.

Un fichier de configuration dans le dépôt. C'est vous qui le lancez depuis votre propre machine.

Un file di configurazione nel repository. Lo lanci dalla tua macchina.

Eine Konfigurationsdatei im Repository. Du startest sie von deinem eigenen Rechner.

Sebuah file konfigurasi di repository. Anda meluncurkannya dari mesin Anda sendiri.

Um arquivo de configuração no repositório. Você sobe a partir da sua própria máquina.

What you need

Qué necesitas

必要なもの

Что нужно

آپ کو کیا درکار ہے

你需要什么

你需要什麼

Czego potrzebujesz

Ce qu'il vous faut

Cosa ti serve

Was du brauchst

Yang Anda perlukan

O que você precisa

The flyctl command line tool and a Fly account. Unlike a marketplace template, nothing is listed anywhere: the service definition is fly.toml in the repository, and you are the one who runs it. Check the image line before you launch, because the tag that file pins is not always the 0.17.0 these pages describe. Since the file is yours to edit, set the tag you want yourself.

La herramienta de línea de comandos flyctl y una cuenta de Fly. A diferencia de una plantilla de marketplace, aquí no hay nada publicado en ningún sitio: la definición del servicio es fly.toml en el repositorio, y quien lo ejecuta eres tú. Mira la línea de la imagen antes de lanzarlo, porque la etiqueta que ese archivo fija no siempre es la 0.17.0 que describen estas páginas. Como el archivo es tuyo, pon tú mismo la etiqueta que quieras.

flyctl コマンドラインツールと Fly のアカウント。マーケットプレイスのテンプレートと違い、どこかに掲載されているものはありません。サービス定義はリポジトリの fly.toml で、動かすのはあなたです。起動する前にイメージの行を見てください。このファイルが固定しているタグは、これらのページが説明している 0.17.0 とはかぎりません。ファイルは自分で編集するものなので、欲しいタグは自分で書いてください。

Утилита командной строки flyctl и учётная запись Fly. В отличие от шаблона в магазине, здесь нигде ничего не опубликовано: описанием сервиса служит fly.toml в репозитории, и запускаете его вы сами. Перед запуском посмотрите строку с образом: тег, который закрепляет этот файл, не всегда та самая 0.17.0, о которой эти страницы. Файл ваш, так что нужный тег поставьте сами.

flyctl کمانڈ لائن ٹول اور ایک Fly اکاؤنٹ۔ مارکیٹ پلیس ٹیمپلیٹ کے برعکس یہاں کہیں کچھ درج نہیں: سروس کی تعریف ریپازٹری میں fly.toml ہے، اور اسے چلانے والے آپ ہیں۔ چلانے سے پہلے امیج والی سطر دیکھ لیں، کیونکہ یہ فائل جو ٹیگ جماتی ہے وہ ہمیشہ وہی 0.17.0 نہیں ہوتا جو یہ صفحات بیان کرتے ہیں۔ چونکہ فائل آپ کی اپنی ہے، جو ٹیگ چاہیے وہ خود لکھ دیں۔

flyctl 命令行工具，加一个 Fly 账号。和市场模板不同，这里没有任何地方上架：服务定义就是仓库里的 fly.toml，跑它的人是你。启动前先看一眼镜像那一行，因为这个文件钉住的标签未必就是这些页面讲的 0.17.0。既然文件归你编辑，想要哪个标签就自己写。

flyctl 命令列工具，加一個 Fly 帳號。和市場範本不同，這裡沒有任何地方上架：服務定義就是儲存庫裡的 fly.toml，跑它的人是你。啟動前先看一眼映像檔那一行，因為這個檔案釘住的標籤未必就是這些頁面講的 0.17.0。既然檔案歸你編輯，想要哪個標籤就自己寫。

Narzędzia wiersza poleceń flyctl i konta na Fly. W przeciwieństwie do szablonu z marketplace nic nie jest nigdzie wystawione: definicją usługi jest fly.toml w repozytorium, a uruchamiasz je ty. Sprawdź linię z obrazem, zanim wystartujesz, bo tag, który ten plik przypina, nie zawsze jest tą 0.17.0, którą opisują te strony. Skoro plik jest twój do edycji, sam ustaw tag, który chcesz.

L'outil en ligne de commande flyctl et un compte Fly. Contrairement à un template de marketplace, rien n'est listé nulle part : la définition du service est le fly.toml du dépôt, et c'est vous qui l'exécutez. Vérifiez la ligne de l'image avant de lancer, parce que le tag que ce fichier fixe n'est pas toujours la 0.17.0 que ces pages décrivent. Comme le fichier est à vous, mettez vous-même le tag que vous voulez.

Lo strumento da riga di comando flyctl e un account Fly. A differenza di un template di marketplace, qui non c'è niente in elenco da nessuna parte: la definizione del servizio è fly.toml nel repository, e a farla girare sei tu. Controlla la riga dell'immagine prima di lanciare, perché il tag che quel file fissa non è sempre la 0.17.0 che queste pagine descrivono. Visto che il file è tuo da modificare, il tag che vuoi mettilo tu.

Das Kommandozeilenwerkzeug flyctl und ein Fly-Konto. Anders als bei einem Marktplatz-Template ist nirgends etwas gelistet: die Service-Definition ist die fly.toml im Repository, und du bist derjenige, der sie ausführt. Prüf die Image-Zeile, bevor du startest, denn der Tag, den diese Datei festnagelt, ist nicht immer das 0.17.0, das diese Seiten beschreiben. Da die Datei dir gehört, setz den Tag, den du willst, selbst.

Command line tool flyctl dan sebuah akun Fly. Tidak seperti template marketplace, tidak ada yang terdaftar di mana pun: definisi service-nya adalah fly.toml di repository, dan Andalah yang menjalankannya. Periksa baris image sebelum Anda launch, karena tag yang dipaku file itu tidak selalu 0.17.0 yang dibahas halaman-halaman ini. Karena file itu milik Anda untuk diedit, set sendiri tag yang Anda mau.

A ferramenta de linha de comando flyctl e uma conta na Fly. Diferente de um template de marketplace, não há nada listado em lugar nenhum: a definição do serviço é o fly.toml no repositório, e quem roda é você. Confira a linha da imagem antes de subir, porque a tag que esse arquivo fixa nem sempre é a 0.17.0 que estas páginas descrevem. Como o arquivo é seu para editar, defina você mesmo a tag que quer.

What it sets for you

Qué configura por ti

向こうが設定してくれること

Что он настраивает за вас

یہ آپ کے لیے کیا مقرر کرتا ہے

它替你设了什么

它替你設了什麼

Co ustawia za ciebie

Ce qu'il règle pour vous

Cosa imposta al posto tuo

Was sie für dich setzt

Apa yang ia set untuk Anda

O que ele define para você

The file mounts a volume at /app/data and sets STORAGE_PROVIDER to sqlite, so saved connections live on the server and survive a redeploy. It forces HTTPS on the generated hostname, which is why AUTH_COOKIE_SECURE is absent and should stay absent: the browser keeps a Secure cookie over HTTPS. The documented setup generates the secret with openssl rand -hex 32, which is 64 characters and therefore a real one rather than a placeholder that happens to clear the length check.

El fichero monta un volumen en /app/data y pone STORAGE_PROVIDER a sqlite, así que las conexiones guardadas viven en el servidor y sobreviven a un redespliegue. Fuerza HTTPS en el nombre generado, y por eso AUTH_COOKIE_SECURE no aparece y debe seguir sin aparecer: por HTTPS el navegador conserva una cookie Secure. La configuración documentada genera el secreto con openssl rand -hex 32, que son 64 caracteres y por tanto uno de verdad, no un marcador que da la casualidad de superar la comprobación de longitud.

このファイルは /app/data にボリュームをマウントし、STORAGE_PROVIDER を sqlite にします。保存した接続はサーバー側にあり、再デプロイしても残ります。生成されたホスト名で HTTPS を強制するので、AUTH_COOKIE_SECURE は書かれていませんし、書かないままにしてください。HTTPS ならブラウザーは Secure Cookie を保持します。手順書では秘密鍵を openssl rand -hex 32 で作ります。64 文字あり、長さ検査をたまたま通る仮の値ではなく本物です。

Файл монтирует том в /app/data и ставит STORAGE_PROVIDER в sqlite, так что сохранённые подключения лежат на сервере и переживают передеплой. Он принудительно включает HTTPS на сгенерированном имени, поэтому AUTH_COOKIE_SECURE отсутствует и пусть отсутствует: по HTTPS браузер сохраняет Secure-куку. В документированной последовательности секрет создаётся командой openssl rand -hex 32, что даёт 64 символа, то есть настоящий секрет, а не заглушка, случайно прошедшая проверку длины.

یہ فائل /app/data پر ایک والیوم لگاتی ہے اور STORAGE_PROVIDER کو sqlite کر دیتی ہے، سو محفوظ کیے گئے کنکشن سرور پر رہتے ہیں اور دوبارہ تعیناتی کے بعد بھی باقی رہتے ہیں۔ یہ تیار شدہ ہوسٹ نام پر HTTPS لازم کرتی ہے، اسی لیے AUTH_COOKIE_SECURE موجود نہیں اور نہ ہی ہونا چاہیے: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے۔ دستاویزی طریقہ راز openssl rand -hex 32 سے بناتا ہے، جو 64 حروف ہے، یعنی اصل راز، نہ کہ کوئی عارضی قدر جو اتفاقاً لمبائی کی جانچ پار کر جائے۔

这份文件在 /app/data 挂了卷，并把 STORAGE_PROVIDER 设成 sqlite，所以保存的连接在服务端，重新部署也还在。它在生成的主机名上强制 HTTPS，所以 AUTH_COOKIE_SECURE 没有出现，也应该一直不出现：HTTPS 下浏览器会保留 Secure cookie。文档里的做法用 openssl rand -hex 32 生成密钥，那是 64 个字符，是真密钥，不是碰巧通过长度检查的占位符。

這份檔案在 /app/data 掛了磁碟區，並把 STORAGE_PROVIDER 設成 sqlite，所以儲存的連線在伺服器端，重新部署也還在。它在產生的主機名上強制 HTTPS，所以 AUTH_COOKIE_SECURE 沒有出現，也應該一直不出現：HTTPS 下瀏覽器會保留 Secure cookie。文件裡的做法用 openssl rand -hex 32 產生金鑰，那是 64 個字元，是真金鑰，不是碰巧通過長度檢查的佔位符。

Plik montuje wolumen w /app/data i ustawia STORAGE_PROVIDER na sqlite, więc zapisane połączenia mieszkają na serwerze i przeżywają redeploy. Wymusza HTTPS na wygenerowanej nazwie hosta i dlatego AUTH_COOKIE_SECURE jest nieobecne i takie powinno zostać: przy HTTPS przeglądarka utrzyma ciasteczko Secure. Opisana procedura generuje sekret przez openssl rand -hex 32, czyli 64 znaki, a więc prawdziwy sekret, a nie zaślepkę, która przypadkiem przechodzi kontrolę długości.

Le fichier monte un volume sur /app/data et règle STORAGE_PROVIDER sur sqlite, si bien que les connexions enregistrées vivent sur le serveur et survivent à un redéploiement. Il force HTTPS sur le nom d'hôte généré, ce qui explique que AUTH_COOKIE_SECURE soit absent et doive le rester : en HTTPS le navigateur conserve un cookie Secure. L'installation documentée génère le secret avec openssl rand -hex 32, soit 64 caractères, donc un vrai secret et non une valeur d'exemple qui passe par hasard le contrôle de longueur.

Il file monta un volume su /app/data e imposta STORAGE_PROVIDER a sqlite, quindi le connessioni salvate vivono sul server e sopravvivono a un nuovo deploy. Forza l'HTTPS sull'hostname generato, ed è per questo che AUTH_COOKIE_SECURE è assente e assente deve restare: in HTTPS il browser tiene un cookie Secure. La procedura documentata genera il segreto con openssl rand -hex 32, che dà 64 caratteri ed è quindi un segreto vero e non un segnaposto che per caso supera il controllo sulla lunghezza.

Die Datei hängt ein Volume unter /app/data ein und setzt STORAGE_PROVIDER auf sqlite, gespeicherte Verbindungen liegen also auf dem Server und überstehen ein Redeploy. Sie erzwingt HTTPS auf dem generierten Hostnamen, deshalb fehlt AUTH_COOKIE_SECURE und sollte auch fehlen: der Browser behält ein Secure-Cookie über HTTPS. Das dokumentierte Setup erzeugt das Secret mit openssl rand -hex 32, das sind 64 Zeichen und damit ein echtes statt eines Platzhalters, der die Längenprüfung gerade so besteht.

File ini me-mount volume di /app/data dan men-set STORAGE_PROVIDER ke sqlite, jadi koneksi yang tersimpan tinggal di server dan selamat dari redeploy. Ia memaksa HTTPS pada hostname yang dibuatkan, dan itulah sebabnya AUTH_COOKIE_SECURE tidak ada dan sebaiknya tetap tidak ada: browser menyimpan cookie Secure lewat HTTPS. Penyiapan yang didokumentasikan membuat secret dengan openssl rand -hex 32, yang panjangnya 64 karakter dan karena itu secret sungguhan, bukan placeholder yang kebetulan lolos pemeriksaan panjang.

O arquivo monta um volume em /app/data e põe STORAGE_PROVIDER em sqlite, então as conexões salvas ficam no servidor e sobrevivem a um redeploy. Ele força HTTPS no hostname gerado, e é por isso que AUTH_COOKIE_SECURE está ausente e deve continuar ausente: o navegador guarda um cookie Secure em HTTPS. A configuração documentada gera o segredo com openssl rand -hex 32, que dá 64 caracteres e portanto é um segredo de verdade, não um placeholder que por acaso passa na checagem de tamanho.

A Blueprint in the repository. Render builds the image itself.

Un Blueprint en el repositorio. Render construye la imagen por su cuenta.

リポジトリにある Blueprint。イメージは Render 側でビルドされます。

Blueprint в репозитории. Образ Render собирает сам.

ریپازٹری میں ایک Blueprint۔ امیج Render خود بناتا ہے۔

仓库里的一份 Blueprint。镜像由 Render 自己构建。

儲存庫裡的一份 Blueprint。映像檔由 Render 自己建置。

Blueprint w repozytorium. Render sam buduje obraz.

Un Blueprint dans le dépôt. Render construit l'image lui-même.

Un Blueprint nel repository. L'immagine la costruisce Render.

Ein Blueprint im Repository. Render baut das Image selbst.

Sebuah Blueprint di repository. Render membangun image-nya sendiri.

Um Blueprint no repositório. A Render constrói a imagem ela mesma.

No tag to pin

No hay etiqueta que fijar

固定するタグがない

Нечего закреплять

پن کرنے کو کوئی ٹیگ نہیں

没有标签要钉

沒有標籤要釘

Nie ma tagu do przypięcia

Aucun tag à fixer

Nessun tag da fissare

Kein Tag zum Festnageln

Tidak ada tag untuk dipaku

Não há tag para fixar

Render builds from the repository's Dockerfile rather than pulling a published image, so there is no version tag in this path at all. The service tracks whichever branch you point it at, which means it follows the project rather than a release.

Render construye a partir del Dockerfile del repositorio en lugar de descargar una imagen publicada, así que en este camino no hay ninguna etiqueta de versión. El servicio sigue la rama a la que lo apuntes, es decir, sigue al proyecto y no a una versión.

Render は公開イメージを取得するのではなく、リポジトリの Dockerfile からビルドします。そのためこの経路にはバージョンタグが存在しません。サービスは指定したブランチを追うので、リリースではなくプロジェクトそのものを追いかけます。

Render собирает из Dockerfile в репозитории, а не тянет опубликованный образ, поэтому в этом пути вообще нет тега версии. Сервис следует за той веткой, на которую вы его направите, то есть за проектом, а не за релизом.

Render شائع شدہ امیج کھینچنے کے بجائے ریپازٹری کی Dockerfile سے بناتا ہے، سو اس راستے میں ورژن کا کوئی ٹیگ ہے ہی نہیں۔ سروس اُسی برانچ کے پیچھے چلتی ہے جس پر آپ اسے لگائیں، یعنی کسی ریلیز کے نہیں، خود منصوبے کے پیچھے۔

Render 是从仓库的 Dockerfile 构建，而不是拉一个已发布的镜像，所以这条路上根本没有版本标签。服务跟的是你指给它的分支，也就是跟着项目走，而不是跟着某个版本。

Render 是從儲存庫的 Dockerfile 建置，而不是拉一個已發布的映像檔，所以這條路上根本沒有版本標籤。服務跟的是你指給它的分支，也就是跟著專案走，而不是跟著某個版本。

Render buduje z Dockerfile w repozytorium, zamiast ciągnąć opublikowany obraz, więc na tej ścieżce nie ma w ogóle żadnego tagu wersji. Usługa podąża za gałęzią, którą jej wskażesz, czyli idzie za projektem, a nie za wydaniem.

Render construit à partir du Dockerfile du dépôt au lieu de tirer une image publiée, donc il n'y a aucun tag de version dans ce chemin. Le service suit la branche que vous lui désignez, ce qui veut dire qu'il suit le projet et non une release.

Render costruisce dal Dockerfile del repository invece di scaricare un'immagine pubblicata, quindi in questa strada un tag di versione non c'è proprio. Il servizio segue il branch su cui lo punti, il che vuol dire che segue il progetto e non una release.

Render baut aus dem Dockerfile des Repositorys, statt ein veröffentlichtes Image zu ziehen, in diesem Weg gibt es also überhaupt keinen Versions-Tag. Der Dienst folgt dem Branch, auf den du ihn richtest, und damit dem Projekt statt einem Release.

Render membangun dari Dockerfile di repository alih-alih menarik image yang sudah dipublikasikan, jadi di jalur ini tidak ada tag versi sama sekali. Service-nya mengikuti branch mana pun yang Anda tunjuk, artinya ia mengikuti proyek, bukan sebuah rilis.

A Render constrói a partir do Dockerfile do repositório em vez de baixar uma imagem publicada, então nesse caminho não existe tag de versão nenhuma. O serviço acompanha o branch para o qual você apontar, o que quer dizer que ele segue o projeto e não uma release.

Two defaults worth writing out

Dos valores por defecto que conviene escribir

書き出しておく価値のある二つの既定値

Два умолчания, которые стоит записать

دو طے شدہ قدریں جو لکھ دینی چاہئیں

两个值得写出来的默认值

兩個值得寫出來的預設值

Dwa domyślne ustawienia, które lepiej wypisać wprost

Deux valeurs par défaut qui méritent d'être écrites

Due valori predefiniti che conviene scrivere per esteso

Zwei Voreinstellungen, die man ausschreiben sollte

Dua default yang layak ditulis eksplisit

Dois padrões que vale escrever por extenso

Render fills in plan and region when they are absent, and the Blueprint states neither, so both defaults apply. An omitted plan gets 0.5c-512mb, which is a paid plan rather than the free tier the file's comments assume throughout. An omitted region gets oregon, and Render's own spec says that value cannot be changed after the service is created. Add both to the Blueprint before you deploy from it, or you inherit a paid plan in a region you did not choose and cannot move.

Render rellena plan y region cuando faltan, y el Blueprint no indica ninguno, así que se aplican los dos valores por defecto. Un plan omitido recibe 0.5c-512mb, que es de pago y no el nivel gratuito que los comentarios del fichero dan por supuesto. Una región omitida recibe oregon, y la propia especificación de Render dice que ese valor no se puede cambiar después de crear el servicio. Añade los dos al Blueprint antes de desplegar desde él, o heredarás un plan de pago en una región que no elegiste y no puedes mover.

plan と region を書かないと Render が埋めますが、この Blueprint はどちらも書いていないので、両方とも既定値が適用されます。plan を省くと 0.5c-512mb、つまりファイルのコメントが終始前提にしている無料枠ではなく有料プランになります。region を省くと oregon になり、Render の仕様書はこの値がサービス作成後に変更できないと明言しています。ここからデプロイする前に両方を Blueprint に足してください。さもないと、選んでいない、しかも動かせないリージョンで有料プランを引き継ぐことになります。

Render подставляет plan и region, если их нет, а Blueprint не задаёт ни того, ни другого, так что действуют оба умолчания. Пропущенный plan даёт 0.5c-512mb: платный тариф, а не бесплатный уровень, из которого исходят комментарии в самом файле. Пропущенный region даёт oregon, и спецификация Render прямо говорит, что это значение нельзя изменить после создания сервиса. Добавьте оба в Blueprint, прежде чем разворачивать из него, иначе получите платный тариф в регионе, который не выбирали и не сможете сменить.

plan اور region نہ ہوں تو Render خود بھر دیتا ہے، اور یہ Blueprint دونوں میں سے کوئی نہیں لکھتا، سو دونوں طے شدہ قدریں لاگو ہو جاتی ہیں۔ plan چھوڑ دیں تو 0.5c-512mb ملتا ہے، جو ادائیگی والا منصوبہ ہے، وہ مفت درجہ نہیں جو فائل کے تبصرے شروع سے فرض کرتے ہیں۔ region چھوڑ دیں تو oregon ملتا ہے، اور Render کی اپنی وضاحت کہتی ہے کہ سروس بن جانے کے بعد یہ قدر بدلی نہیں جا سکتی۔ اس سے تعینات کرنے سے پہلے دونوں Blueprint میں شامل کریں، ورنہ آپ کو ایسے ریجن میں ادائیگی والا منصوبہ ورثے میں ملے گا جو آپ نے چنا بھی نہیں اور جسے بدلا بھی نہیں جا سکتا۔

plan 和 region 缺席时 Render 会替你填，而这份 Blueprint 两个都没写，所以两个默认值都会生效。省掉 plan 会得到 0.5c-512mb，那是付费方案，不是文件注释通篇假定的免费额度。省掉 region 会得到 oregon，而 Render 自己的规范写明这个值在服务创建之后改不了。从它部署之前先把这两项加进 Blueprint，否则你会在一个自己没选、又搬不走的区域里继承一个付费方案。

plan 和 region 缺席時 Render 會替你填，而這份 Blueprint 兩個都沒寫，所以兩個預設值都會生效。省掉 plan 會得到 0.5c-512mb，那是付費方案，不是檔案註解通篇假定的免費額度。省掉 region 會得到 oregon，而 Render 自己的規範寫明這個值在服務建立之後改不了。從它部署之前先把這兩項加進 Blueprint，否則你會在一個自己沒選、又搬不走的區域裡繼承一個付費方案。

Render uzupełnia plan i region, kiedy ich brakuje, a Blueprint nie podaje żadnego z nich, więc wchodzą oba domyślne. Pominięty plan dostaje 0.5c-512mb, czyli plan płatny, a nie darmowy poziom, który komentarze w pliku zakładają od początku do końca. Pominięty region dostaje oregon, a specyfikacja samego Rendera mówi, że tej wartości nie da się zmienić po utworzeniu usługi. Dopisz oba do Blueprintu, zanim z niego wdrożysz, albo odziedziczysz płatny plan w regionie, którego nie wybrałeś i z którego się nie ruszysz.

Render complète plan et region quand ils sont absents, et le Blueprint n'indique ni l'un ni l'autre, donc les deux valeurs par défaut s'appliquent. Un plan omis donne 0.5c-512mb, qui est un plan payant et non l'offre gratuite que les commentaires du fichier supposent d'un bout à l'autre. Une région omise donne oregon, et la spécification de Render dit elle-même que cette valeur ne peut plus être changée une fois le service créé. Ajoutez les deux au Blueprint avant de déployer depuis lui, sinon vous héritez d'un plan payant dans une région que vous n'avez pas choisie et que vous ne pouvez pas quitter.

Render riempie plan e region quando mancano, e il Blueprint non dichiara né l'uno né l'altro, quindi valgono entrambi i default. Un piano omesso diventa 0.5c-512mb, che è un piano a pagamento e non il piano gratuito che i commenti del file danno per scontato ovunque. Una region omessa diventa oregon, e la specifica di Render dice che quel valore non si può cambiare dopo la creazione del servizio. Aggiungili tutti e due al Blueprint prima di distribuirlo, altrimenti ti ritrovi un piano a pagamento in una region che non hai scelto e da cui non ti puoi spostare.

Render füllt plan und region auf, wenn sie fehlen, und der Blueprint nennt beides nicht, also greifen beide Voreinstellungen. Ein weggelassener Plan wird 0.5c-512mb, und das ist ein kostenpflichtiger Plan und nicht die kostenlose Stufe, von der die Kommentare in der Datei durchgehend ausgehen. Eine weggelassene Region wird oregon, und Renders eigene Spezifikation sagt, dass sich dieser Wert nach dem Anlegen des Dienstes nicht mehr ändern lässt. Trag beides in den Blueprint ein, bevor du daraus deployst, sonst erbst du einen kostenpflichtigen Plan in einer Region, die du nicht gewählt hast und nicht mehr wechseln kannst.

Render mengisi plan dan region ketika keduanya tidak ada, dan Blueprint ini tidak menyebut satu pun, jadi kedua default itu berlaku. Plan yang dihilangkan mendapat 0.5c-512mb, yang merupakan plan berbayar, bukan tier gratis yang diasumsikan komentar di file itu dari awal sampai akhir. Region yang dihilangkan mendapat oregon, dan spesifikasi Render sendiri mengatakan nilai itu tidak bisa diubah setelah service dibuat. Tambahkan keduanya ke Blueprint sebelum Anda deploy darinya, atau Anda mewarisi plan berbayar di region yang tidak Anda pilih dan tidak bisa dipindahkan.

A Render preenche plan e region quando eles estão ausentes, e o Blueprint não declara nenhum dos dois, então os dois padrões valem. Um plano omitido vira 0.5c-512mb, que é um plano pago e não o tier gratuito que os comentários do arquivo assumem o tempo todo. Uma região omitida vira oregon, e a própria spec da Render diz que esse valor não pode ser mudado depois que o serviço é criado. Coloque os dois no Blueprint antes de fazer deploy a partir dele, ou você herda um plano pago numa região que não escolheu e não pode trocar.

The Blueprint prompts for JWT_SECRET at create time rather than carrying one, which is the right shape. Paste real output from openssl rand -base64 32: the thirty-two character floor stops a short value, not a weak one.

El Blueprint pide JWT_SECRET en el momento de crear en lugar de llevar uno, que es la forma correcta. Pega salida real de openssl rand -base64 32: el mínimo de treinta y dos caracteres detiene un valor corto, no uno débil.

Blueprint は JWT_SECRET を値として持ち回らず、作成時に入力を求めます。これが正しい形です。openssl rand -base64 32 の実際の出力を貼り付けてください。三十二文字という下限が止めるのは短い値であって、弱い値ではありません。

Blueprint не носит JWT_SECRET с собой, а спрашивает его при создании, и это правильная форма. Вставьте настоящий вывод openssl rand -base64 32: порог в тридцать два символа останавливает короткое значение, а не слабое.

Blueprint JWT_SECRET ساتھ لے کر نہیں چلتا بلکہ بناتے وقت پوچھتا ہے، اور یہی درست شکل ہے۔ openssl rand -base64 32 کا اصل نتیجہ چسپاں کریں: بتیس حروف کی حد چھوٹی قدر روکتی ہے، کمزور قدر نہیں۔

Blueprint 不带着 JWT_SECRET 走，而是在创建时问你要，这个形式是对的。请粘贴 openssl rand -base64 32 的真实输出：三十二字符这条底线拦的是短值，不是弱值。

Blueprint 不帶著 JWT_SECRET 走，而是在建立時問你要，這個形式是對的。請貼上 openssl rand -base64 32 的真實輸出：三十二字元這條底線攔的是短值，不是弱值。

Blueprint pyta o JWT_SECRET przy tworzeniu usługi, zamiast nieść gotowy, i to jest właściwy kształt. Wklej prawdziwe wyjście z openssl rand -base64 32: próg trzydziestu dwóch znaków zatrzymuje wartość krótką, a nie słabą.

Le Blueprint demande le JWT_SECRET au moment de la création au lieu d'en transporter un, ce qui est la bonne forme. Collez-y une vraie sortie de openssl rand -base64 32 : le plancher de trente-deux caractères arrête une valeur courte, pas une valeur faible.

Il Blueprint chiede JWT_SECRET al momento della creazione invece di portarselo dietro, ed è la forma giusta. Incolla l'output vero di openssl rand -base64 32: la soglia dei trentadue caratteri ferma un valore corto, non uno debole.

Der Blueprint fragt JWT_SECRET beim Anlegen ab, statt eines mitzubringen, und das ist die richtige Form. Setz echte Ausgabe von openssl rand -base64 32 ein: die Untergrenze von zweiunddreißig Zeichen stoppt einen kurzen Wert, keinen schwachen.

Blueprint ini menanyakan JWT_SECRET saat pembuatan alih-alih membawanya, dan itu bentuk yang benar. Tempelkan output asli dari openssl rand -base64 32: batas bawah tiga puluh dua karakter menahan nilai yang pendek, bukan nilai yang lemah.

O Blueprint pede o JWT_SECRET na hora da criação em vez de carregar um, que é o formato certo. Cole a saída real de openssl rand -base64 32: o piso de trinta e dois caracteres barra um valor curto, não um valor fraco.

A deploy button whose entire service definition lives in its own URL.

Un botón de despliegue cuya definición de servicio completa vive en su propia URL.

デプロイボタン。サービス定義はすべてその URL の中にあります。

Кнопка деплоя, всё определение сервиса которой лежит в её собственном URL.

ایک ڈپلائے بٹن، جس کی پوری سروس تعریف اُسی کے URL میں ہوتی ہے۔

一个部署按钮，整份服务定义就写在它自己的 URL 里。

一個部署按鈕，整份服務定義就寫在它自己的 URL 裡。

Przycisk deploy, którego cała definicja usługi mieszka we własnym URL-u.

Un bouton de déploiement dont toute la définition de service tient dans sa propre URL.

Un pulsante di deploy la cui intera definizione del servizio sta nel suo stesso URL.

Ein Deploy-Button, dessen komplette Service-Definition in seiner eigenen URL steckt.

Sebuah tombol deploy yang seluruh definisi service-nya tinggal di dalam URL-nya sendiri.

Um botão de deploy cuja definição inteira de serviço mora na própria URL.

Change three values before you deploy

Cambia tres valores antes de desplegar

デプロイ前に三つの値を変える

Поменяйте три значения до деплоя

تعینات سے پہلے تین قدریں بدلیں

部署前先改三个值

部署前先改三個值

Zmień trzy wartości, zanim wdrożysz

Changez trois valeurs avant de déployer

Cambia tre valori prima di distribuire

Ändere drei Werte, bevor du deployst

Ubah tiga nilai sebelum Anda deploy

Mude três valores antes de fazer o deploy

JWT_SECRET comes filled in with a placeholder that is deliberately shorter than the thirty-two character minimum, so a deployment left as it stands refuses to start and says why, rather than running on a secret anyone can read. The button carries no passwords at all. The two fields behave differently when they are left unset, and both answers are safe ones: ADMIN_PASSWORD is generated on the first run and printed to the Koyeb runtime log, exactly as a bare docker run does it, and USER_PASSWORD is never generated, so without it the lower-privilege account does not exist at all. Fill either one in on the deploy form if you want to choose it yourself, or if you want that second account. But do not put a placeholder back.

JWT_SECRET viene con un marcador de posición deliberadamente más corto que el mínimo de treinta y dos caracteres, así que un despliegue que se deje tal cual se niega a arrancar y dice por qué, en lugar de funcionar con un secreto que cualquiera puede leer. El botón no trae ninguna contraseña. Los dos campos se comportan de forma distinta cuando se dejan sin poner, y las dos respuestas son seguras: ADMIN_PASSWORD se genera en el primer arranque y se imprime en el registro de ejecución de Koyeb, igual que en un docker run pelado, y USER_PASSWORD no se genera nunca, así que sin ella la cuenta de menor privilegio no existe. Rellena la que quieras en el formulario de despliegue si prefieres elegirla tú, o si quieres esa segunda cuenta; pero no vuelvas a poner un marcador de posición.

JWT_SECRET には、三十二文字の下限よりわざと短いプレースホルダーが入っています。ですから手を入れないまま配置すると、誰でも読める秘密で動き出すのではなく、起動を断って理由を告げます。ボタンはパスワードを一つも運んできません。二つの項目は、空のままにしたときの振る舞いが違い、どちらの答えも安全な側です。ADMIN_PASSWORD は初回起動時に生成され、素の docker run と同じように Koyeb の実行ログへ出力されます。USER_PASSWORD は生成されることがなく、設定しなければ権限の低い口はそもそも作られません。自分で決めたいとき、あるいはその二つ目の口が欲しいときは配置フォームで入れてください。ただしプレースホルダーを戻さないこと。

В JWT_SECRET подставлена заглушка, намеренно короче минимума в тридцать два символа, поэтому развёртывание, оставленное как есть, откажется стартовать и скажет почему, а не будет работать на секрете, который может прочитать кто угодно. Кнопка не несёт ни одного пароля. Два поля ведут себя по-разному, когда их оставляют пустыми, и оба ответа безопасны: ADMIN_PASSWORD генерируется при первом запуске и печатается в журнал выполнения Koyeb, ровно как при голом docker run, а USER_PASSWORD не генерируется никогда, и без него учётной записи с меньшими правами просто нет. Впишите своё значение в форму развёртывания, если хотите выбрать его сами или если вам нужна вторая учётная запись, но не возвращайте заглушку.

JWT_SECRET میں ایک جگہ بھرنے والا متن ہے جو جان بوجھ کر بتیس حرف کی کم از کم حد سے چھوٹا ہے، سو جو تعیناتی جوں کی توں چھوڑ دی جائے وہ چلنے سے انکار کر دیتی ہے اور وجہ بتاتی ہے، بجائے اس کے کہ ایسے راز پر چلے جسے کوئی بھی پڑھ سکے۔ بٹن کوئی پاس ورڈ ساتھ نہیں لاتا۔ دونوں خانے خالی چھوڑنے پر مختلف برتاؤ کرتے ہیں، اور دونوں جواب محفوظ رخ پر ہیں: ADMIN_PASSWORD پہلی بار چلنے پر بنتا ہے اور Koyeb کے رن ٹائم لاگ میں چھپتا ہے، بالکل سادہ docker run کی طرح؛ USER_PASSWORD کبھی نہیں بنتا، اور اس کے بغیر کم اختیار والا اکاؤنٹ سرے سے وجود نہیں رکھتا۔ اگر آپ خود چننا چاہیں، یا وہ دوسرا اکاؤنٹ چاہیں، تو تعیناتی فارم میں اپنی قدر بھر دیں، مگر جگہ بھرنے والا متن واپس نہ رکھیں۔

JWT_SECRET 里填的是一个占位值，长度被有意做得比三十二个字符的下限还短，所以原样部署会拒绝启动并说明原因，而不是带着一个谁都能读到的密钥跑起来。这个按钮不带任何密码过来。两个字段留空时的行为不同，而且两种结果都在安全的一边：ADMIN_PASSWORD 会在首次启动时生成，并打印到 Koyeb 的运行日志里，和裸跑 docker run 一样；USER_PASSWORD 从不生成，不设它就根本没有那个低权限账号。想自己指定，或者想要第二个账号，就在部署表单里填上，但不要再放回占位值。

JWT_SECRET 裡填的是一個佔位值，長度被有意做得比三十二個字元的下限還短，所以原樣部署會拒絕啟動並說明原因，而不是帶著一個誰都能讀到的金鑰跑起來。這個按鈕不帶任何密碼過來。兩個欄位留空時的行為不同，而且兩種結果都在安全的一邊：ADMIN_PASSWORD 會在首次啟動時產生，並印到 Koyeb 的執行日誌裡，和裸跑 docker run 一樣；USER_PASSWORD 從不產生，不設它就根本沒有那個低權限帳號。想自己指定，或者想要第二個帳號，就在部署表單裡填上，但不要再放回佔位值。

JWT_SECRET jest wypełniony zaślepką celowo krótszą niż wymagane minimum trzydziestu dwóch znaków, więc wdrożenie zostawione tak, jak jest, odmawia startu i mówi dlaczego, zamiast chodzić na sekrecie, który każdy może przeczytać. Haseł przycisk nie niesie żadnych. Te dwa pola zachowują się różnie, kiedy zostawisz je puste, i obie odpowiedzi są bezpieczne: ADMIN_PASSWORD jest generowane przy pierwszym uruchomieniu i wypisywane do runtime logu Koyeb, dokładnie tak, jak robi to gołe docker run, a USER_PASSWORD nie jest generowane nigdy, więc bez niego konto o niższych uprawnieniach po prostu nie istnieje. Wypełnij którekolwiek z nich w formularzu wdrożenia, jeśli chcesz wybrać wartość sam albo chcesz mieć to drugie konto, ale nie wstawiaj z powrotem zaślepki.

JWT_SECRET est prérempli avec une valeur d'exemple délibérément plus courte que le minimum de trente-deux caractères, si bien qu'un déploiement laissé tel quel refuse de démarrer et dit pourquoi, plutôt que de tourner sur un secret que n'importe qui peut lire. Le bouton ne porte aucun mot de passe. Les deux champs se comportent différemment quand on les laisse vides, et les deux réponses sont sûres : ADMIN_PASSWORD est généré au premier lancement et écrit dans le log d'exécution Koyeb, exactement comme le fait un simple docker run, et USER_PASSWORD n'est jamais généré, donc sans lui le compte à privilèges réduits n'existe pas du tout. Remplissez l'un ou l'autre dans le formulaire de déploiement si vous voulez le choisir vous-même, ou si vous voulez ce second compte, mais ne remettez pas une valeur d'exemple.

JWT_SECRET arriva già compilato con un segnaposto volutamente più corto del minimo di trentadue caratteri, quindi un deployment lasciato com'è si rifiuta di partire e dice perché, invece di girare su un segreto che chiunque può leggere. Il pulsante non porta nessuna password. I due campi si comportano in modo diverso quando restano vuoti, e sono sicure entrambe le risposte: ADMIN_PASSWORD viene generata al primo avvio e stampata nel log di runtime di Koyeb, esattamente come fa un docker run nudo e crudo, e USER_PASSWORD non viene mai generata, quindi senza di essa l'account con meno privilegi non esiste proprio. Compila l'uno o l'altro nel modulo di deploy se vuoi sceglierli tu, o se quel secondo account lo vuoi, ma non rimetterci un segnaposto.

JWT_SECRET ist mit einem Platzhalter vorbelegt, der absichtlich kürzer ist als das Minimum von zweiunddreißig Zeichen; eine Installation, die so bleibt, wie sie ist, startet nicht und sagt auch warum, statt auf einem Secret zu laufen, das jeder lesen kann. Passwörter bringt der Button überhaupt keine mit. Die beiden Felder verhalten sich unterschiedlich, wenn du sie leer lässt, und beide Antworten sind sichere: ADMIN_PASSWORD wird beim ersten Start erzeugt und ins Koyeb-Runtime-Log geschrieben, genau wie es ein nacktes docker run macht, und USER_PASSWORD wird nie erzeugt, ohne dieses Feld gibt es das Konto mit den geringeren Rechten also gar nicht. Trag eines von beiden im Deploy-Formular ein, wenn du es selbst wählen willst oder wenn du dieses zweite Konto haben willst, aber setz keinen Platzhalter zurück.

JWT_SECRET datang terisi dengan placeholder yang sengaja dibuat lebih pendek dari minimum tiga puluh dua karakter, jadi deployment yang dibiarkan apa adanya menolak start dan menyebutkan alasannya, ketimbang berjalan di atas secret yang bisa dibaca siapa saja. Tombol itu sama sekali tidak membawa password. Kedua kolomnya berperilaku berbeda ketika dibiarkan kosong, dan kedua jawabannya aman: ADMIN_PASSWORD dibuat pada run pertama dan dicetak ke log runtime Koyeb, persis seperti yang dilakukan docker run polos, sedangkan USER_PASSWORD tidak pernah dibuatkan, jadi tanpa itu akun berhak-rendah tidak ada sama sekali. Isi salah satunya di formulir deploy kalau Anda ingin memilihnya sendiri, atau kalau Anda memang mau akun kedua itu, tetapi jangan kembalikan placeholder ke sana.

JWT_SECRET vem preenchido com um placeholder deliberadamente mais curto que o mínimo de trinta e dois caracteres, então um deploy deixado como está se recusa a subir e diz por quê, em vez de rodar com um segredo que qualquer um pode ler. O botão não carrega senha nenhuma. Os dois campos se comportam de forma diferente quando ficam sem valor, e as duas respostas são seguras: ADMIN_PASSWORD é gerada na primeira execução e impressa no log de runtime da Koyeb, exatamente como um docker run puro faz, e USER_PASSWORD nunca é gerada, então sem ela a conta de menor privilégio simplesmente não existe. Preencha qualquer uma das duas no formulário de deploy se quiser escolher você mesmo, ou se quiser essa segunda conta, mas não coloque um placeholder de volta.

Filling them in is not the only way. Clear both fields instead and the application generates its own on first run and prints the credentials to the Koyeb runtime log, the same way a bare docker run does.

Rellenarlos no es la única vía. Vacía los dos campos y la aplicación genera los suyos en el primer arranque e imprime las credenciales en el log de ejecución de Koyeb, igual que hace un docker run pelado.

値を入れるのが唯一の道ではありません。両方の欄を空にすれば、アプリが初回起動時に自分で生成し、素の docker run と同じように Koyeb のランタイムログへ資格情報を出力します。

Заполнить их не единственный путь. Очистите оба поля, и приложение при первом запуске создаст свои и напечатает учётные данные в рантайм-лог Koyeb, ровно как это делает голый docker run.

انہیں بھرنا واحد راستہ نہیں۔ دونوں خانے خالی کر دیں تو ایپ پہلی بار چلنے پر اپنے بنا لیتی ہے اور اسناد Koyeb کے رن ٹائم لاگ میں چھاپ دیتی ہے، بالکل ویسے جیسے سادہ docker run کرتا ہے۔

填上并不是唯一的办法。把两个字段都清空，应用会在首次启动时自己生成，并把凭据打到 Koyeb 的运行日志里，和裸跑 docker run 一样。

填上並不是唯一的辦法。把兩個欄位都清空，應用會在首次啟動時自己產生，並把認證資訊打到 Koyeb 的執行日誌裡，和裸跑 docker run 一樣。

Wypełnienie ich to nie jedyna droga. Wyczyść oba pola, a aplikacja wygeneruje własne przy pierwszym uruchomieniu i wypisze dane logowania do runtime logu Koyeb, tak samo jak gołe docker run.

Les remplir n'est pas la seule voie. Videz plutôt les deux champs et l'application génère les siens au premier lancement puis écrit les identifiants dans le log d'exécution Koyeb, de la même façon qu'un simple docker run.

Compilarli non è l'unica strada. In alternativa svuota entrambi i campi e l'applicazione se li genera da sola al primo avvio e stampa le credenziali nel log di runtime di Koyeb, allo stesso modo di un docker run nudo e crudo.

Ausfüllen ist nicht der einzige Weg. Leer stattdessen beide Felder, dann erzeugt die Anwendung ihre eigenen beim ersten Start und schreibt die Zugangsdaten ins Koyeb-Runtime-Log, genauso wie ein nacktes docker run es tut.

Mengisinya bukan satu-satunya cara. Kosongkan saja kedua kolom itu dan aplikasi membuat sendiri miliknya pada run pertama lalu mencetak kredensialnya ke log runtime Koyeb, sama seperti yang dilakukan docker run polos.

Preencher não é o único caminho. Limpe os dois campos e a aplicação gera os seus próprios na primeira execução e imprime as credenciais no log de runtime da Koyeb, do mesmo jeito que um docker run puro faz.

What it keeps

Qué mantiene

残っている設定

Что осталось

کیا برقرار ہے

它保留了什么

它保留了什麼

Co przechowuje

Ce qu'il conserve

Cosa conserva

Was es behält

Apa yang ia simpan

O que ele guarda

Nothing, on the button's defaults. The free instance has no persistent disk, so STORAGE_PROVIDER is set to local and your saved connections live in the browser rather than on the server. Clear the browser and they are gone, and a second device sees none of them. STORAGE_PROVIDER=sqlite would write to a filesystem that resets on every redeploy. For storage that survives, point STORAGE_POSTGRES_URL at a Koyeb managed Postgres and set STORAGE_PROVIDER=postgres. The button also scales to zero after about an hour idle, so the first request after a quiet night waits for a cold start.

Nada, con los valores por defecto del botón. La instancia gratuita no tiene disco persistente, así que STORAGE_PROVIDER viene en local y tus conexiones guardadas viven en el navegador y no en el servidor: si lo limpias, desaparecen, y un segundo dispositivo no ve ninguna. STORAGE_PROVIDER=sqlite escribiría en un sistema de archivos que se reinicia en cada redespliegue. Para un almacenamiento que sobreviva, apunta STORAGE_POSTGRES_URL a un Postgres gestionado de Koyeb y pon STORAGE_PROVIDER=postgres. El botón además baja a cero tras aproximadamente una hora inactivo, así que la primera petición tras una noche tranquila espera un arranque en frío.

ボタンの既定値では、何も残りません。無料インスタンスに永続ディスクはないので STORAGE_PROVIDER は local になっており、保存した接続はサーバーではなくブラウザーの中にあります。ブラウザーを消せば失われ、別の端末からは一つも見えません。STORAGE_PROVIDER=sqlite は、再配置のたびに初期化されるファイルシステムへ書くことになります。残る保存先が欲しければ、STORAGE_POSTGRES_URL を Koyeb のマネージド Postgres に向け、STORAGE_PROVIDER=postgres にしてください。ボタンはまた、一時間ほど何も来ないとゼロまで縮むので、静かな夜のあとの最初のリクエストはコールドスタートを待ちます。

В настройках самой кнопки менять нечего. У бесплатного инстанса нет постоянного диска, поэтому STORAGE_PROVIDER стоит в local, и сохранённые подключения живут в браузере, а не на сервере: очистите браузер, и их нет, а второе устройство не увидит ни одного. STORAGE_PROVIDER=sqlite писал бы в файловую систему, которая обнуляется при каждом перевыкате. Чтобы хранилище это пережило, направьте STORAGE_POSTGRES_URL на управляемый Postgres в Koyeb и поставьте STORAGE_PROVIDER=postgres. Кнопка к тому же сворачивается до нуля примерно через час простоя, так что первый запрос после тихой ночи ждёт холодного старта.

بٹن کی طے شدہ ترتیب پر کچھ بھی نہیں۔ مفت انسٹنس کے پاس مستقل ڈسک نہیں، اس لیے STORAGE_PROVIDER کو local رکھا گیا ہے اور آپ کے محفوظ کنکشن سرور پر نہیں بلکہ براؤزر میں رہتے ہیں، براؤزر صاف کریں تو ختم، اور دوسرے آلے کو ایک بھی نظر نہیں آتا۔ STORAGE_PROVIDER=sqlite ایسے فائل سسٹم پر لکھے گا جو ہر بار دوبارہ تعیناتی پر صفر ہو جاتا ہے۔ ایسا ذخیرہ چاہیے جو باقی رہے تو STORAGE_POSTGRES_URL کو Koyeb کے منظم Postgres کی طرف کریں اور STORAGE_PROVIDER=postgres کر دیں۔ بٹن تقریباً ایک گھنٹے کی خاموشی کے بعد صفر تک سکڑ بھی جاتا ہے، سو پُرسکون رات کے بعد پہلی درخواست کو ٹھنڈے آغاز کا انتظار کرنا پڑتا ہے۔

按按钮的默认值，什么都不留。免费实例没有持久磁盘，所以 STORAGE_PROVIDER 设成了 local，你保存的连接住在浏览器里而不是服务器上。清掉浏览器就没了，换一台设备也一个都看不到。STORAGE_PROVIDER=sqlite 会写到一个每次重新部署都会归零的文件系统上。想要留得住的存储，就把 STORAGE_POSTGRES_URL 指向 Koyeb 托管的 Postgres，并设上 STORAGE_PROVIDER=postgres。这个按钮还会在大约一小时无请求后缩到零，所以安静一夜之后的第一个请求要等一次冷启动。

按按鈕的預設值，什麼都不留。免費實例沒有持久磁碟，所以 STORAGE_PROVIDER 設成了 local，你儲存的連線住在瀏覽器裡而不是伺服器上，清掉瀏覽器就沒了，換一台裝置也一個都看不到。STORAGE_PROVIDER=sqlite 會寫到一個每次重新部署都會歸零的檔案系統上。想要留得住的儲存，就把 STORAGE_POSTGRES_URL 指向 Koyeb 託管的 Postgres，並設上 STORAGE_PROVIDER=postgres。這個按鈕還會在大約一小時無請求後縮到零，所以安靜一夜之後的第一個請求要等一次冷啟動。

Na domyślnych ustawieniach przycisku: nic. Darmowa instancja nie ma trwałego dysku, więc STORAGE_PROVIDER jest ustawione na local, a twoje zapisane połączenia mieszkają w przeglądarce, nie na serwerze. Wyczyścisz przeglądarkę i nie ma ich, a drugie urządzenie nie widzi z nich żadnego. STORAGE_PROVIDER=sqlite pisałoby do systemu plików, który zeruje się przy każdym redeployu. Żeby dane przetrwały, skieruj STORAGE_POSTGRES_URL na zarządzanego Postgresa w Koyeb i ustaw STORAGE_PROVIDER=postgres. Przycisk skaluje też do zera po mniej więcej godzinie bezczynności, więc pierwsze żądanie po cichej nocy czeka na zimny start.

Rien, avec les valeurs par défaut du bouton. L'instance gratuite n'a pas de disque persistant, donc STORAGE_PROVIDER est réglé sur local et vos connexions enregistrées vivent dans le navigateur plutôt que sur le serveur : videz le navigateur et elles ont disparu, et un second appareil n'en voit aucune. STORAGE_PROVIDER=sqlite écrirait sur un système de fichiers réinitialisé à chaque redéploiement. Pour un stockage qui survit, pointez STORAGE_POSTGRES_URL vers un Postgres managé Koyeb et mettez STORAGE_PROVIDER=postgres. Le bouton descend aussi à zéro après environ une heure d'inactivité, donc la première requête après une nuit calme attend un démarrage à froid.

Niente, con i valori predefiniti del pulsante. L'istanza gratuita non ha disco persistente, quindi STORAGE_PROVIDER è impostato a local e le tue connessioni salvate vivono nel browser invece che sul server. Svuoti il browser e sono sparite, e un secondo dispositivo non ne vede nessuna. STORAGE_PROVIDER=sqlite scriverebbe su un filesystem che si azzera a ogni nuovo deploy. Per uno storage che sopravvive, punta STORAGE_POSTGRES_URL su un Postgres gestito di Koyeb e imposta STORAGE_PROVIDER=postgres. Il pulsante scala anche a zero dopo circa un'ora di inattività, quindi la prima richiesta dopo una notte tranquilla aspetta un avvio a freddo.

Mit den Voreinstellungen des Buttons: nichts. Die kostenlose Instanz hat keine dauerhafte Platte, deshalb steht STORAGE_PROVIDER auf local und deine gespeicherten Verbindungen liegen im Browser statt auf dem Server. Browser leeren und sie sind weg, und ein zweites Gerät sieht keine davon. STORAGE_PROVIDER=sqlite würde auf ein Dateisystem schreiben, das bei jedem Redeploy zurückgesetzt wird. Für Speicher, der das übersteht, richte STORAGE_POSTGRES_URL auf ein von Koyeb verwaltetes Postgres und setz STORAGE_PROVIDER=postgres. Der Button skaliert außerdem nach etwa einer Stunde Leerlauf auf null, die erste Anfrage nach einer ruhigen Nacht wartet also auf einen Kaltstart.

Tidak ada, dengan default tombol itu. Instance gratisnya tidak punya disk permanen, jadi STORAGE_PROVIDER diset ke local dan koneksi yang Anda simpan tinggal di browser, bukan di server: bersihkan browser dan semuanya hilang, dan perangkat kedua tidak melihat satu pun. STORAGE_PROVIDER=sqlite akan menulis ke filesystem yang di-reset setiap kali redeploy. Untuk penyimpanan yang bertahan, arahkan STORAGE_POSTGRES_URL ke Postgres terkelola di Koyeb dan set STORAGE_PROVIDER=postgres. Tombol itu juga menskala ke nol setelah kira-kira satu jam menganggur, jadi permintaan pertama setelah malam yang sepi harus menunggu cold start.

Nada, nos padrões do botão. A instância gratuita não tem disco persistente, então STORAGE_PROVIDER fica em local e suas conexões salvas ficam no navegador e não no servidor: limpe o navegador e elas somem, e um segundo dispositivo não vê nenhuma delas. STORAGE_PROVIDER=sqlite escreveria num sistema de arquivos que é zerado a cada redeploy. Para armazenamento que sobrevive, aponte STORAGE_POSTGRES_URL para um Postgres gerenciado da Koyeb e ponha STORAGE_PROVIDER=postgres. O botão também escala para zero depois de mais ou menos uma hora ocioso, então a primeira requisição depois de uma noite quieta espera um cold start.

What stops the agent

Qué detiene al agente

エージェントが止まる条件

Что останавливает агента

ایجنٹ کو کیا روکتا ہے

什么会拦住智能体

什麼會攔住智慧代理

Co zatrzymuje agenta

Ce qui bloque l'agent

Cosa blocca l'agente

Was den Agenten stoppt

Apa yang menghentikan agent

O que impede o agente

Two conditions decide whether the database agent can run, and they are separate. The first is where the connection lives: a run re-resolves its connection on the server, so one that only your browser knows about is not one it can use. The second only applies to PostgreSQL, and it catches people out: the agent refuses a role that is a superuser or a member of pg_read_server_files, pg_write_server_files or pg_execute_server_program. It says so in the run, because a read-only transaction does not stop server-side file access or program execution. Point it at a least-privilege role, not at the owner.

Dos condiciones deciden si el agente de base de datos puede ejecutarse, y son independientes. La primera es dónde vive la conexión: una ejecución vuelve a resolver su conexión en el servidor, así que una que solo conoce tu navegador no le sirve. La segunda solo afecta a PostgreSQL y pilla a mucha gente: el agente rechaza un rol que sea superusuario o miembro de pg_read_server_files, pg_write_server_files o pg_execute_server_program. Lo dice en la propia ejecución, porque una transacción de solo lectura no impide el acceso a archivos del servidor ni la ejecución de programas. Apúntalo a un rol de mínimo privilegio, no al propietario.

データベースエージェントが動けるかどうかは二つの条件で決まり、二つは別々のものです。一つ目は接続がどこにあるかです。実行はサーバー側で接続を解決し直すので、ブラウザーしか知らない接続は使えません。二つ目は PostgreSQL にだけ効くもので、ここでつまずく人がいます。エージェントは、スーパーユーザーである、あるいは pg_read_server_files、pg_write_server_files、pg_execute_server_program のいずれかに属するロールを拒みます。実行の中でそう言います。読み取り専用トランザクションは、サーバー側のファイルアクセスやプログラム実行を止めないからです。所有者ではなく、最小権限のロールを指してください。

Возможность запуска агента базы данных определяют два условия, и они независимы. Первое касается того, где живёт подключение: запуск заново разрешает своё подключение на сервере, так что то, о котором знает только ваш браузер, ему не подходит. Второе касается только PostgreSQL и многих застаёт врасплох: агент отказывает роли, которая является суперпользователем или входит в pg_read_server_files, pg_write_server_files или pg_execute_server_program. Он прямо говорит об этом в запуске, потому что транзакция только для чтения не мешает доступу к файлам сервера и запуску программ. Направляйте его на роль с минимальными правами, а не на владельца.

ڈیٹابیس ایجنٹ چل سکتا ہے یا نہیں، یہ دو شرطیں طے کرتی ہیں، اور یہ الگ الگ ہیں۔ پہلی یہ کہ کنکشن کہاں رہتا ہے: ہر چلن اپنا کنکشن سرور پر دوبارہ حل کرتا ہے، سو جس کا علم صرف آپ کے براؤزر کو ہے وہ اس کے کام کا نہیں۔ دوسری صرف PostgreSQL پر لاگو ہوتی ہے اور لوگ اسی پر پھنستے ہیں: ایجنٹ ایسے رول کو رد کر دیتا ہے جو سپر یوزر ہو یا pg_read_server_files، pg_write_server_files یا pg_execute_server_program کا رکن ہو۔ وہ چلن کے اندر یہ بات کہتا بھی ہے، کیونکہ صرف پڑھنے والا ٹرانزیکشن سرور کی فائلوں تک رسائی یا پروگرام چلانے کو نہیں روکتا۔ اسے مالک کے بجائے کم سے کم اختیار والے رول کی طرف لگائیں۔

数据库智能体能不能跑，由两个条件决定，而且这两个是分开的。第一个是连接在哪里：每次运行都会在服务端重新解析它的连接，所以只有你浏览器知道的连接它用不了。第二个只对 PostgreSQL 生效，而且很容易让人栽跟头：如果角色是超级用户，或者属于 pg_read_server_files、pg_write_server_files、pg_execute_server_program 中的任何一个，智能体会拒绝。它会在运行里把这话讲出来，因为一个只读事务并不能阻止服务端的文件访问或程序执行。把它指向一个最小权限的角色，而不是属主。

資料庫智慧代理能不能跑，由兩個條件決定，而且這兩個是分開的。第一個是連線在哪裡：每次執行都會在伺服器端重新解析它的連線，所以只有你瀏覽器知道的連線它用不了。第二個只對 PostgreSQL 生效，而且很容易讓人栽跟頭：如果角色是超級使用者，或者屬於 pg_read_server_files、pg_write_server_files、pg_execute_server_program 中的任何一個，智慧代理會拒絕。它會在執行裡把這話講出來，因為一個唯讀交易並不能阻止伺服器端的檔案存取或程式執行。把它指向一個最小權限的角色，而不是擁有者。

O tym, czy agent bazy danych może wystartować, decydują dwa warunki i są od siebie niezależne. Pierwszy to miejsce, w którym mieszka połączenie: uruchomienie rozwiązuje swoje połączenie jeszcze raz po stronie serwera, więc takie, o którym wie tylko twoja przeglądarka, do niczego mu się nie przyda. Drugi dotyczy wyłącznie PostgreSQL-a i to on zaskakuje ludzi: agent odmawia roli, która jest superuserem albo należy do pg_read_server_files, pg_write_server_files lub pg_execute_server_program. Mówi o tym wprost w uruchomieniu, bo transakcja tylko do odczytu nie powstrzymuje dostępu do plików po stronie serwera ani uruchamiania programów. Skieruj go na rolę o minimalnych uprawnieniach, a nie na właściciela.

Deux conditions décident si l'agent de base de données peut tourner, et elles sont distinctes. La première est l'endroit où vit la connexion : une exécution re-résout sa connexion sur le serveur, donc une connexion que seul votre navigateur connaît n'en est pas une qu'il puisse utiliser. La seconde ne concerne que PostgreSQL, et elle prend les gens au dépourvu : l'agent refuse un rôle superuser ou membre de pg_read_server_files, pg_write_server_files ou pg_execute_server_program. Il le dit dans l'exécution, parce qu'une transaction en lecture seule n'empêche ni l'accès aux fichiers côté serveur ni l'exécution de programmes. Pointez-le vers un rôle à privilèges minimaux, pas vers le propriétaire.

Due condizioni decidono se l'agente di database può girare, e sono separate. La prima è dove vive la connessione: un'esecuzione risolve di nuovo la sua connessione sul server, quindi una che conosce solo il tuo browser non è una che l'esecuzione possa usare. La seconda vale solo per PostgreSQL, e coglie in fallo parecchie persone: l'agente rifiuta un ruolo che sia superuser o membro di pg_read_server_files, pg_write_server_files o pg_execute_server_program. Lo dice nell'esecuzione, perché una transazione in sola lettura non impedisce l'accesso ai file sul server né l'esecuzione di programmi. Puntalo su un ruolo con i privilegi minimi, non sul proprietario.

Zwei Bedingungen entscheiden, ob der Datenbank-Agent laufen kann, und sie sind voneinander unabhängig. Die erste ist, wo die Verbindung liegt: ein Lauf löst seine Verbindung auf dem Server neu auf, eine, von der nur dein Browser weiß, kann er also nicht benutzen. Die zweite betrifft nur PostgreSQL, und sie erwischt viele: der Agent verweigert eine Rolle, die Superuser oder Mitglied von pg_read_server_files, pg_write_server_files oder pg_execute_server_program ist. Er sagt das im Lauf, denn eine Nur-Lese-Transaktion verhindert weder serverseitigen Dateizugriff noch das Ausführen von Programmen. Richte ihn auf eine Rolle mit minimalen Rechten, nicht auf den Owner.

Dua syarat menentukan apakah agent database bisa berjalan, dan keduanya terpisah. Yang pertama adalah di mana koneksinya tinggal: sebuah run me-resolve ulang koneksinya di server, jadi koneksi yang hanya diketahui browser Anda bukan koneksi yang bisa ia pakai. Yang kedua hanya berlaku untuk PostgreSQL, dan inilah yang sering menjebak orang: agent menolak role yang superuser atau anggota pg_read_server_files, pg_write_server_files atau pg_execute_server_program. Ia mengatakannya di dalam run, karena transaksi read-only tidak menghentikan akses file sisi server maupun eksekusi program. Arahkan ke role dengan hak paling kecil, bukan ke pemiliknya.

Duas condições decidem se o agente de banco de dados pode rodar, e elas são separadas. A primeira é onde a conexão mora: uma execução resolve a conexão de novo no servidor, então uma que só o seu navegador conhece não serve. A segunda vale só para PostgreSQL, e pega muita gente de surpresa: o agente recusa uma role que seja superuser ou membro de pg_read_server_files, pg_write_server_files ou pg_execute_server_program. Ele diz isso na execução, porque uma transação somente leitura não impede acesso a arquivos do servidor nem execução de programas. Aponte para uma role de menor privilégio, não para a dona do banco.

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

DigitalOcean

1-Click Droplet from the Marketplace. Ubuntu 24.04 LTS. The listing ships 0.16.0, two releases behind the 0.17.0 these pages describe, so a detail here and there will not match. The first-boot script sets AUTH_COOKIE_SECURE=false for you, which is what a droplet answering on plain HTTP needs: without it the session cookie is marked Secure, the browser withholds it, and the login screen returns you to itself.

Droplet 1-Click desde el Marketplace. Ubuntu 24.04 LTS. El listado entrega 0.16.0, dos releases por detrás de la 0.17.0 que describen estas páginas, así que algún detalle suelto no coincidirá. El script del primer arranque pone AUTH_COOKIE_SECURE=false por ti, que es lo que necesita un droplet que responde por HTTP plano: sin eso la cookie de sesión se marca Secure, el navegador no la manda, y la pantalla de acceso te devuelve a sí misma.

Marketplace の 1-Click Droplet。Ubuntu 24.04 LTS。この出品が配るのは 0.16.0 で、これらのページが説明している 0.17.0 より二つ前のリリースです。細部はところどころ食い違います。初回起動のスクリプトが AUTH_COOKIE_SECURE=false を代わりに設定してくれます。平文 HTTP で応答するドロップレットに要るのは、まさにこれです。これが無いとセッション Cookie に Secure が付き、ブラウザーはそれを送らず、ログイン画面は自分自身へ戻してきます。

1-Click Droplet из Marketplace. Ubuntu 24.04 LTS. Листинг выдаёт 0.16.0, что на два выпуска позади 0.17.0, о которой эти страницы, так что какая-нибудь деталь с ними не совпадёт. Скрипт первой загрузки сам задаёт AUTH_COOKIE_SECURE=false, а это и нужно дроплету, который отвечает по обычному HTTP: без этого сессионная кука помечается Secure, браузер её не отправляет, и экран входа возвращает вас на него же.

1-Click Droplet، Marketplace سے۔ Ubuntu 24.04 LTS۔ یہ فہرست 0.16.0 دیتی ہے، ان صفحات کی 0.17.0 سے دو ریلیز پیچھے، سو کہیں کوئی ایک آدھ تفصیل نہیں ملے گی۔ پہلی بار چلنے والا اسکرپٹ آپ کے لیے خود AUTH_COOKIE_SECURE=false مقرر کر دیتا ہے، اور سادہ HTTP پر جواب دینے والے ڈراپلیٹ کو یہی درکار ہے: اس کے بغیر سیشن کوکی پر Secure لگ جاتا ہے، براؤزر اسے روک لیتا ہے، اور لاگ اِن اسکرین آپ کو واپس اپنے ہی پاس لے آتی ہے۔

来自 Marketplace 的 1-Click Droplet。Ubuntu 24.04 LTS。这个上架发的是 0.16.0，比这些页面讲的 0.17.0 落后两个版本，所以这儿那儿会有一处细节对不上。首次启动的脚本会替你设好 AUTH_COOKIE_SECURE=false，而这正是一个用明文 HTTP 应答的 droplet 所需要的：没有它，会话 cookie 会被打上 Secure，浏览器就不把它发出去，登录页面于是把你退回它自己。

來自 Marketplace 的 1-Click Droplet。Ubuntu 24.04 LTS。這個上架發的是 0.16.0，比這些頁面講的 0.17.0 落後兩個版本，所以這裡那裡會有一處細節對不上。首次啟動的腳本會替你設好 AUTH_COOKIE_SECURE=false，而這正是一台以明文 HTTP 回應的 droplet 所需要的：沒有它，工作階段 cookie 會被打上 Secure，瀏覽器就不把它送出去，登入畫面於是把你退回它自己。

1-Click Droplet z Marketplace. Ubuntu 24.04 LTS. Wpis wystawia 0.16.0, o dwa wydania za 0.17.0, którą opisują te strony, więc gdzieniegdzie jakiś szczegół się nie zgodzi. Skrypt pierwszego startu sam ustawia AUTH_COOKIE_SECURE=false, a tego właśnie potrzebuje droplet odpowiadający po zwykłym HTTP: bez tego ciasteczko sesji dostaje flagę Secure, przeglądarka go nie wysyła, a ekran logowania zwraca cię z powrotem do siebie.

Droplet 1-Click depuis la Marketplace. Ubuntu 24.04 LTS. L'annonce livre la 0.16.0, deux releases derrière la 0.17.0 que ces pages décrivent, donc tel ou tel détail ne correspondra pas. Le script de premier démarrage met AUTH_COOKIE_SECURE=false à votre place, et c'est exactement ce qu'il faut à un droplet qui répond en HTTP simple : sans cela, le cookie de session est marqué Secure, le navigateur le retient, et l'écran de connexion vous renvoie à lui-même.

Droplet 1-Click dal Marketplace. Ubuntu 24.04 LTS. L'inserzione distribuisce la 0.16.0, due release indietro rispetto alla 0.17.0 che queste pagine descrivono, quindi un dettaglio qua e là non corrisponderà. Lo script del primo avvio imposta AUTH_COOKIE_SECURE=false al posto tuo, ed è quello che serve a un droplet che risponde in HTTP semplice: senza, il cookie di sessione viene marcato Secure, il browser non lo manda, e la schermata di accesso ti rimanda a sé stessa.

1-Click-Droplet aus dem Marketplace. Ubuntu 24.04 LTS. Das Listing liefert 0.16.0 aus, zwei Releases hinter dem 0.17.0, das diese Seiten beschreiben, das eine oder andere Detail passt also nicht. Das Skript beim ersten Start setzt AUTH_COOKIE_SECURE=false für dich, und genau das braucht ein Droplet, das über einfaches HTTP antwortet: ohne das wird das Session-Cookie als Secure markiert, der Browser hält es zurück, und die Anmeldemaske schickt dich zu sich selbst zurück.

Droplet 1-Click dari Marketplace. Ubuntu 24.04 LTS. Listing-nya mengirim 0.16.0, dua rilis di belakang 0.17.0 yang dibahas halaman-halaman ini, jadi ada satu dua detail yang tidak akan cocok. Skrip boot pertama sudah menyetel AUTH_COOKIE_SECURE=false untuk Anda, dan itulah yang dibutuhkan droplet yang menjawab lewat HTTP biasa: tanpa itu cookie sesi ditandai Secure, peramban menahannya, dan layar login mengembalikan Anda ke layar login lagi.

Droplet 1-Click do Marketplace. Ubuntu 24.04 LTS. O anúncio entrega a 0.16.0, duas releases atrás da 0.17.0 que estas páginas descrevem, então um detalhe ou outro não vai bater. O script de primeiro boot já define AUTH_COOKIE_SECURE=false para você, que é o que um droplet respondendo em HTTP puro precisa: sem isso o cookie de sessão é marcado como Secure, o navegador segura ele, e a tela de login devolve você para ela mesma.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Open the LibreDB Studio listing in the DigitalOcean Marketplace.
2. Press Create LibreDB Studio Droplet.
3. Pick a region and a size. The snapshot is built on a 25 GB disk, so the droplet has to have at least that much: the 10 GB shared-CPU size cannot take it.
4. Add your SSH key and create.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

Give first boot a minute. It generates credentials unique to that droplet and starts the container under a systemd unit. Then open http://your-droplet-ip:3000.

Dale un minuto al primer arranque. Genera credenciales únicas para ese droplet y arranca el contenedor bajo una unidad de systemd. Luego abre http://your-droplet-ip:3000.

最初の起動には一分ほど見てください。そのドロップレット固有の資格情報を生成し、systemd ユニットとしてコンテナを起動します。その後 http://your-droplet-ip:3000 を開きます。

Дайте первому запуску минуту. Он генерирует учётные данные, уникальные для этого дроплета, и запускает контейнер под юнитом systemd. Затем откройте http://your-droplet-ip:3000.

پہلی بار چلنے کو ایک منٹ دیں۔ یہ اُس ڈراپلیٹ کے لیے منفرد اسناد تیار کرتا ہے اور کنٹینر کو systemd یونٹ کے تحت چلا دیتا ہے۔ پھر http://your-droplet-ip:3000 کھولیں۔

第一次启动给它一分钟。它会生成这台 droplet 专属的凭据，并把容器挂在一个 systemd 单元下启动。然后打开 http://your-droplet-ip:3000。

第一次啟動給它一分鐘。它會產生這台 droplet 專屬的認證資訊，並把容器掛在一個 systemd 單元下啟動。然後打開 http://your-droplet-ip:3000。

Daj pierwszemu uruchomieniu minutę. Generuje dane logowania unikalne dla tego dropletu i startuje kontener jako jednostkę systemd. Potem otwórz http://your-droplet-ip:3000.

Laissez une minute au premier démarrage. Il génère des identifiants propres à ce droplet et démarre le container sous une unité systemd. Ouvrez ensuite http://your-droplet-ip:3000.

Dai al primo avvio un minuto. Genera credenziali uniche per quel droplet e avvia il container sotto un'unità systemd. Poi apri http://your-droplet-ip:3000.

Gib dem ersten Start eine Minute. Er erzeugt Zugangsdaten, die es nur auf diesem Droplet gibt, und startet den Container unter einer systemd-Unit. Dann öffne http://your-droplet-ip:3000.

Beri boot pertama waktu satu menit. Ia membuat kredensial yang unik untuk droplet itu dan menjalankan container di bawah sebuah unit systemd. Lalu buka http://your-droplet-ip:3000.

Dê um minuto ao primeiro boot. Ele gera credenciais únicas daquele droplet e sobe o container sob uma unit do systemd. Depois abra http://your-droplet-ip:3000.

To get the credentials, SSH in as root; the message of the day says where they are. The droplet generates two accounts, admin@libredb.org and user@libredb.org, each with its own password, and both sit in /etc/libredb-studio.env. How that file is written is worth knowing if anyone else has a login on the box. The listing ships 0.16.0, and the script that release runs creates the file with a plain redirect and narrows the mode afterwards, and cloud-init runs that script under a umask of 0022, so for the moment between the two the file is world-readable with live passwords in it. 0.16.1 and later write it under umask 077 into a temporary name and then moves it into place, so the finished name is the only state anyone else can see. Rotate both passwords after first boot.

Para obtener las credenciales, entra por SSH como root; el mensaje del día dice dónde están. El droplet genera dos cuentas, admin@libredb.org y user@libredb.org, cada una con su contraseña, y ambas están en /etc/libredb-studio.env. Merece la pena saber cómo se escribe ese archivo si alguien más tiene acceso a la máquina. El listado entrega 0.16.0, y el script que ejecuta esa release crea el archivo con una redirección simple y restringe el modo después, y cloud-init ejecuta ese script con una umask de 0022: durante el instante entre ambas cosas el archivo es legible por todos y contiene contraseñas vivas. La 0.16.1 y posteriores lo escriben bajo umask 077 con un nombre temporal y luego lo mueven a su sitio, así que el nombre definitivo es el único estado que puede ver cualquier otra persona. Rota las dos contraseñas después del primer arranque.

資格情報を見るには root で SSH してください。どこにあるかは motd が教えてくれます。ドロップレットは admin@libredb.org と user@libredb.org の二つのアカウントを作り、それぞれに別のパスワードを与え、どちらも /etc/libredb-studio.env に置きます。この機械に他の誰かのログインがあるなら、そのファイルの書かれ方は知っておく価値があります。この出品が配るのは 0.16.0 で、そのリリースが走らせるスクリプトは、単純なリダイレクトでこのファイルを作り、モードを狭めるのはそのあとです。そして cloud-init はそのスクリプトを umask 0022 で走らせます。つまり、その二つの間のわずかな時間、このファイルは生きたパスワードを抱えたまま誰にでも読める状態になります。0.16.1 以降は umask 077 のもとで一時的な名前に書き、所定の場所へ移すので、他の誰かに見えるのは出来上がった名前だけです。初回起動のあとは、二つのパスワードをどちらも入れ替えてください。

Чтобы получить учётные данные, зайдите по SSH под root; сообщение дня скажет, где они. Дроплет создаёт две учётные записи, admin@libredb.org и user@libredb.org, каждую со своим паролем, и обе лежат в /etc/libredb-studio.env. То, как пишется этот файл, стоит знать, если на машине есть чужой вход. Листинг выдаёт 0.16.0, и скрипт этого выпуска создаёт файл обычным перенаправлением и сужает режим уже потом, а cloud-init запускает этот скрипт с umask 0022, а значит, в промежутке между этими двумя действиями файл доступен на чтение всем и содержит живые пароли. В 0.16.1 и новее он пишется под umask 077 во временное имя, а затем переносится на место, так что готовое имя остаётся единственным состоянием, которое видит кто-то ещё. После первой загрузки смените оба пароля.

سندیں دیکھنے کے لیے root کے طور پر SSH کریں؛ دن کا پیغام بتا دے گا کہ وہ کہاں ہیں۔ ڈراپلیٹ دو اکاؤنٹ بناتا ہے، admin@libredb.org اور user@libredb.org، ہر ایک کا اپنا پاس ورڈ، اور دونوں /etc/libredb-studio.env میں ہوتے ہیں۔ اگر اس مشین پر کسی اور کا بھی لاگ اِن ہے تو یہ فائل کس طرح لکھی جاتی ہے، یہ جاننے کے لائق ہے۔ یہ فہرست 0.16.0 دیتی ہے، اور اُس ریلیز کا چلایا ہوا اسکرپٹ فائل کو سادہ ری ڈائریکٹ سے بناتا ہے اور موڈ بعد میں تنگ کرتا ہے، جبکہ cloud-init اُس اسکرپٹ کو umask 0022 پر چلاتا ہے، سو ان دونوں کے درمیان کے لمحے میں یہ فائل زندہ پاس ورڈ لیے ہوئے سب کے پڑھنے کے قابل ہوتی ہے۔ 0.16.1 اور اس کے بعد والی اسے umask 077 کے تحت ایک عارضی نام سے لکھتی ہیں اور پھر جگہ پر منتقل کر دیتی ہیں، سو کسی اور کو نظر آنے والی واحد حالت مکمل نام ہی ہوتی ہے۔ پہلی بار چلنے کے بعد دونوں پاس ورڈ بدل دیں۔

要拿到凭据，用 root 通过 SSH 登进去；每日提示会告诉你它们在哪。droplet 会生成两个账号，admin@libredb.org 和 user@libredb.org，各有各的密码，两个都放在 /etc/libredb-studio.env 里。如果这台机器上还有别人的登录账号，那么这个文件是怎么写出来的就值得知道一下。这个上架发的是 0.16.0，那个版本跑的脚本用一个普通的重定向创建它，之后才把权限收紧，而 cloud-init 跑这个脚本时的 umask 是 0022，也就是说，在这两步之间的那一瞬，这个装着实时密码的文件是所有人可读的。0.16.1 及以后的版本则是在 umask 077 下先写成一个临时名字，再移动到位，所以别人能看到的状态只有写好之后的那个名字。首次启动之后，把两个密码都换掉。

要拿到認證資訊，用 root 透過 SSH 登進去；每日提示會告訴你它們在哪。droplet 會產生兩個帳號，admin@libredb.org 和 user@libredb.org，各有各的密碼，兩個都放在 /etc/libredb-studio.env 裡。如果這台機器上還有別人的登入帳號，那麼這個檔案是怎麼寫出來的就值得知道一下。這個上架發的是 0.16.0，那個版本跑的腳本用一個普通的重新導向建立它，之後才把權限收緊，而 cloud-init 跑這個腳本時的 umask 是 0022，也就是說，在這兩步之間的那一瞬，這個裝著即時密碼的檔案是所有人可讀的。0.16.1 及之後的版本則是在 umask 077 下先寫成一個臨時名字，再移動到位，所以別人能看到的狀態只有寫好之後的那個名字。首次啟動之後，把兩個密碼都換掉。

Po dane logowania zaloguj się przez SSH jako root; message of the day mówi, gdzie ich szukać. Droplet generuje dwa konta, admin@libredb.org i user@libredb.org, każde z własnym hasłem, i oba siedzą w /etc/libredb-studio.env. To, jak ten plik powstaje, warto znać, jeśli ktoś jeszcze ma konto na tej maszynie. Wpis wystawia 0.16.0, a skrypt, który to wydanie uruchamia, tworzy plik zwykłym przekierowaniem i dopiero potem zawęża uprawnienia, a cloud-init uruchamia ten skrypt z umaskiem 0022, więc przez chwilę między jednym a drugim plik jest do odczytu dla wszystkich i ma w środku żywe hasła. Wersja 0.16.1 i nowsze zapisują go pod umask 077 do nazwy tymczasowej, a potem przenoszą na miejsce, więc gotowa nazwa jest jedynym stanem, jaki widzi ktokolwiek inny. Po pierwszym starcie zmień oba hasła.

Pour obtenir les identifiants, connectez-vous en SSH en tant que root ; le message du jour indique où ils sont. Le droplet génère deux comptes, admin@libredb.org et user@libredb.org, chacun avec son propre mot de passe, et tous deux se trouvent dans /etc/libredb-studio.env. La façon dont ce fichier est écrit mérite d'être connue si quelqu'un d'autre a un accès sur la machine. L'annonce livre la 0.16.0, et le script qu'exécute cette release crée le fichier avec une simple redirection puis en restreint les droits ensuite, et cloud-init exécute ce script sous un umask de 0022, donc pendant l'instant qui sépare les deux, le fichier est lisible par tout le monde avec des mots de passe valides dedans. La 0.16.1 et les suivantes l'écrivent sous umask 077 dans un nom temporaire puis le déplacent à sa place, si bien que le nom définitif est le seul état que quelqu'un d'autre puisse voir. Changez les deux mots de passe après le premier démarrage.

Per avere le credenziali, entra in SSH come root; il messaggio del giorno dice dove sono. Il droplet genera due account, admin@libredb.org e user@libredb.org, ciascuno con la sua password, e stanno tutti e due in /etc/libredb-studio.env. Come quel file viene scritto vale la pena saperlo se sulla macchina ha un login anche qualcun altro. L'inserzione distribuisce la 0.16.0, e lo script che quella release esegue crea il file con una redirezione semplice e ne restringe i permessi dopo, e cloud-init esegue quello script con una umask 0022, quindi nel momento che sta tra le due cose il file è leggibile da tutti con dentro password vive. La 0.16.1 e le successive lo scrivono sotto umask 077 con un nome temporaneo e poi lo spostano al suo posto, così il nome finale è l'unico stato che qualcun altro può vedere. Cambia entrambe le password dopo il primo avvio.

Für die Zugangsdaten meld dich per SSH als root an; die Message of the Day sagt, wo sie stehen. Das Droplet erzeugt zwei Konten, admin@libredb.org und user@libredb.org, jedes mit eigenem Passwort, und beide stehen in /etc/libredb-studio.env. Wie diese Datei geschrieben wird, solltest du kennen, wenn noch jemand anderes einen Login auf der Maschine hat. Das Listing liefert 0.16.0 aus, und das Skript, das dieses Release ausführt, legt die Datei mit einer einfachen Umleitung an und engt die Rechte erst danach ein, und cloud-init führt dieses Skript unter einer umask von 0022 aus. In dem Moment dazwischen ist die Datei für alle lesbar und enthält gültige Passwörter. 0.16.1 und neuer schreiben sie unter umask 077 in einen temporären Namen und schieben sie dann an ihren Platz, der fertige Name ist also der einzige Zustand, den jemand anderes zu sehen bekommt. Wechsel beide Passwörter nach dem ersten Start.

Untuk mendapatkan kredensialnya, SSH masuk sebagai root; message of the day menyebutkan di mana letaknya. Droplet membuat dua akun, admin@libredb.org dan user@libredb.org, masing-masing dengan password sendiri, dan keduanya berada di /etc/libredb-studio.env. Bagaimana file itu ditulis layak diketahui kalau ada orang lain yang punya login di mesin itu. Listing-nya mengirim 0.16.0, dan skrip yang dijalankan rilis itu membuat file tersebut dengan redirect biasa lalu mempersempit mode-nya setelahnya, dan cloud-init menjalankan skrip itu di bawah umask 0022, jadi untuk sesaat di antara keduanya file itu bisa dibaca seluruh dunia sementara berisi password yang hidup. 0.16.1 dan seterusnya menulisnya di bawah umask 077 ke nama sementara lalu memindahkannya ke tempatnya, jadi nama final itulah satu-satunya keadaan yang bisa dilihat orang lain. Ganti kedua password itu setelah boot pertama.

Para pegar as credenciais, entre por SSH como root; a mensagem do dia diz onde elas estão. O droplet gera duas contas, admin@libredb.org e user@libredb.org, cada uma com a própria senha, e as duas ficam em /etc/libredb-studio.env. Vale saber como esse arquivo é escrito se mais alguém tem login na máquina. O anúncio entrega a 0.16.0, e o script que essa release roda cria o arquivo com um redirecionamento simples e só depois fecha o modo, e o cloud-init roda esse script sob um umask de 0022, então no intervalo entre as duas coisas o arquivo fica legível por todo mundo com senhas vivas dentro. A 0.16.1 e as posteriores escrevem o arquivo sob umask 077 com um nome temporário e depois movem para o lugar, então o nome final é o único estado que mais alguém consegue ver. Troque as duas senhas depois do primeiro boot.

The image is close to the AWS and Azure ones in shape: Ubuntu 24.04, the published container, run by systemd, credentials generated on your own instance at first boot. One difference is worth knowing: this droplet pins the container by tag, while the AWS image and the Azure template both pin it by digest. The one place where what you can boot today falls short of the AWS image is the write above. Nothing phones home and the publisher has no access to your droplet.

La imagen se parece en forma a las de AWS y Azure: Ubuntu 24.04, el contenedor publicado, ejecutado por systemd, credenciales generadas en tu propia instancia en el primer arranque. Vale la pena conocer una diferencia: este droplet fija el contenedor por etiqueta, mientras que la imagen de AWS y la plantilla de Azure lo fijan las dos por digest. El único punto en el que lo que puedes arrancar hoy se queda por detrás de la imagen de AWS es la escritura de arriba. Nada llama a casa y el editor no tiene acceso a tu droplet.

このイメージは、形としては AWS や Azure のものに近いです。Ubuntu 24.04、公開コンテナ、systemd による起動、そして初回起動時に自分のインスタンス上で生成される資格情報。知っておく価値のある違いが一つあります。このドロップレットはコンテナをタグで固定していますが、AWS のイメージと Azure のテンプレートはどちらもダイジェストで固定しています。いま起動できるものが AWS のイメージに一つだけ及ばないのが、上で述べた書き込み方です。どこにも通信しませんし、公開者はあなたのドロップレットに触れません。

По устройству образ близок к образам AWS и Azure: Ubuntu 24.04, опубликованный контейнер, запуск через systemd, учётные данные, создаваемые на вашем же экземпляре при первой загрузке. Об одном различии стоит знать: этот дроплет закрепляет контейнер по тегу, а образ AWS и шаблон Azure закрепляют его оба по дайджесту. Единственное, в чём то, что можно запустить сегодня, уступает образу AWS, это описанная выше запись файла. Никуда ничего не отправляется, и у издателя нет доступа к вашему дроплету.

شکل کے اعتبار سے یہ امیج AWS اور Azure والوں کے قریب ہے: Ubuntu 24.04، شائع شدہ کنٹینر، systemd سے چلتی ہوئی، اور سندیں جو آپ ہی کے انسٹینس پر پہلی بار چلنے پر بنتی ہیں۔ ایک فرق جاننے کے قابل ہے: یہ ڈراپلیٹ کنٹینر کو ٹیگ سے جماتا ہے، جبکہ AWS کی امیج اور Azure کا ٹیمپلیٹ دونوں اسے ڈائجسٹ سے جماتے ہیں۔ آج آپ جو چلا سکتے ہیں وہ AWS کی امیج سے صرف ایک جگہ پیچھے ہے، اور وہ اوپر بیان کی گئی لکھائی ہے۔ کچھ بھی گھر فون نہیں کرتا اور شائع کرنے والے کی آپ کے ڈراپلیٹ تک کوئی رسائی نہیں۔

这个镜像在形态上和 AWS、Azure 那两个很接近：Ubuntu 24.04、已发布的容器、由 systemd 拉起、凭据在你自己的实例上首次启动时生成。有一处差别值得知道：这台 droplet 是按标签固定容器的，而 AWS 的镜像和 Azure 的模板都是按摘要固定。你今天能启动的那一版，唯一不如 AWS 镜像的地方就是上面讲的那次写入。没有任何东西回传，发布方也碰不到你的 droplet。

這個映像檔在形態上和 AWS、Azure 那兩個很接近：Ubuntu 24.04、已發布的容器、由 systemd 拉起、認證資訊在你自己的實例上首次啟動時產生。有一處差別值得知道：這台 droplet 是按標籤固定容器的，而 AWS 的映像檔和 Azure 的範本都是按摘要固定。你今天能啟動的那一版，唯一不如 AWS 映像檔的地方就是上面講的那次寫入。沒有任何東西回傳，發布方也碰不到你的 droplet。

Kształtem obraz jest blisko tych z AWS i Azure: Ubuntu 24.04, opublikowany kontener, uruchamiany przez systemd, dane logowania generowane na twojej własnej instancji przy pierwszym starcie. Jedną różnicę warto znać: ten droplet przypina kontener tagiem, a obraz AWS i szablon Azure przypinają go oba digestem. Jedyne miejsce, w którym to, co dziś wystartujesz, ustępuje obrazowi AWS, to opisany wyżej zapis pliku. Nic nie dzwoni do domu, a wydawca nie ma dostępu do twojego dropletu.

L'image est proche de celles d'AWS et d'Azure dans sa forme : Ubuntu 24.04, le container publié, lancé par systemd, identifiants générés sur votre propre instance au premier démarrage. Une différence mérite d'être connue : ce droplet fixe le container par tag, tandis que l'image AWS et le template Azure le fixent tous les deux par digest. Le seul point où ce que vous pouvez démarrer aujourd'hui reste en deçà de l'image AWS est l'écriture ci-dessus. Rien ne téléphone à la maison et l'éditeur n'a aucun accès à votre droplet.

L'immagine ha una forma vicina a quelle di AWS e Azure: Ubuntu 24.04, il container pubblicato, fatto girare da systemd, credenziali generate sulla tua istanza al primo avvio. Vale la pena conoscere una differenza: questo droplet fissa il container per tag, mentre l'immagine AWS e il template Azure lo fissano tutti e due per digest. L'unico punto in cui quello che puoi far partire oggi resta indietro rispetto all'immagine AWS è la scrittura di cui sopra. Niente telefona a casa e chi pubblica non ha accesso al tuo droplet.

Das Image ähnelt in der Form denen von AWS und Azure: Ubuntu 24.04, der veröffentlichte Container, von systemd gestartet, Zugangsdaten beim ersten Start auf deiner eigenen Instanz erzeugt. Einen Unterschied sollte man kennen: Dieses Droplet nagelt den Container per Tag fest, während das AWS-Image und das Azure-Template ihn beide per Digest festnageln. Die eine Stelle, an der das, was du heute booten kannst, hinter dem AWS-Image zurückbleibt, ist das Schreiben oben. Nichts funkt nach Hause, und der Herausgeber hat keinen Zugriff auf dein Droplet.

Bentuk image ini mirip dengan image AWS dan Azure: Ubuntu 24.04, container yang dipublikasikan, dijalankan oleh systemd, kredensial dibuat di instance Anda sendiri pada boot pertama. Satu perbedaan perlu Anda ketahui: droplet ini memaku container lewat tag, sedangkan image AWS dan template Azure sama-sama memakunya lewat digest. Satu tempat di mana apa yang bisa Anda boot hari ini tertinggal dari image AWS adalah soal penulisan file di atas. Tidak ada yang menelepon pulang dan penerbitnya tidak punya akses ke droplet Anda.

A imagem é parecida com as da AWS e da Azure no formato: Ubuntu 24.04, o container publicado, rodando por systemd, credenciais geradas na sua própria instância no primeiro boot. Vale conhecer uma diferença: este droplet fixa o container por tag, enquanto tanto a imagem da AWS quanto o template da Azure fixam por digest. O único ponto em que o que você consegue subir hoje fica atrás da imagem da AWS é a escrita descrita acima. Nada manda informação para casa e quem publica não tem acesso ao seu droplet.

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

AWS

Free AMI product on AWS Marketplace, and the most current of the cloud images. More than one version stays selectable in the launch form, so pick the newest deliberately rather than taking whatever the page offers first.

Producto AMI gratuito en AWS Marketplace, y la más al día de las imágenes en la nube. En el formulario de lanzamiento sigue habiendo más de una versión seleccionable, así que elige la más nueva a propósito en vez de quedarte con la que la página ofrezca primero.

AWS Marketplace の無料 AMI 製品で、クラウドのイメージの中でいちばん新しいものです。起動フォームでは複数のバージョンが選べるままなので、ページが先に出してきたものを受け取るのではなく、新しいほうを意識して選んでください。

Бесплатный продукт-AMI в AWS Marketplace и самый свежий из облачных образов. В форме запуска выбираемой остаётся не одна версия, так что выбирайте новейшую сознательно, а не берите то, что страница предложит первым.

AWS Marketplace پر مفت AMI مصنوع، اور کلاؤڈ کی امیجوں میں سب سے تازہ۔ چلانے کے فارم میں ایک سے زیادہ ورژن منتخب ہو سکتے ہیں، سو جو صفحہ پہلے پیش کرے وہ لینے کے بجائے سب سے نیا جان بوجھ کر چنیں۔

AWS Marketplace 上的免费 AMI 产品，也是几个云镜像里最新的一个。启动表单里不止一个版本可以选，所以请刻意去选最新的那个，而不是页面先摆出哪个就用哪个。

AWS Marketplace 上的免費 AMI 產品，也是幾個雲映像檔裡最新的一個。啟動表單裡不只一個版本可以選，所以請刻意去選最新的那個，而不是頁面先擺出哪個就用哪個。

Darmowy produkt AMI na AWS Marketplace i najbardziej aktualny z obrazów chmurowych. W formularzu uruchomienia do wyboru zostaje więcej niż jedna wersja, więc świadomie wskaż najnowszą, zamiast brać to, co strona podsunie pierwsze.

Produit AMI gratuit sur AWS Marketplace, et la plus à jour des images cloud. Plus d'une version reste sélectionnable dans le formulaire de lancement, choisissez donc la plus récente délibérément plutôt que de prendre ce que la page propose en premier.

Prodotto AMI gratuito su AWS Marketplace, e la più aggiornata delle immagini cloud. Nel modulo di avvio resta selezionabile più di una versione, quindi scegli quella più nuova di proposito invece di prendere quella che la pagina ti propone per prima.

Kostenloses AMI-Produkt auf dem AWS Marketplace und das aktuellste der Cloud-Images. Mehr als eine Version bleibt im Startformular auswählbar, wähl also bewusst die neueste, statt zu nehmen, was die Seite zuerst anbietet.

Produk AMI gratis di AWS Marketplace, dan yang paling terkini di antara image cloud. Lebih dari satu versi tetap bisa dipilih di formulir launch, jadi pilih yang paling baru dengan sengaja alih-alih mengambil apa pun yang ditawarkan halaman itu lebih dulu.

Produto AMI gratuito no AWS Marketplace, e a mais atual das imagens de nuvem. Mais de uma versão continua selecionável no formulário de launch, então escolha a mais nova de propósito em vez de aceitar o que a página oferece primeiro.

What it costs

Cuánto cuesta

費用

Сколько это стоит

لاگت کیا ہے

费用是多少

費用是多少

Ile to kosztuje

Ce que cela coûte

Quanto costa

Was es kostet

Berapa biayanya

Quanto custa

Nothing for the software: it is a free AMI-based product, with no metering, no contract and no software charge. AWS still bills you for what it runs on, which is the instance hours, the EBS volume and data transfer out, and anything else you attach to it.

Nada por el software: es un producto gratuito basado en AMI, sin medición, sin contrato y sin cargo de software. AWS te sigue cobrando aquello sobre lo que corre, es decir las horas de instancia, el volumen EBS y la transferencia de datos de salida, más cualquier otra cosa que le conectes.

ソフトウェアの料金はありません。従量計測も契約もソフトウェア課金もない、無料の AMI 製品です。ただし動かす土台の分は AWS に払います。インスタンスの稼働時間、EBS ボリューム、外向きのデータ転送、そして自分で足したものすべてです。

За софт платить не нужно: это бесплатный продукт на базе AMI, без учёта потребления, без контракта и без платы за ПО. AWS по-прежнему выставляет счёт за то, на чём он работает: часы инстанса, том EBS, исходящий трафик и всё, что вы к нему подключите.

سافٹ ویئر کا کچھ نہیں: یہ AMI پر مبنی ایک مفت مصنوع ہے، نہ پیمائش، نہ معاہدہ، نہ سافٹ ویئر کی فیس۔ البتہ جس چیز پر یہ چلتا ہے، اس کا بل AWS پھر بھی بھیجتا ہے: انسٹینس کے گھنٹے، EBS والیوم، باہر جانے والا ڈیٹا، اور جو کچھ آپ اس کے ساتھ جوڑیں۔

软件本身不收钱：这是一个基于 AMI 的免费产品，没有计量、没有合同、没有软件费。但它跑在什么上面，AWS 照样收：实例时长、EBS 卷、出站流量，以及你挂上去的任何别的东西。

軟體本身不收錢：這是一個基於 AMI 的免費產品，沒有計量、沒有合約、沒有軟體費。但它跑在什麼上面，AWS 照樣收：實例時長、EBS 磁碟區、對外流量，以及你掛上去的任何別的東西。

Za samo oprogramowanie nic: to darmowy produkt oparty na AMI, bez licznika, bez umowy i bez opłaty za software. AWS i tak policzy ci to, na czym on działa, czyli godziny instancji, wolumen EBS i transfer wychodzący, oraz wszystko inne, co do niego podepniesz.

Rien pour le logiciel : c'est un produit gratuit à base d'AMI, sans compteur, sans contrat et sans frais logiciels. AWS vous facture quand même ce sur quoi il tourne, c'est-à-dire les heures d'instance, le volume EBS et le trafic sortant, plus tout ce que vous y rattachez.

Niente per il software: è un prodotto gratuito basato su AMI, senza metering, senza contratto e senza addebito software. AWS ti fattura comunque quello su cui gira, cioè le ore di istanza, il volume EBS e il traffico in uscita, più qualsiasi altra cosa tu ci attacchi.

Für die Software nichts: es ist ein kostenloses AMI-Produkt, ohne Abrechnung, ohne Vertrag, ohne Softwaregebühr. AWS berechnet dir weiterhin das, worauf es läuft, also Instanzstunden, das EBS-Volume und ausgehenden Datenverkehr, und alles andere, was du daranhängst.

Tidak ada untuk perangkat lunaknya: ini produk berbasis AMI yang gratis, tanpa metering, tanpa kontrak dan tanpa biaya perangkat lunak. AWS tetap menagih Anda untuk yang menjalankannya, yaitu jam instance, volume EBS dan transfer data keluar, serta apa pun lain yang Anda pasangkan padanya.

Nada pelo software: é um produto gratuito baseado em AMI, sem medição, sem contrato e sem cobrança de software. A AWS continua cobrando pelo que roda embaixo, que são as horas de instância, o volume EBS e a transferência de dados para fora, e qualquer outra coisa que você anexar.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Open the Marketplace listing and subscribe.
2. Launch the AMI with the recommended security group: TCP 3000 and TCP 22, both scoped to your own CIDR.
3. No user data, no IAM role, no AWS credentials. The instance needs none of them.

Finding the generated password. The image boots in strict mode (its first-boot script writes AUTH_BOOTSTRAP=off), so the password is generated once and never regenerated. Clearing the environment file does not produce a new one the way it does on a plain container; it produces a refusal.

Encontrar la contraseña generada. La imagen arranca en modo estricto (su script de primer arranque escribe AUTH_BOOTSTRAP=off), así que la contraseña se genera una vez y no se vuelve a generar. Borrar el archivo de entorno no produce una nueva como ocurre en un contenedor normal; produce un rechazo.

生成されたパスワードを見つける。このイメージは厳格モードで起動します。初回起動スクリプトが AUTH_BOOTSTRAP=off を書くので、パスワードは一度だけ生成され、作り直されることはありません。環境ファイルを消しても、素のコンテナのように新しいものが出てくるわけではなく、拒否が返ってきます。

Как найти сгенерированный пароль. Образ загружается в строгом режиме: его скрипт первой загрузки пишет AUTH_BOOTSTRAP=off, поэтому пароль создаётся один раз и заново не создаётся. Удаление файла окружения не даёт нового пароля, как это бывает на обычном контейнере; оно даёт отказ.

بنایا گیا پاس ورڈ کہاں ملے گا۔ امیج سخت وضع میں چلتی ہے، اس کا پہلی بار چلنے والا اسکرپٹ AUTH_BOOTSTRAP=off لکھتا ہے، سو پاس ورڈ ایک بار بنتا ہے اور دوبارہ نہیں بنتا۔ ماحول کی فائل مٹانے سے نیا پاس ورڈ نہیں ملتا جیسے سادہ کنٹینر میں ملتا ہے؛ انکار ملتا ہے۔

到哪里找生成的密码。这个镜像以严格模式启动，它的首次启动脚本会写入 AUTH_BOOTSTRAP=off，所以密码只生成一次，不会再重新生成。删掉环境文件并不会像在普通容器上那样给你一个新密码；它给你的是一次拒绝。

到哪裡找產生的密碼。這個映像檔以嚴格模式啟動，它的首次啟動腳本會寫入 AUTH_BOOTSTRAP=off，所以密碼只產生一次，不會再重新產生。刪掉環境檔案並不會像在普通容器上那樣給你一個新密碼；它給你的是一次拒絕。

Jak znaleźć wygenerowane hasło. Obraz startuje w trybie ścisłym, ponieważ jego skrypt pierwszego uruchomienia zapisuje AUTH_BOOTSTRAP=off, więc hasło powstaje raz i nigdy nie jest generowane ponownie. Wyczyszczenie pliku środowiskowego nie wyprodukuje nowego, tak jak dzieje się to na gołym kontenerze; wyprodukuje odmowę.

Retrouver le mot de passe généré. L'image démarre en mode strict (son script de premier démarrage écrit AUTH_BOOTSTRAP=off), donc le mot de passe est généré une fois et jamais régénéré. Vider le fichier d'environnement n'en produit pas un nouveau comme sur un simple container ; cela produit un refus.

Trovare la password generata. L'immagine parte in modalità strict (il suo script di primo avvio scrive AUTH_BOOTSTRAP=off), quindi la password viene generata una volta e mai più rigenerata. Svuotare il file di environment non ne produce una nuova come succede su un container semplice; produce un rifiuto.

Das erzeugte Passwort finden. Das Image startet im strikten Modus (sein First-Boot-Skript schreibt AUTH_BOOTSTRAP=off), das Passwort wird also einmal erzeugt und nie wieder neu. Die Umgebungsdatei zu leeren bringt kein neues hervor, wie es bei einem nackten Container der Fall wäre; es bringt eine Verweigerung.

Menemukan password yang dibuatkan. Image ini boot dalam mode ketat (skrip boot pertamanya menulis AUTH_BOOTSTRAP=off), jadi password dibuat sekali dan tidak pernah dibuat ulang. Menghapus file environment tidak menghasilkan password baru seperti pada container biasa; yang dihasilkan adalah penolakan.

Achar a senha gerada. A imagem sobe em modo estrito (o script de primeiro boot escreve AUTH_BOOTSTRAP=off), então a senha é gerada uma vez e nunca mais regerada. Limpar o arquivo de ambiente não produz uma nova como acontece num container puro; produz uma recusa.

First boot takes about a minute and generates a password unique to that instance. There are two ways to read it:

El primer arranque tarda alrededor de un minuto y genera una contraseña única para esa instancia. Hay dos formas de leerla:

初回起動には 1 分ほどかかり、そのインスタンス固有のパスワードが生成されます。読み取る方法は二つあります。

Первая загрузка занимает около минуты и генерирует пароль, уникальный для этого инстанса. Прочитать его можно двумя способами:

پہلی بوٹ میں تقریباً ایک منٹ لگتا ہے اور اُسی انسٹینس کے لیے مخصوص ایک پاس ورڈ بنتا ہے۔ اسے پڑھنے کے دو طریقے ہیں:

首次启动大约需要一分钟，并会生成一个专属于该实例的密码。有两种方式可以读到它：

首次啟動大約需要一分鐘，並會產生一個專屬於該實例的密碼。有兩種方式可以讀到它：

Pierwsze uruchomienie zajmuje jakąś minutę i generuje hasło unikalne dla tej instancji. Są dwa sposoby, żeby je odczytać:

Le premier démarrage prend environ une minute et génère un mot de passe propre à cette instance. Il y a deux façons de le lire :

Il primo avvio richiede circa un minuto e genera una password unica per quell'istanza. Ci sono due modi per leggerla:

Der erste Start dauert etwa eine Minute und erzeugt ein Passwort, das es nur auf dieser Instanz gibt. Es gibt zwei Wege, es zu lesen:

Boot pertama memakan waktu sekitar satu menit dan membuat password yang unik untuk instance itu. Ada dua cara membacanya:

O primeiro boot leva mais ou menos um minuto e gera uma senha única daquela instância. Há duas formas de ler:

• Without an SSH key: EC2 console, Actions, Monitor and troubleshoot, Get system log. The first-boot banner is printed there.
• With SSH: log in as ubuntu and run sudo cat /etc/libredb-studio.info.

Then open http://your-instance-ip:3000 and sign in as admin@libredb.org.

Después abre http://your-instance-ip:3000 y entra como admin@libredb.org.

あとは http://your-instance-ip:3000 を開き、admin@libredb.org でサインインします。

Затем откройте http://your-instance-ip:3000 и войдите как admin@libredb.org.

پھر http://your-instance-ip:3000 کھولیں اور admin@libredb.org کے طور پر سائن اِن کریں۔

然后打开 http://your-instance-ip:3000，以 admin@libredb.org 登录。

然後打開 http://your-instance-ip:3000，以 admin@libredb.org 登入。

Potem otwórz http://your-instance-ip:3000 i zaloguj się jako admin@libredb.org.

Ouvrez ensuite http://your-instance-ip:3000 et connectez-vous en tant que admin@libredb.org.

Poi apri http://your-instance-ip:3000 e accedi come admin@libredb.org.

Dann öffne http://your-instance-ip:3000 und melde dich als admin@libredb.org an.

Lalu buka http://your-instance-ip:3000 dan masuk sebagai admin@libredb.org.

Depois abra http://your-instance-ip:3000 e entre como admin@libredb.org.

Where your data lives

Dónde viven tus datos

データの置き場所

Где живут ваши данные

آپ کا ڈیٹا کہاں رہتا ہے

你的数据存在哪里

你的資料存在哪裡

Gdzie mieszkają twoje dane

Où vivent vos données

Dove vivono i tuoi dati

Wo deine Daten liegen

Di mana data Anda tinggal

Onde ficam os seus dados

Do not rotate JWT_SECRET on a working instance. The key that seals your saved connection secrets is derived from it, so changing it makes every one of them unreadable.

No rotes JWT_SECRET en una instancia que funciona. La clave que sella los secretos de tus conexiones guardadas se deriva de él, así que cambiarlo deja ilegibles todos y cada uno de ellos.

稼働中のインスタンスで JWT_SECRET をローテーションしないでください。保存済み接続の秘密情報を封印する鍵はここから導出されるので、変更するとそのすべてが読めなくなります。

Не проводите ротацию JWT_SECRET на работающем экземпляре. Ключ, запечатывающий секреты сохранённых подключений, выводится из него, поэтому его смена сделает нечитаемыми их все.

چلتے ہوئے انسٹینس پر JWT_SECRET نہ بدلیں۔ آپ کے محفوظ کنکشنوں کے رازوں کو مہربند کرنے والی کلید اسی سے اخذ ہوتی ہے، اس لیے اسے بدلنے پر وہ سب ناقابلِ مطالعہ ہو جاتے ہیں۔

不要在正在运行的实例上轮换 JWT_SECRET。封存你已保存连接机密的那把密钥是由它派生出来的，所以一改，它们就全都读不出来了。

不要在正在執行的實例上輪替 JWT_SECRET。封存你已儲存連線機密的那把金鑰是由它派生出來的，所以一改，它們就全都讀不出來了。

Nie rotuj JWT_SECRET na działającej instancji. Wyprowadzany jest z niego klucz pieczętujący sekrety twoich zapisanych połączeń, więc jego zmiana czyni każde z nich nieczytelnym.

N'effectuez pas de rotation de JWT_SECRET sur une instance qui fonctionne. La clé qui scelle les secrets de vos connexions enregistrées en est dérivée, donc le changer les rend tous illisibles.

Non ruotare JWT_SECRET su un'istanza che funziona. La chiave che sigilla i segreti delle tue connessioni salvate deriva da esso, quindi cambiarlo li rende illeggibili tutti quanti.

Rotiere JWT_SECRET nicht auf einer laufenden Instanz. Der Schlüssel, der deine gespeicherten Verbindungs-Secrets versiegelt, wird daraus abgeleitet. Änderst du ihn, ist jedes einzelne davon unlesbar.

Jangan merotasi JWT_SECRET pada instance yang sedang berjalan. Kunci yang menyegel secret koneksi tersimpan Anda diturunkan darinya, jadi mengubahnya membuat semuanya tidak bisa dibaca.

Não rotacione o JWT_SECRET numa instância que está funcionando. A chave que sela os segredos das suas conexões salvas é derivada dele, então trocá-lo torna todos eles ilegíveis.

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Azure

Solution template on Microsoft Marketplace. HTTPS is a switch in the wizard, on by default.

Plantilla de solución en Microsoft Marketplace. HTTPS es un interruptor del asistente, activado por defecto.

Microsoft Marketplace のソリューションテンプレート。HTTPS はウィザードのスイッチで、既定では入っています。

Шаблон решения в Microsoft Marketplace. В мастере HTTPS представлен переключателем, по умолчанию включённым.

Microsoft Marketplace پر سلوشن ٹیمپلیٹ۔ HTTPS سہولت کار میں ایک سوئچ ہے، جو طے شدہ طور پر آن ہے۔

Microsoft Marketplace 上的解决方案模板。HTTPS 是向导里的一个开关，默认打开。

Microsoft Marketplace 上的解決方案範本。HTTPS 是精靈裡的一個開關，預設打開。

Szablon rozwiązania na Microsoft Marketplace. HTTPS to przełącznik w kreatorze, domyślnie włączony.

Solution template sur Microsoft Marketplace. HTTPS est une case de l'assistant, activée par défaut.

Solution template su Microsoft Marketplace. L'HTTPS è un interruttore nella procedura guidata, attivo di default.

Solution Template auf dem Microsoft Marketplace. HTTPS ist ein Schalter im Assistenten, standardmäßig an.

Solution template di Microsoft Marketplace. HTTPS adalah sebuah sakelar di wizard, menyala secara default.

Solution template no Microsoft Marketplace. HTTPS é um botão no assistente, ligado por padrão.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Open the Marketplace listing and press Get It Now.
2. Work through the Azure portal wizard. It asks for a resource group, a region, a VM name and size, an OS disk size, your administrator details, a DNS name label, and whether to enable HTTPS with a free certificate. Two of its fields decide who can reach the machine at all, and they are easy to skim past: the allowed source for the web interface, and the allowed source for SSH.
3. Deploy and wait for the template to finish.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

The template deploys one Ubuntu 24.04 LTS VM running the container behind a Caddy reverse proxy with automatic HTTPS. That is the one difference worth knowing about compared with the other cloud images: because Caddy terminates TLS for you, you reach the app at https:// and the cookie trap does not apply. Leave AUTH_COOKIE_SECURE alone here.

La plantilla despliega una máquina virtual Ubuntu 24.04 LTS que ejecuta el contenedor detrás de un proxy inverso Caddy con HTTPS automático. Esa es la única diferencia que merece la pena conocer frente a las otras imágenes de nube: como Caddy termina el TLS por ti, llegas a la aplicación por https:// y la trampa de la cookie no aplica. Aquí no toques AUTH_COOKIE_SECURE.

テンプレートは Ubuntu 24.04 LTS の VM を 1 台デプロイし、Caddy リバースプロキシの背後でコンテナを動かして HTTPS を自動化します。ほかのクラウドイメージと比べて知っておく価値のある違いはここだけです。Caddy が TLS を終端してくれるので https:// でアプリに到達でき、Cookie の落とし穴は当てはまりません。ここでは AUTH_COOKIE_SECURE に触らないでください。

Шаблон разворачивает одну виртуальную машину Ubuntu 24.04 LTS, где контейнер работает за обратным прокси Caddy с автоматическим HTTPS. Это единственное отличие от остальных облачных образов, о котором стоит знать: раз Caddy терминирует TLS за вас, вы попадаете в приложение по https://, и ловушка с куками здесь неприменима. AUTH_COOKIE_SECURE тут не трогайте.

ٹیمپلیٹ ایک Ubuntu 24.04 LTS VM ڈپلائے کرتا ہے جس پر کنٹینر ایک Caddy ریورس پراکسی کے پیچھے خودکار HTTPS کے ساتھ چلتا ہے۔ دوسری کلاؤڈ امیجوں کے مقابلے میں جاننے کے قابل فرق بس یہی ہے: چونکہ Caddy آپ کے لیے TLS ختم کر دیتا ہے، آپ ایپ تک https:// پر پہنچتے ہیں اور کوکی والا پھندا یہاں لاگو نہیں ہوتا۔ یہاں AUTH_COOKIE_SECURE کو ہاتھ نہ لگائیں۔

模板会部署一台 Ubuntu 24.04 LTS 虚拟机，容器跑在 Caddy 反向代理后面，自动启用 HTTPS。这是它和其他云镜像相比唯一值得知道的差别：既然 Caddy 替你终结了 TLS，你就用 https:// 访问应用，那个 Cookie 陷阱在这里不适用。这里不要去动 AUTH_COOKIE_SECURE。

範本會部署一台 Ubuntu 24.04 LTS 虛擬機器，容器跑在 Caddy 反向代理後面，自動啟用 HTTPS。這是它和其他雲映像檔相比唯一值得知道的差別：既然 Caddy 替你終結了 TLS，你就用 https:// 存取應用，那個 Cookie 陷阱在這裡不適用。這裡不要去動 AUTH_COOKIE_SECURE。

Szablon wdraża jedną maszynę wirtualną z Ubuntu 24.04 LTS, na której kontener stoi za reverse proxy Caddy z automatycznym HTTPS. To jedyna różnica warta uwagi w porównaniu z pozostałymi obrazami chmurowymi: skoro Caddy terminuje TLS za ciebie, aplikację otwierasz pod https:// i pułapka z ciasteczkiem tu nie działa. Zostaw tutaj AUTH_COOKIE_SECURE w spokoju.

Le template déploie une VM Ubuntu 24.04 LTS qui fait tourner le container derrière un reverse proxy Caddy avec HTTPS automatique. C'est la seule différence qui mérite d'être connue par rapport aux autres images cloud : comme Caddy termine le TLS pour vous, vous atteignez l'application en https:// et le piège du cookie ne s'applique pas. Ne touchez pas à AUTH_COOKIE_SECURE ici.

Il template distribuisce una VM Ubuntu 24.04 LTS che fa girare il container dietro un reverse proxy Caddy con HTTPS automatico. È l'unica differenza che vale la pena conoscere rispetto alle altre immagini cloud: siccome è Caddy a terminare il TLS per te, raggiungi l'app su https:// e la trappola del cookie non si applica. Qui lascia stare AUTH_COOKIE_SECURE.

Das Template stellt eine Ubuntu-24.04-LTS-VM bereit, auf der der Container hinter einem Caddy-Reverse-Proxy mit automatischem HTTPS läuft. Das ist der eine Unterschied zu den anderen Cloud-Images, den du kennen solltest: weil Caddy TLS für dich terminiert, erreichst du die App unter https:// und die Cookie-Falle greift nicht. Lass AUTH_COOKIE_SECURE hier in Ruhe.

Template ini men-deploy satu VM Ubuntu 24.04 LTS yang menjalankan container di belakang reverse proxy Caddy dengan HTTPS otomatis. Itulah satu perbedaan yang layak diketahui dibanding image cloud lainnya: karena Caddy yang menerminasi TLS untuk Anda, Anda menjangkau aplikasi di https:// dan jebakan cookie tidak berlaku. Biarkan AUTH_COOKIE_SECURE apa adanya di sini.

O template faz deploy de uma VM Ubuntu 24.04 LTS rodando o container atrás de um proxy reverso Caddy com HTTPS automático. Essa é a única diferença que vale conhecer em relação às outras imagens de nuvem: como o Caddy termina o TLS para você, você acessa o app em https:// e a armadilha do cookie não se aplica. Deixe AUTH_COOKIE_SECURE quieto aqui.

The deployment outputs in the portal give you the address to open. Sign in with the application administrator email and password you typed in the wizard, which are a separate pair from the VM's own administrator login you use for SSH.

Las salidas del despliegue en el portal te dan la dirección que hay que abrir. Entra con el correo y la contraseña del administrador de la aplicación que escribiste en el asistente, que son un par distinto del inicio de sesión del administrador de la propia VM que usas para SSH.

ポータルのデプロイ出力に、開くべきアドレスが出ます。ログインにはウィザードで入力したアプリケーション管理者のメールアドレスとパスワードを使います。これは SSH に使う VM 自身の管理者ログインとは別のものです。

Выходные данные развёртывания в портале дают адрес, который надо открыть. Входите по почте и паролю администратора приложения, которые вы ввели в мастере: это отдельная пара, не тот администратор самой виртуальной машины, под которым вы заходите по SSH.

پورٹل میں تعیناتی کے نتائج آپ کو وہ پتہ دیتے ہیں جو کھولنا ہے۔ اُسی ای میل اور پاس ورڈ سے داخل ہوں جو آپ نے سہولت کار میں ایپلیکیشن کے منتظم کے لیے لکھے تھے؛ یہ اُس ورچوئل مشین کے اپنے منتظم لاگ اِن سے الگ جوڑا ہے جسے آپ SSH کے لیے استعمال کرتے ہیں۔

门户里的部署输出会给你要打开的地址。用你在向导里填的应用管理员邮箱和密码登录，它和你用来 SSH 的那台虚拟机自身的管理员账号是两回事。

入口裡的部署輸出會給你要打開的位址。用你在精靈裡填的應用管理員電子郵件和密碼登入，它和你用來 SSH 的那台虛擬機器自身的管理員帳號是兩回事。

Adres do otwarcia dostajesz w wyjściach wdrożenia w portalu. Zaloguj się e-mailem i hasłem administratora aplikacji, które wpisałeś w kreatorze, to inna para niż własny login administratora maszyny wirtualnej, którego używasz do SSH.

Les sorties du déploiement dans le portail vous donnent l'adresse à ouvrir. Connectez-vous avec l'e-mail et le mot de passe d'administrateur de l'application que vous avez saisis dans l'assistant, qui forment une paire distincte de l'identifiant d'administrateur de la VM que vous utilisez pour SSH.

Gli output del deployment nel portale ti danno l'indirizzo da aprire. Accedi con l'email e la password dell'amministratore dell'applicazione che hai digitato nella procedura guidata, che sono una coppia distinta dal login di amministratore della VM stessa, quello che usi per SSH.

Die Deployment-Ausgaben im Portal nennen dir die Adresse zum Öffnen. Melde dich mit der E-Mail-Adresse und dem Passwort des Anwendungsadministrators an, die du im Assistenten eingetippt hast. Das ist ein anderes Paar als der Administrator-Login der VM selbst, den du für SSH nimmst.

Output deployment di portal memberi Anda alamat untuk dibuka. Masuk dengan email dan password administrator aplikasi yang Anda ketik di wizard, yang merupakan pasangan terpisah dari login administrator VM itu sendiri yang Anda pakai untuk SSH.

As saídas do deployment no portal te dão o endereço para abrir. Entre com o e-mail e a senha de administrador da aplicação que você digitou no assistente, que são um par separado do login de administrador da própria VM que você usa para SSH.

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Google Cloud

Kubernetes app in the Marketplace catalog.

Aplicación de Kubernetes en el catálogo del Marketplace.

Marketplace カタログの Kubernetes アプリ。

Приложение Kubernetes в каталоге Marketplace.

Marketplace کیٹلاگ میں Kubernetes ایپ۔

Marketplace 目录中的 Kubernetes 应用。

Marketplace 目錄中的 Kubernetes 應用。

Aplikacja Kubernetes w katalogu Marketplace.

Application Kubernetes dans le catalogue Marketplace.

App Kubernetes nel catalogo Marketplace.

Kubernetes-App im Marketplace-Katalog.

Aplikasi Kubernetes di katalog Marketplace.

App Kubernetes no catálogo do Marketplace.

What you need

Qué necesitas

必要なもの

Что нужно

آپ کو کیا درکار ہے

你需要什么

你需要什麼

Czego potrzebujesz

Ce qu'il vous faut

Cosa ti serve

Was du brauchst

Yang Anda perlukan

O que você precisa

This channel deploys into Kubernetes rather than onto a VM, so you need an existing GKE cluster and the Kubernetes Engine Admin role on the target project. It is not the only Kubernetes route: the public Helm chart and the Rancher partner catalogue reach a cluster too, and the Helm block below is the same application by a shorter path.

Este canal despliega en Kubernetes en lugar de en una VM, así que necesitas un clúster GKE existente y el rol Kubernetes Engine Admin en el proyecto de destino. No es la única vía a Kubernetes: el chart público de Helm y el catálogo de partners de Rancher también llegan a un clúster, y el bloque de Helm de más abajo es la misma aplicación por un camino más corto.

このチャネルは VM ではなく Kubernetes に配置します。そのため既存の GKE クラスターと、対象プロジェクトでの Kubernetes Engine Admin ロールが必要です。Kubernetes への道はこれだけではありません。公開されている Helm チャートと Rancher のパートナーカタログも同じクラスターに届きますし、下の Helm のブロックは同じアプリを短い手順で入れるものです。

Этот канал разворачивает приложение в Kubernetes, а не на виртуальной машине, поэтому нужен готовый кластер GKE и роль Kubernetes Engine Admin в целевом проекте. Это не единственный путь в Kubernetes: публичный чарт Helm и партнёрский каталог Rancher тоже доходят до кластера, а блок Helm ниже представляет то же самое приложение, но короче.

یہ چینل ایپ کو ورچوئل مشین کے بجائے Kubernetes پر تعینات کرتا ہے، سو آپ کو ایک موجودہ GKE کلسٹر اور ہدف پروجیکٹ پر Kubernetes Engine Admin کا کردار درکار ہے۔ Kubernetes تک پہنچنے کا یہی واحد راستہ نہیں: عوامی Helm چارٹ اور Rancher کا پارٹنر کیٹلاگ بھی کلسٹر تک پہنچتے ہیں، اور نیچے والا Helm کا حصہ وہی ایپ ہے، بس مختصر راستے سے۔

这个渠道把应用部署进 Kubernetes，而不是装到虚拟机上，所以你需要一个现成的 GKE 集群，以及目标项目上的 Kubernetes Engine Admin 角色。这不是通往 Kubernetes 的唯一路：公开的 Helm chart 和 Rancher 合作伙伴目录同样能落到集群里，下面那段 Helm 就是同一个应用，只是路更短。

這個通道把應用部署進 Kubernetes，而不是裝到虛擬機器上，所以你需要一個現成的 GKE 叢集，以及目標專案上的 Kubernetes Engine Admin 角色。這不是通往 Kubernetes 的唯一路：公開的 Helm chart 和 Rancher 合作夥伴目錄同樣能落到叢集裡，下面那段 Helm 就是同一個應用，只是路更短。

Ten kanał wdraża do Kubernetesa, a nie na maszynę wirtualną, więc potrzebujesz istniejącego klastra GKE i roli Kubernetes Engine Admin w docelowym projekcie. To nie jedyna droga przez Kubernetesa: publiczny chart Helma i katalog partnerski Rancher też docierają do klastra, a blok o Helmie niżej to ta sama aplikacja krótszą drogą.

Ce canal déploie dans Kubernetes plutôt que sur une VM, il vous faut donc un cluster GKE existant et le rôle Kubernetes Engine Admin sur le projet cible. Ce n'est pas la seule voie Kubernetes : le chart Helm public et le catalogue partenaire Rancher atteignent eux aussi un cluster, et le bloc Helm ci-dessous est la même application par un chemin plus court.

Questo canale distribuisce su Kubernetes e non su una VM, quindi ti serve un cluster GKE esistente e il ruolo Kubernetes Engine Admin sul progetto di destinazione. Non è l'unica strada Kubernetes: anche il chart Helm pubblico e il catalogo partner di Rancher arrivano a un cluster, e il blocco Helm qui sotto è la stessa applicazione per una via più breve.

Dieser Kanal deployt nach Kubernetes statt auf eine VM, du brauchst also einen vorhandenen GKE-Cluster und die Rolle Kubernetes Engine Admin im Zielprojekt. Es ist nicht der einzige Kubernetes-Weg: das öffentliche Helm-Chart und der Rancher-Partnerkatalog erreichen einen Cluster ebenfalls, und der Helm-Block weiter unten ist dieselbe Anwendung auf kürzerem Weg.

Kanal ini men-deploy ke Kubernetes, bukan ke sebuah VM, jadi Anda perlu cluster GKE yang sudah ada dan role Kubernetes Engine Admin di project tujuan. Ini bukan satu-satunya jalur Kubernetes: chart Helm publik dan katalog partner Rancher juga sampai ke cluster, dan blok Helm di bawah adalah aplikasi yang sama lewat jalan yang lebih pendek.

Este canal faz deploy dentro do Kubernetes e não numa VM, então você precisa de um cluster GKE existente e da role Kubernetes Engine Admin no projeto de destino. Não é a única rota de Kubernetes: o chart Helm público e o catálogo de parceiros da Rancher também chegam a um cluster, e o bloco de Helm abaixo é a mesma aplicação por um caminho mais curto.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Open the Marketplace catalog inside the Google Cloud console and search for LibreDB Studio.
2. Press Configure, choose the target cluster and namespace.
3. Deploy, then follow the post-deploy instructions Google shows to reach the service.

If you would rather use Helm directly

Si prefieres usar Helm directamente

Helm を直接使いたい場合

Если вы предпочитаете Helm напрямую

اگر آپ براہِ راست Helm استعمال کرنا چاہیں

如果你更想直接用 Helm

如果你更想直接用 Helm

Jeśli wolisz użyć Helma bezpośrednio

Si vous préférez passer directement par Helm

Se preferisci usare Helm direttamente

Wenn du lieber direkt Helm nimmst

Kalau Anda lebih suka memakai Helm langsung

Se você preferir usar o Helm direto

The public chart is not the Marketplace one, but it installs the same application: chart 0.1.67 carries app version 0.17.0. Three of its values are worth knowing, all defaulting to empty, so a values file that sets none of them changes nothing. secrets.adminTotpSecret and secrets.userTotpSecret turn on the second factor for an account. config.basePath prefixes the health probes. Read that last one carefully before planning around it, because the subpath itself is fixed when the image is built and the published image is built at the root. The chart exposes no ingress by default, so the last line is how you reach it while you look around:

El chart público no es el de Marketplace, pero instala la misma aplicación: el chart 0.1.67 lleva la versión de app 0.17.0. Merece la pena conocer tres de sus valores; los tres vienen vacíos por defecto, así que un archivo de valores que no fije ninguno no cambia nada. secrets.adminTotpSecret y secrets.userTotpSecret activan el segundo factor de una cuenta. config.basePath prefija las sondas de salud. Lee bien este último antes de planificar en torno a él, porque la subruta en sí se fija al construir la imagen, y la imagen publicada se construye en la raíz. El chart no expone ingress por defecto, así que la última línea es cómo llegar a él mientras miras:

公開チャートは Marketplace のものではありませんが、入るアプリケーションは同じです。チャート 0.1.67 はアプリ版 0.17.0 を運びます。知っておく価値のある値が三つあり、いずれも既定は空なので、どれも設定しない values ファイルは何も変えません。secrets.adminTotpSecret と secrets.userTotpSecret はアカウントの第二要素を有効にします。config.basePath はヘルスプローブに接頭辞を付けます。最後のものは計画に組み込む前によく読んでください。サブパス自体はイメージのビルド時に固定され、公開イメージはルートでビルドされているからです。チャートは既定で ingress を公開しないので、見て回るあいだの到達手段が最後の行です。

Публичный чарт не тот, что в Marketplace, но ставит он то же приложение: чарт 0.1.67 несёт версию приложения 0.17.0. Три его значения стоит знать, все по умолчанию пусты, так что файл значений, не задающий ни одного, ничего не меняет. secrets.adminTotpSecret и secrets.userTotpSecret включают второй фактор для учётной записи. config.basePath добавляет префикс к пробам состояния. Последнее прочитайте внимательно, прежде чем строить на нём планы: сам подпуть фиксируется при сборке образа, а опубликованный образ собран в корне. Чарт по умолчанию не выставляет ingress, поэтому последняя строка служит способом дотянуться до него, пока вы осматриваетесь:

عوامی چارٹ Marketplace والا نہیں، مگر ایپلی کیشن وہی نصب کرتا ہے: چارٹ 0.1.67 ایپ ورژن 0.17.0 لاتا ہے۔ اس کی تین اقدار جاننے کے لائق ہیں، تینوں طے شدہ طور پر خالی، سو ایسی ویلیوز فائل جو ان میں سے کوئی مقرر نہ کرے کچھ نہیں بدلتی۔ secrets.adminTotpSecret اور secrets.userTotpSecret کسی اکاؤنٹ کے لیے دوسرا عنصر چالو کرتے ہیں۔ config.basePath ہیلتھ پروب کو سابقہ لگاتا ہے۔ آخری والے کو منصوبہ بنانے سے پہلے غور سے پڑھیں، کیونکہ ذیلی راستہ خود امیج بناتے وقت طے ہوتا ہے اور شائع شدہ امیج جڑ پر بنی ہے۔ چارٹ طے شدہ طور پر کوئی ingress نہیں کھولتا، سو دیکھنے بھالنے کے دوران پہنچنے کا طریقہ آخری سطر ہے:

公开的 chart 不是 Marketplace 那一份，但装的是同一个应用：chart 0.1.67 带的是应用版本 0.17.0。其中三个值值得知道，默认都是空的，所以一份一个都不设的 values 文件什么也不会改变。secrets.adminTotpSecret 和 secrets.userTotpSecret 为某个账号打开第二因素。config.basePath 给健康探针加前缀。最后这个在围绕它做计划前要读仔细：子路径本身是在构建镜像时定死的，而发布的镜像是按根路径构建的。chart 默认不开放 ingress，所以最后一行是你四处看看时访问它的办法：

公開的 chart 不是 Marketplace 那一份，但裝的是同一個應用：chart 0.1.67 帶的是應用版本 0.17.0。其中三個值值得知道，預設都是空的，所以一份一個都不設的 values 檔案什麼也不會改變。secrets.adminTotpSecret 和 secrets.userTotpSecret 為某個帳號打開第二因素。config.basePath 給健康探測加前綴。最後這個在圍繞它做計畫前要讀仔細：子路徑本身是在建置映像檔時定死的，而發布的映像檔是按根路徑建置的。chart 預設不開放 ingress，所以最後一行是你四處看看時存取它的辦法：

Publiczny chart to nie ten z Marketplace, ale instaluje tę samą aplikację: chart 0.1.67 niesie wersję aplikacji 0.17.0. Trzy jego wartości warto znać, wszystkie domyślnie puste, więc plik values, który nie ustawia żadnej z nich, niczego nie zmienia. secrets.adminTotpSecret i secrets.userTotpSecret włączają drugi składnik uwierzytelniania dla konta. config.basePath dokleja prefiks do sond zdrowia. Tę ostatnią przeczytaj uważnie, zanim coś na niej oprzesz, bo sam podkatalog jest ustalany przy budowaniu obrazu, a opublikowany obraz jest zbudowany na roocie. Chart domyślnie nie wystawia żadnego ingressu, więc ostatnia linia to sposób na dotarcie do niego, kiedy się rozglądasz:

Le chart public n'est pas celui de la Marketplace, mais il installe la même application : le chart 0.1.67 porte la version applicative 0.17.0. Trois de ses valeurs méritent d'être connues, toutes vides par défaut, si bien qu'un fichier de valeurs qui n'en définit aucune ne change rien. secrets.adminTotpSecret et secrets.userTotpSecret activent le second facteur pour un compte. config.basePath préfixe les sondes de santé. Lisez cette dernière attentivement avant de bâtir dessus, parce que le sous-chemin lui-même est figé à la construction de l'image et que l'image publiée est construite à la racine. Le chart n'expose aucun ingress par défaut, donc la dernière ligne est la façon de l'atteindre pendant que vous regardez :

Il chart pubblico non è quello del Marketplace, ma installa la stessa applicazione: il chart 0.1.67 porta la versione applicativa 0.17.0. Tre dei suoi valori vale la pena conoscerli, tutti vuoti di default, quindi un values file che non ne imposta nessuno non cambia niente. secrets.adminTotpSecret e secrets.userTotpSecret attivano il secondo fattore per un account. config.basePath antepone un prefisso alle health probe. Leggi quest'ultimo con attenzione prima di farci dei piani sopra, perché il subpath in sé è fissato quando l'immagine viene costruita e l'immagine pubblicata è costruita sulla radice. Il chart di default non espone nessun ingress, quindi l'ultima riga è il modo in cui lo raggiungi mentre ti guardi intorno:

Das öffentliche Chart ist nicht das aus dem Marketplace, es installiert aber dieselbe Anwendung: Chart 0.1.67 führt App-Version 0.17.0. Drei seiner Werte solltest du kennen, alle stehen standardmäßig leer, eine Values-Datei, die keinen davon setzt, ändert also nichts. secrets.adminTotpSecret und secrets.userTotpSecret schalten den zweiten Faktor für ein Konto ein. config.basePath stellt den Health-Probes ein Präfix voran. Lies den letzten genau, bevor du darum herum planst, denn der Subpfad selbst wird beim Bauen des Images festgelegt, und das veröffentlichte Image ist auf der Wurzel gebaut. Das Chart legt standardmäßig keinen Ingress an, die letzte Zeile ist also der Weg, um beim Umsehen dranzukommen:

Chart publik bukan chart Marketplace, tetapi ia memasang aplikasi yang sama: chart 0.1.67 membawa versi aplikasi 0.17.0. Tiga nilainya layak diketahui, semuanya default kosong, jadi values file yang tidak men-set satu pun tidak mengubah apa pun. secrets.adminTotpSecret dan secrets.userTotpSecret menyalakan faktor kedua untuk sebuah akun. config.basePath memberi awalan pada probe health. Baca yang terakhir itu dengan teliti sebelum menyusun rencana di sekitarnya, karena subpath-nya sendiri sudah tetap saat image dibangun dan image yang dipublikasikan dibangun di root. Chart ini tidak mengekspos ingress secara default, jadi baris terakhir adalah cara Anda menjangkaunya sambil melihat-lihat:

O chart público não é o do Marketplace, mas instala a mesma aplicação: o chart 0.1.67 carrega a versão de app 0.17.0. Três dos valores dele valem conhecer, todos com padrão vazio, então um values file que não define nenhum deles não muda nada. secrets.adminTotpSecret e secrets.userTotpSecret ligam o segundo fator de uma conta. config.basePath prefixa os probes de health. Leia esse último com atenção antes de planejar em cima dele, porque o subpath em si é fixado quando a imagem é construída e a imagem publicada é construída na raiz. O chart não expõe ingress por padrão, então a última linha é como você alcança enquanto dá uma olhada:

helm repo add libredb https://libredb.org/libredb-studio/
helm repo update
helm search repo libredb/libredb-studio   # chart and app version
helm install libredb libredb/libredb-studio

# the generated admin credentials
kubectl logs deployment/libredb-libredb-studio | grep -A 4 "generated admin credentials"

# the chart exposes no ingress by default, so reach it with a port-forward
kubectl port-forward deployment/libredb-libredb-studio 3000:3000

The chart exposes the cookie switch as config.authCookieSecure and leaves it unset, so the application decides: Secure in production. A chart install usually sits behind an ingress terminating TLS, which is why unset is the right default. Set it to false only if you are reaching the service over plain HTTP.

El chart expone el interruptor de la cookie como config.authCookieSecure y lo deja sin definir, así que decide la aplicación: Secure en producción. Una instalación por chart suele estar detrás de un ingress que termina el TLS, y por eso sin definir es el valor correcto. Ponlo en false solo si vas a llegar al servicio por HTTP plano.

チャートは Cookie のスイッチを config.authCookieSecure として公開しますが、未設定のままにします。判断はアプリに委ねられ、本番では Secure が付きます。チャートでのインストールは通常、TLS を終端する ingress の背後に置かれるので、未設定が正しい既定です。平文 HTTP でサービスに到達する場合だけ false にしてください。

Чарт выставляет переключатель куки как config.authCookieSecure, но оставляет его незаданным, так что решение принимает само приложение: в продакшене Secure. Установка через чарт обычно стоит за ingress, терминирующим TLS, поэтому незаданное значение здесь и есть правильное. Ставьте false только если попадаете в сервис по обычному HTTP.

چارٹ کوکی والے سوئچ کو config.authCookieSecure کے طور پر پیش کرتا ہے مگر اسے غیر مقرر چھوڑ دیتا ہے، یعنی فیصلہ ایپ کرتی ہے: پروڈکشن میں Secure۔ چارٹ سے کی گئی تنصیب عموماً TLS ختم کرنے والے ingress کے پیچھے ہوتی ہے، اسی لیے غیر مقرر ہی درست طے شدہ قدر ہے۔ اسے false صرف اُس صورت میں کریں جب آپ سروس تک سادہ HTTP پر پہنچ رہے ہوں۔

这个 chart 把 Cookie 开关暴露为 config.authCookieSecure，但保持不设置，由应用自己决定：生产环境下带 Secure。通过 chart 安装通常都放在终结 TLS 的 ingress 后面，所以不设置才是正确的默认。只有当你通过明文 HTTP 访问服务时才把它设为 false。

這個 chart 把 Cookie 開關暴露為 config.authCookieSecure，但保持不設定，由應用自己決定：生產環境下帶 Secure。透過 chart 安裝通常都放在終結 TLS 的 ingress 後面，所以不設定才是正確的預設。只有當你透過明文 HTTP 存取服務時才把它設為 false。

Chart wystawia przełącznik ciasteczka jako config.authCookieSecure i zostawia go nieustawionym, więc decyduje aplikacja: Secure na produkcji. Instalacja z chartu zwykle siedzi za ingressem terminującym TLS i dlatego brak ustawienia jest tu właściwą wartością domyślną. Ustaw go na false tylko wtedy, gdy sięgasz do usługi po zwykłym HTTP.

Le chart expose le commutateur de cookie sous config.authCookieSecure et le laisse non défini, donc c'est l'application qui décide : Secure en production. Une installation par chart se trouve d'ordinaire derrière un ingress qui termine le TLS, ce qui explique que non défini soit la bonne valeur par défaut. Ne le mettez à false que si vous atteignez le service en HTTP simple.

Il chart espone l'interruttore del cookie come config.authCookieSecure e lo lascia non impostato, quindi decide l'applicazione: Secure in produzione. Un'installazione via chart di solito sta dietro un ingress che termina il TLS, ed è per questo che lasciarlo non impostato è il default giusto. Mettilo a false solo se raggiungi il servizio in HTTP semplice.

Das Chart bietet den Cookie-Schalter als config.authCookieSecure an und lässt ihn ungesetzt, die Anwendung entscheidet also: Secure in der Produktion. Eine Chart-Installation sitzt meist hinter einem Ingress, der TLS terminiert, deshalb ist ungesetzt die richtige Voreinstellung. Setz ihn nur dann auf false, wenn du den Dienst über einfaches HTTP erreichst.

Chart mengekspos sakelar cookie sebagai config.authCookieSecure dan membiarkannya tidak diset, jadi aplikasilah yang memutuskan: Secure di produksi. Instalasi chart biasanya berada di belakang ingress yang menerminasi TLS, dan itulah sebabnya tidak diset adalah default yang benar. Set ke false hanya kalau Anda menjangkau service-nya lewat HTTP biasa.

O chart expõe o botão do cookie como config.authCookieSecure e deixa sem valor, então a aplicação decide: Secure em produção. Uma instalação por chart geralmente fica atrás de um ingress terminando TLS, e é por isso que sem valor é o padrão certo. Ponha em false só se você for acessar o serviço por HTTP puro.

The chart the project publishes. Chart 0.1.67 carries application version 0.17.0.

El chart que publica el proyecto. El chart 0.1.67 lleva la versión 0.17.0 de la aplicación.

プロジェクトが公開しているチャート。チャート 0.1.67 がアプリのバージョン 0.17.0 を運びます。

Чарт, который публикует проект. Чарт 0.1.67 несёт версию приложения 0.17.0.

وہ چارٹ جو منصوبہ شائع کرتا ہے۔ چارٹ 0.1.67 ایپ کا ورژن 0.17.0 لاتا ہے۔

项目自己发布的 chart。chart 0.1.67 带的应用版本是 0.17.0。

專案自己發布的 chart。chart 0.1.67 帶的應用版本是 0.17.0。

Chart publikowany przez projekt. Chart 0.1.67 niesie wersję aplikacji 0.17.0.

Le chart que publie le projet. Le chart 0.1.67 porte la version applicative 0.17.0.

Il chart che il progetto pubblica. Il chart 0.1.67 porta la versione applicativa 0.17.0.

Das Chart, das das Projekt veröffentlicht. Chart 0.1.67 führt Anwendungsversion 0.17.0.

Chart yang dipublikasikan proyek ini. Chart 0.1.67 membawa versi aplikasi 0.17.0.

O chart que o projeto publica. O chart 0.1.67 carrega a versão 0.17.0 da aplicação.

Install and reach it

Instalar y llegar a ello

導入して到達する

Установить и добраться

نصب کریں اور پہنچیں

安装并访问

安裝並存取

Instalacja i dostęp

Installer et l'atteindre

Installalo e raggiungilo

Installieren und erreichen

Pasang dan jangkau

Instalar e alcançar

helm repo add libredb https://libredb.org/libredb-studio/
helm repo update
helm search repo libredb/libredb-studio   # chart and app version
helm install libredb libredb/libredb-studio

# the generated admin credentials
kubectl logs deployment/libredb-libredb-studio | grep -A 4 "generated admin credentials"

# the chart exposes no ingress by default, so reach it with a port-forward
kubectl port-forward deployment/libredb-libredb-studio 3000:3000

Three values worth knowing

Tres valores que conviene conocer

知っておく価値のある三つの値

Три значения, которые стоит знать

تین اقدار جو جاننے کے لائق ہیں

三个值得知道的值

三個值得知道的值

Trzy wartości warte poznania

Trois valeurs qui méritent d'être connues

Tre valori che vale la pena conoscere

Drei Werte, die du kennen solltest

Tiga nilai yang layak diketahui

Três valores que vale conhecer

secrets.adminTotpSecret and secrets.userTotpSecret turn on the second factor for an account. config.basePath reads as though it moves the application to a subpath. It does not: it prefixes the health probes only. The subpath itself is fixed when the image is built, and the published image is built at the root, so a chart install with that value set stays at the root while its probes still pass. All three default to empty, so a values file that sets none of them changes nothing.

secrets.adminTotpSecret y secrets.userTotpSecret activan el segundo factor de una cuenta. config.basePath se lee como si moviera la aplicación a una subruta. No lo hace: solo prefija las sondas de salud. La subruta en sí se fija al construir la imagen, y la imagen publicada se construye en la raíz, así que una instalación del chart con ese valor puesto se queda en la raíz mientras sus sondas siguen pasando. Los tres vienen vacíos por defecto, así que un archivo de valores que no fije ninguno no cambia nada.

secrets.adminTotpSecret と secrets.userTotpSecret はアカウントの第二要素を有効にします。config.basePath は、アプリケーションをサブパスへ移すかのように読めます。そうではありません。ヘルスプローブに接頭辞を付けるだけです。サブパス自体はイメージのビルド時に固定され、公開イメージはルートでビルドされているので、この値を設定してチャートを入れてもアプリはルートのままで、プローブは通り続けます。三つとも既定は空なので、どれも設定しない values ファイルは何も変えません。

secrets.adminTotpSecret и secrets.userTotpSecret включают второй фактор для учётной записи. config.basePath читается так, будто переносит приложение на подпуть. Это не так: он добавляет префикс только к пробам состояния. Сам подпуть фиксируется при сборке образа, а опубликованный образ собран в корне, так что установка чарта с этим значением остаётся в корне, а пробы всё равно проходят. Все три по умолчанию пусты, так что файл значений, не задающий ни одного, ничего не меняет.

secrets.adminTotpSecret اور secrets.userTotpSecret کسی اکاؤنٹ کے لیے دوسرا عنصر چالو کرتے ہیں۔ config.basePath پڑھنے میں ایسا لگتا ہے جیسے یہ ایپلی کیشن کو کسی ذیلی راستے پر لے جاتا ہو۔ ایسا نہیں ہے: یہ صرف ہیلتھ پروب کو سابقہ لگاتا ہے۔ ذیلی راستہ خود امیج بناتے وقت طے ہوتا ہے، اور شائع شدہ امیج جڑ پر بنی ہے، سو یہ قدر مقرر کر کے چارٹ نصب کرنے پر بھی ایپ جڑ ہی پر رہتی ہے اور اس کی پروب پھر بھی کامیاب رہتی ہیں۔ تینوں طے شدہ طور پر خالی ہیں، سو ایسی ویلیوز فائل جو ان میں سے کوئی مقرر نہ کرے کچھ نہیں بدلتی۔

secrets.adminTotpSecret 和 secrets.userTotpSecret 为某个账号打开第二因素。config.basePath 读起来像是把应用挪到子路径下。它不会：它只给健康探针加前缀。子路径本身是在构建镜像时定死的，而发布的镜像是按根路径构建的，所以设了这个值装出来的 chart 仍然在根路径，探针也照样通过。三个默认都是空的，所以一份一个都不设的 values 文件什么也不会改变。

secrets.adminTotpSecret 和 secrets.userTotpSecret 為某個帳號打開第二因素。config.basePath 讀起來像是把應用挪到子路徑下。它不會：它只給健康探測加前綴。子路徑本身是在建置映像檔時定死的，而發布的映像檔是按根路徑建置的，所以設了這個值裝出來的 chart 仍然在根路徑，探測也照樣通過。三個預設都是空的，所以一份一個都不設的 values 檔案什麼也不會改變。

secrets.adminTotpSecret i secrets.userTotpSecret włączają drugi składnik uwierzytelniania dla konta. config.basePath czyta się tak, jakby przenosił aplikację pod podkatalog. Nie przenosi: dokleja prefiks wyłącznie do sond zdrowia. Sam podkatalog jest ustalany przy budowaniu obrazu, a opublikowany obraz jest zbudowany na roocie, więc instalacja z chartu z tą ustawioną wartością zostaje na roocie, a jej sondy i tak przechodzą. Wszystkie trzy są domyślnie puste, więc plik values, który nie ustawia żadnej z nich, niczego nie zmienia.

secrets.adminTotpSecret et secrets.userTotpSecret activent le second facteur pour un compte. config.basePath se lit comme s'il déplaçait l'application vers un sous-chemin. Ce n'est pas le cas : il préfixe uniquement les sondes de santé. Le sous-chemin lui-même est figé à la construction de l'image, et l'image publiée est construite à la racine, donc une installation par chart avec cette valeur définie reste à la racine pendant que ses sondes continuent de passer. Les trois sont vides par défaut, si bien qu'un fichier de valeurs qui n'en définit aucune ne change rien.

secrets.adminTotpSecret e secrets.userTotpSecret attivano il secondo fattore per un account. config.basePath si legge come se spostasse l'applicazione su un subpath. Non lo fa: mette un prefisso soltanto alle health probe. Il subpath in sé è fissato quando l'immagine viene costruita, e l'immagine pubblicata è costruita sulla radice, quindi un'installazione via chart con quel valore impostato resta sulla radice mentre le sue probe continuano a passare. Tutti e tre sono vuoti di default, quindi un values file che non ne imposta nessuno non cambia niente.

secrets.adminTotpSecret und secrets.userTotpSecret schalten den zweiten Faktor für ein Konto ein. config.basePath liest sich, als würde er die Anwendung auf einen Subpfad verschieben. Tut er nicht: er stellt nur den Health-Probes ein Präfix voran. Der Subpfad selbst wird beim Bauen des Images festgelegt, und das veröffentlichte Image ist auf der Wurzel gebaut, eine Chart-Installation mit gesetztem Wert bleibt also auf der Wurzel und ihre Probes gehen trotzdem durch. Alle drei stehen standardmäßig leer, eine Values-Datei, die keinen davon setzt, ändert also nichts.

secrets.adminTotpSecret dan secrets.userTotpSecret menyalakan faktor kedua untuk sebuah akun. config.basePath terbaca seolah-olah memindahkan aplikasi ke sebuah subpath. Tidak begitu: ia hanya memberi awalan pada probe health. Subpath-nya sendiri sudah tetap saat image dibangun, dan image yang dipublikasikan dibangun di root, jadi instalasi chart dengan nilai itu diset tetap berada di root sementara probe-nya tetap lolos. Ketiganya default kosong, jadi values file yang tidak men-set satu pun tidak mengubah apa pun.

secrets.adminTotpSecret e secrets.userTotpSecret ligam o segundo fator de uma conta. config.basePath parece que move a aplicação para um subpath. Não move: ele prefixa só os probes de health. O subpath em si é fixado quando a imagem é construída, e a imagem publicada é construída na raiz, então uma instalação por chart com esse valor definido continua na raiz e os probes continuam passando. Os três têm padrão vazio, então um values file que não define nenhum deles não muda nada.

A template in the Kubero catalogue.

Una plantilla en el catálogo de Kubero.

Kubero のカタログにあるテンプレート。

Шаблон в каталоге Kubero.

Kubero کے کیٹلاگ میں ایک ٹیمپلیٹ۔

Kubero 目录里的一个模板。

Kubero 目錄裡的一個範本。

Szablon w katalogu Kubero.

Un template dans le catalogue Kubero.

Un template nel catalogo di Kubero.

Ein Template im Kubero-Katalog.

Sebuah template di katalog Kubero.

Um template no catálogo do Kubero.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

This catalogue currently installs 0.9.27, far behind the 0.17.0 these pages describe. Catalogues are refreshed on their own schedule rather than with the release, so check what the entry says before you plan around anything written here.

Este catálogo instala actualmente 0.9.27, muy por detrás de la 0.17.0 que describen estas páginas. Los catálogos se refrescan según su propio calendario y no con la versión, así que comprueba lo que dice la entrada antes de planificar en torno a nada de lo escrito aquí.

このカタログが現在入れるのは 0.9.27 で、これらのページが説明している 0.17.0 よりずっと古いものです。カタログはリリースに合わせてではなく、それぞれの都合で更新されます。ここに書かれていることを前提に計画する前に、掲載側の表示を確かめてください。

Этот каталог сейчас ставит 0.9.27, далеко позади 0.17.0, о которой эти страницы. Каталоги обновляются по своему расписанию, а не вместе с релизом, поэтому загляните в запись каталога, прежде чем строить планы на написанном здесь.

یہ کیٹلاگ اِس وقت 0.9.27 نصب کرتا ہے، جو ان صفحات کی 0.17.0 سے بہت پیچھے ہے۔ کیٹلاگ ریلیز کے ساتھ نہیں، اپنے وقت پر تازہ ہوتے ہیں، سو یہاں لکھی کسی بات پر منصوبہ بنانے سے پہلے وہاں کا اندراج دیکھ لیں۔

这个目录目前装的是 0.9.27，比这些页面讲的 0.17.0 落后很多。目录是按自己的节奏刷新的，不是跟着发布走，所以在把这里写的东西当前提之前，先看一眼条目上写的是什么。

這個目錄目前裝的是 0.9.27，比這些頁面講的 0.17.0 落後很多。目錄是按自己的節奏更新的，不是跟著發布走，所以在把這裡寫的東西當成前提之前，先看一眼項目上寫的是什麼。

Ten katalog instaluje obecnie 0.9.27, daleko za 0.17.0, którą opisują te strony. Katalogi odświeżają się we własnym rytmie, a nie razem z wydaniem, więc sprawdź, co mówi wpis, zanim oprzesz plany na czymkolwiek, co tu napisałem.

Ce catalogue installe actuellement la 0.9.27, loin derrière la 0.17.0 que ces pages décrivent. Les catalogues sont rafraîchis à leur propre rythme plutôt qu'avec la release, vérifiez donc ce que dit l'entrée avant de bâtir sur quoi que ce soit d'écrit ici.

Questo catalogo al momento installa la 0.9.27, molto indietro rispetto alla 0.17.0 che queste pagine descrivono. I cataloghi vengono aggiornati con i loro tempi e non insieme alla release, quindi controlla cosa dice la voce prima di fare piani su qualcosa scritto qui.

Dieser Katalog installiert derzeit 0.9.27, weit hinter dem 0.17.0, das diese Seiten beschreiben. Kataloge werden nach eigenem Zeitplan aufgefrischt und nicht mit dem Release, schau also nach, was der Eintrag sagt, bevor du um irgendetwas hier Geschriebenes herum planst.

Katalog ini saat ini memasang 0.9.27, jauh di belakang 0.17.0 yang dibahas halaman-halaman ini. Katalog disegarkan menurut jadwalnya sendiri, bukan bersama rilis, jadi periksa apa yang tertulis di entri itu sebelum Anda menyusun rencana di sekitar apa pun yang ditulis di sini.

Este catálogo hoje instala a 0.9.27, bem atrás da 0.17.0 que estas páginas descrevem. Catálogos são atualizados no ritmo deles e não junto com a release, então veja o que a entrada diz antes de planejar em cima de qualquer coisa escrita aqui.

Reaching it

Cómo llegar

到達の仕方

Как добраться

اس تک پہنچنا

怎么访问

怎麼存取

Jak do niego dotrzeć

L'atteindre

Come raggiungerlo

Wie du es erreichst

Menjangkaunya

Como alcançar

A cluster install usually sits behind an ingress that terminates TLS, which is the case where AUTH_COOKIE_SECURE should stay unset: over HTTPS the browser keeps a Secure cookie, so the advice in the home-server panels is the opposite situation, not this one. Where nothing is exposed yet, kubectl port-forward is enough to look around.

Una instalación en clúster suele estar detrás de un ingress que termina TLS, que es justo el caso en el que AUTH_COOKIE_SECURE debe quedarse sin definir: por HTTPS el navegador conserva una cookie Secure, así que el consejo de los paneles de servidor doméstico es la situación contraria, no esta. Donde todavía no haya nada expuesto, kubectl port-forward basta para echar un vistazo.

クラスターへの導入はたいてい TLS を終端する ingress の背後に置かれます。これは AUTH_COOKIE_SECURE を未設定のままにすべき場合です。HTTPS ならブラウザーは Secure Cookie を保持するので、家庭用サーバー向けパネルの助言は逆の状況の話であり、ここには当てはまりません。まだ何も公開していないなら、様子を見るには kubectl port-forward で十分です。

Установка в кластере обычно стоит за ingress, который терминирует TLS, а это именно тот случай, когда AUTH_COOKIE_SECURE следует оставить незаданным: по HTTPS браузер сохраняет Secure-куку, так что совет из панелей про домашний сервер относится к обратной ситуации, а не к этой. Пока наружу ничего не выставлено, осмотреться хватит kubectl port-forward.

کلسٹر پر تنصیب عموماً ایسے ingress کے پیچھے ہوتی ہے جو TLS ختم کرتا ہے، اور یہی وہ صورت ہے جہاں AUTH_COOKIE_SECURE کو غیر مقرر ہی رہنا چاہیے: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے، سو گھریلو سرور والے پینلوں کی نصیحت اُلٹی صورت کی ہے، اس کی نہیں۔ جہاں ابھی کچھ باہر نہیں کھولا گیا، وہاں دیکھنے بھالنے کے لیے kubectl port-forward کافی ہے۔

集群里的安装通常挂在一个负责终结 TLS 的 ingress 后面，而这正是 AUTH_COOKIE_SECURE 该保持不设的情形：HTTPS 下浏览器会保留 Secure cookie，所以家用服务器那几个面板的建议说的是相反的情况，不是这里。要是还什么都没暴露出去，用 kubectl port-forward 看看就够了。

叢集裡的安裝通常掛在一個負責終結 TLS 的 ingress 後面，而這正是 AUTH_COOKIE_SECURE 該保持不設的情形：HTTPS 下瀏覽器會保留 Secure cookie，所以家用伺服器那幾個面板的建議說的是相反的情況，不是這裡。要是還什麼都沒暴露出去，用 kubectl port-forward 看看就夠了。

Instalacja w klastrze zwykle siedzi za ingressem, który terminuje TLS, a to właśnie przypadek, w którym AUTH_COOKIE_SECURE powinno zostać nieustawione: po HTTPS przeglądarka utrzymuje ciasteczko Secure, więc rada z paneli o serwerach domowych dotyczy odwrotnej sytuacji, nie tej. Kiedy nic nie jest jeszcze wystawione, do rozejrzenia się wystarczy kubectl port-forward.

Une installation en cluster se trouve d'ordinaire derrière un ingress qui termine le TLS, et c'est le cas où AUTH_COOKIE_SECURE doit rester non défini : en HTTPS le navigateur conserve un cookie Secure, donc le conseil des panneaux serveur domestique vise la situation inverse, pas celle-ci. Là où rien n'est encore exposé, kubectl port-forward suffit pour regarder.

Un'installazione su cluster di solito sta dietro un ingress che termina il TLS, ed è il caso in cui AUTH_COOKIE_SECURE dovrebbe restare non impostato: in HTTPS il browser tiene un cookie Secure, quindi il consiglio nei pannelli dei server casalinghi riguarda la situazione opposta, non questa. Dove non è ancora esposto niente, kubectl port-forward basta per dare un'occhiata.

Eine Cluster-Installation sitzt meist hinter einem Ingress, der TLS terminiert, und das ist der Fall, in dem AUTH_COOKIE_SECURE ungesetzt bleiben sollte: über HTTPS behält der Browser ein Secure-Cookie, der Rat aus den Heimserver-Panels gilt also der umgekehrten Lage, nicht dieser. Wo noch nichts nach außen gestellt ist, reicht kubectl port-forward, um sich umzusehen.

Instalasi di cluster biasanya berada di belakang ingress yang menerminasi TLS, dan itulah kasus di mana AUTH_COOKIE_SECURE sebaiknya tetap tidak diset: lewat HTTPS browser menyimpan cookie Secure, jadi saran di panel home server adalah situasi sebaliknya, bukan yang ini. Kalau belum ada yang diekspos, kubectl port-forward sudah cukup untuk melihat-lihat.

Uma instalação em cluster geralmente fica atrás de um ingress que termina o TLS, que é o caso em que AUTH_COOKIE_SECURE deve ficar sem valor: em HTTPS o navegador guarda um cookie Secure, então o conselho dos painéis de home server é a situação oposta, não esta. Onde nada está exposto ainda, kubectl port-forward basta para dar uma olhada.

A template in the Sealos App Store.

Una plantilla en la App Store de Sealos.

Sealos アプリストアのテンプレート。

Шаблон в App Store Sealos.

Sealos ایپ اسٹور میں ایک ٹیمپلیٹ۔

Sealos 应用商店里的一个模板。

Sealos 應用商店裡的一個範本。

Szablon w Sealos App Store.

Un template dans le Sealos App Store.

Un template nell'App Store di Sealos.

Ein Template im Sealos App Store.

Sebuah template di Sealos App Store.

Um template na Sealos App Store.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

This catalogue currently installs 0.14.1, behind the 0.17.0 these pages describe. Catalogues are refreshed on their own schedule rather than with the release, so check what the entry says before you plan around anything written here.

Este catálogo instala actualmente 0.14.1, por detrás de la 0.17.0 que describen estas páginas. Los catálogos se refrescan según su propio calendario y no con la versión, así que comprueba lo que dice la entrada antes de planificar en torno a nada de lo escrito aquí.

このカタログが現在入れるのは 0.14.1 で、これらのページが説明している 0.17.0 より古いものです。カタログはリリースに合わせてではなく、それぞれの都合で更新されます。ここに書かれていることを前提に計画する前に、掲載側の表示を確かめてください。

Этот каталог сейчас ставит 0.14.1, позади 0.17.0, о которой эти страницы. Каталоги обновляются по своему расписанию, а не вместе с релизом, поэтому загляните в запись каталога, прежде чем строить планы на написанном здесь.

یہ کیٹلاگ اِس وقت 0.14.1 نصب کرتا ہے، جو ان صفحات کی 0.17.0 سے پیچھے ہے۔ کیٹلاگ ریلیز کے ساتھ نہیں، اپنے وقت پر تازہ ہوتے ہیں، سو یہاں لکھی کسی بات پر منصوبہ بنانے سے پہلے وہاں کا اندراج دیکھ لیں۔

这个目录目前装的是 0.14.1，比这些页面讲的 0.17.0 落后。目录是按自己的节奏刷新的，不是跟着发布走，所以在把这里写的东西当前提之前，先看一眼条目上写的是什么。

這個目錄目前裝的是 0.14.1，比這些頁面講的 0.17.0 落後。目錄是按自己的節奏更新的，不是跟著發布走，所以在把這裡寫的東西當成前提之前，先看一眼項目上寫的是什麼。

Ten katalog instaluje obecnie 0.14.1, za 0.17.0, którą opisują te strony. Katalogi odświeżają się we własnym rytmie, a nie razem z wydaniem, więc sprawdź, co mówi wpis, zanim oprzesz plany na czymkolwiek, co tu napisałem.

Ce catalogue installe actuellement la 0.14.1, derrière la 0.17.0 que ces pages décrivent. Les catalogues sont rafraîchis à leur propre rythme plutôt qu'avec la release, vérifiez donc ce que dit l'entrée avant de bâtir sur quoi que ce soit d'écrit ici.

Questo catalogo al momento installa la 0.14.1, indietro rispetto alla 0.17.0 che queste pagine descrivono. I cataloghi vengono aggiornati con i loro tempi e non insieme alla release, quindi controlla cosa dice la voce prima di fare piani su qualcosa scritto qui.

Dieser Katalog installiert derzeit 0.14.1, hinter dem 0.17.0, das diese Seiten beschreiben. Kataloge werden nach eigenem Zeitplan aufgefrischt und nicht mit dem Release, schau also nach, was der Eintrag sagt, bevor du um irgendetwas hier Geschriebenes herum planst.

Katalog ini saat ini memasang 0.14.1, di belakang 0.17.0 yang dibahas halaman-halaman ini. Katalog disegarkan menurut jadwalnya sendiri, bukan bersama rilis, jadi periksa apa yang tertulis di entri itu sebelum Anda menyusun rencana di sekitar apa pun yang ditulis di sini.

Este catálogo hoje instala a 0.14.1, atrás da 0.17.0 que estas páginas descrevem. Catálogos são atualizados no ritmo deles e não junto com a release, então veja o que a entrada diz antes de planejar em cima de qualquer coisa escrita aqui.

Reaching it

Cómo llegar

到達の仕方

Как добраться

اس تک پہنچنا

怎么访问

怎麼存取

Jak do niego dotrzeć

L'atteindre

Come raggiungerlo

Wie du es erreichst

Menjangkaunya

Como alcançar

A cluster install usually sits behind an ingress that terminates TLS, which is the case where AUTH_COOKIE_SECURE should stay unset: over HTTPS the browser keeps a Secure cookie, so the advice in the home-server panels is the opposite situation, not this one. Where nothing is exposed yet, kubectl port-forward is enough to look around.

Una instalación en clúster suele estar detrás de un ingress que termina TLS, que es justo el caso en el que AUTH_COOKIE_SECURE debe quedarse sin definir: por HTTPS el navegador conserva una cookie Secure, así que el consejo de los paneles de servidor doméstico es la situación contraria, no esta. Donde todavía no haya nada expuesto, kubectl port-forward basta para echar un vistazo.

クラスターへの導入はたいてい TLS を終端する ingress の背後に置かれます。これは AUTH_COOKIE_SECURE を未設定のままにすべき場合です。HTTPS ならブラウザーは Secure Cookie を保持するので、家庭用サーバー向けパネルの助言は逆の状況の話であり、ここには当てはまりません。まだ何も公開していないなら、様子を見るには kubectl port-forward で十分です。

Установка в кластере обычно стоит за ingress, который терминирует TLS, а это именно тот случай, когда AUTH_COOKIE_SECURE следует оставить незаданным: по HTTPS браузер сохраняет Secure-куку, так что совет из панелей про домашний сервер относится к обратной ситуации, а не к этой. Пока наружу ничего не выставлено, осмотреться хватит kubectl port-forward.

کلسٹر پر تنصیب عموماً ایسے ingress کے پیچھے ہوتی ہے جو TLS ختم کرتا ہے، اور یہی وہ صورت ہے جہاں AUTH_COOKIE_SECURE کو غیر مقرر ہی رہنا چاہیے: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے، سو گھریلو سرور والے پینلوں کی نصیحت اُلٹی صورت کی ہے، اس کی نہیں۔ جہاں ابھی کچھ باہر نہیں کھولا گیا، وہاں دیکھنے بھالنے کے لیے kubectl port-forward کافی ہے۔

集群里的安装通常挂在一个负责终结 TLS 的 ingress 后面，而这正是 AUTH_COOKIE_SECURE 该保持不设的情形：HTTPS 下浏览器会保留 Secure cookie，所以家用服务器那几个面板的建议说的是相反的情况，不是这里。要是还什么都没暴露出去，用 kubectl port-forward 看看就够了。

叢集裡的安裝通常掛在一個負責終結 TLS 的 ingress 後面，而這正是 AUTH_COOKIE_SECURE 該保持不設的情形：HTTPS 下瀏覽器會保留 Secure cookie，所以家用伺服器那幾個面板的建議說的是相反的情況，不是這裡。要是還什麼都沒暴露出去，用 kubectl port-forward 看看就夠了。

Instalacja w klastrze zwykle siedzi za ingressem, który terminuje TLS, a to właśnie przypadek, w którym AUTH_COOKIE_SECURE powinno zostać nieustawione: po HTTPS przeglądarka utrzymuje ciasteczko Secure, więc rada z paneli o serwerach domowych dotyczy odwrotnej sytuacji, nie tej. Kiedy nic nie jest jeszcze wystawione, do rozejrzenia się wystarczy kubectl port-forward.

Une installation en cluster se trouve d'ordinaire derrière un ingress qui termine le TLS, et c'est le cas où AUTH_COOKIE_SECURE doit rester non défini : en HTTPS le navigateur conserve un cookie Secure, donc le conseil des panneaux serveur domestique vise la situation inverse, pas celle-ci. Là où rien n'est encore exposé, kubectl port-forward suffit pour regarder.

Un'installazione su cluster di solito sta dietro un ingress che termina il TLS, ed è il caso in cui AUTH_COOKIE_SECURE dovrebbe restare non impostato: in HTTPS il browser tiene un cookie Secure, quindi il consiglio nei pannelli dei server casalinghi riguarda la situazione opposta, non questa. Dove non è ancora esposto niente, kubectl port-forward basta per dare un'occhiata.

Eine Cluster-Installation sitzt meist hinter einem Ingress, der TLS terminiert, und das ist der Fall, in dem AUTH_COOKIE_SECURE ungesetzt bleiben sollte: über HTTPS behält der Browser ein Secure-Cookie, der Rat aus den Heimserver-Panels gilt also der umgekehrten Lage, nicht dieser. Wo noch nichts nach außen gestellt ist, reicht kubectl port-forward, um sich umzusehen.

Instalasi di cluster biasanya berada di belakang ingress yang menerminasi TLS, dan itulah kasus di mana AUTH_COOKIE_SECURE sebaiknya tetap tidak diset: lewat HTTPS browser menyimpan cookie Secure, jadi saran di panel home server adalah situasi sebaliknya, bukan yang ini. Kalau belum ada yang diekspos, kubectl port-forward sudah cukup untuk melihat-lihat.

Uma instalação em cluster geralmente fica atrás de um ingress que termina o TLS, que é o caso em que AUTH_COOKIE_SECURE deve ficar sem valor: em HTTPS o navegador guarda um cookie Secure, então o conselho dos painéis de home server é a situação oposta, não esta. Onde nada está exposto ainda, kubectl port-forward basta para dar uma olhada.

A community operator for OpenShift and OperatorHub.

Un operador community para OpenShift y OperatorHub.

OpenShift と OperatorHub 向けのコミュニティオペレーター。

Community-оператор для OpenShift и OperatorHub.

OpenShift اور OperatorHub کے لیے ایک کمیونٹی آپریٹر۔

面向 OpenShift 和 OperatorHub 的社区 operator。

面向 OpenShift 和 OperatorHub 的社群 operator。

Operator społecznościowy dla OpenShift i OperatorHub.

Un operator communautaire pour OpenShift et OperatorHub.

Un operator della community per OpenShift e OperatorHub.

Ein Community-Operator für OpenShift und OperatorHub.

Operator komunitas untuk OpenShift dan OperatorHub.

Um operator da comunidade para OpenShift e OperatorHub.

Where it is listed

Dónde está listado

どこに掲載されているか

Где он опубликован

یہ کہاں درج ہے

它上架在哪里

它上架在哪裡

Gdzie jest wystawiony

Où il est listé

Dove è in elenco

Wo er gelistet ist

Di mana ia terdaftar

Onde ele está listado

The operator is published on operatorhub.io, where it currently reads 0.17.0. The OpenShift console reads from a separate catalogue that is refreshed on its own schedule, and today it is the older of the two at 0.16.0, so read the version the console shows before you install. Install it from OperatorHub in the console, then create the custom resource the operator watches; it installs the same chart the helm path uses.

El operador está publicado en operatorhub.io, donde actualmente figura la 0.17.0. La consola de OpenShift lee de un catálogo aparte que se refresca según su propio calendario, y hoy es el más antiguo de los dos, en la 0.16.0, así que mira la versión que muestra la consola antes de instalar. Instálalo desde OperatorHub en la consola y crea después el recurso personalizado que el operador vigila; instala el mismo chart que usa el camino de helm.

このオペレーターは operatorhub.io に公開されており、そこでの表示は現在 0.17.0 です。OpenShift のコンソールは別のカタログを読み、そちらはそれぞれの都合で更新されます。今日の時点では二つのうち古いほうで、0.16.0 です。入れる前に、コンソールが表示しているバージョンを読んでください。コンソールの OperatorHub から導入し、そのあとオペレーターが監視するカスタムリソースを作成してください。入るチャートは helm の経路と同じものです。

Оператор опубликован на operatorhub.io, где сейчас значится 0.17.0. Консоль OpenShift читает из отдельного каталога, который обновляется по своему расписанию, и сегодня он из двух старший, то есть там 0.16.0, поэтому перед установкой посмотрите версию, которую показывает консоль. Установите оператор из OperatorHub в консоли, затем создайте кастомный ресурс, за которым он следит; ставится тот же чарт, что и на пути через helm.

یہ آپریٹر operatorhub.io پر شائع ہے، جہاں اِس وقت 0.17.0 لکھا ہے۔ OpenShift کا کنسول ایک الگ کیٹلاگ سے پڑھتا ہے جو اپنے وقت پر تازہ ہوتا ہے، اور آج دونوں میں سے پرانا وہی ہے، 0.16.0 پر، سو نصب کرنے سے پہلے وہ ورژن دیکھ لیں جو کنسول دکھاتا ہے۔ کنسول میں OperatorHub سے نصب کریں، پھر وہ کسٹم ریسورس بنائیں جس پر آپریٹر نظر رکھتا ہے؛ یہ وہی چارٹ نصب کرتا ہے جو helm والا راستہ استعمال کرتا ہے۔

这个 operator 发布在 operatorhub.io 上，那里目前显示 0.17.0。OpenShift 控制台读的是另一个按自己节奏刷新的目录，今天它是两者里更旧的那个，停在 0.16.0，所以装之前先看一眼控制台显示的版本。在控制台的 OperatorHub 里安装它，然后创建这个 operator 所监视的自定义资源；它装的是和 helm 那条路一样的 chart。

這個 operator 發布在 operatorhub.io 上，那裡目前顯示 0.17.0。OpenShift 主控台讀的是另一個按自己節奏更新的目錄，今天它是兩者裡更舊的那個，停在 0.16.0，所以裝之前先看一眼主控台顯示的版本。在主控台的 OperatorHub 裡安裝它，然後建立這個 operator 所監視的自訂資源；它裝的是和 helm 那條路一樣的 chart。

Operator jest opublikowany na operatorhub.io, gdzie widnieje teraz 0.17.0. Konsola OpenShift czyta z osobnego katalogu, który odświeża się we własnym rytmie, i dziś to on jest starszym z dwóch: stoi na 0.16.0, więc przed instalacją sprawdź wersję, którą pokazuje konsola. Zainstaluj go z OperatorHub w konsoli, a potem utwórz zasób niestandardowy, którego pilnuje operator; instaluje on ten sam chart co ścieżka helm.

L'operator est publié sur operatorhub.io, où il lit actuellement 0.17.0. La console OpenShift lit depuis un catalogue distinct, rafraîchi à son propre rythme, et c'est aujourd'hui le plus ancien des deux, en 0.16.0, lisez donc la version qu'affiche la console avant d'installer. Installez-le depuis OperatorHub dans la console, puis créez la ressource personnalisée que l'operator surveille ; il installe le même chart que le chemin helm.

L'operator è pubblicato su operatorhub.io, dove al momento riporta 0.17.0. La console OpenShift legge da un catalogo separato che viene aggiornato con i suoi tempi, e oggi è il più vecchio dei due, fermo alla 0.16.0, quindi guarda la versione che mostra la console prima di installare. Installalo da OperatorHub nella console, poi crea la custom resource che l'operator osserva; installa lo stesso chart che usa la strada helm.

Der Operator ist auf operatorhub.io veröffentlicht, dort steht derzeit 0.17.0. Die OpenShift-Konsole liest aus einem eigenen Katalog, der nach eigenem Zeitplan aufgefrischt wird, und heute ist er der ältere von beiden bei 0.16.0, lies also die Version, die die Konsole zeigt, bevor du installierst. Installiere ihn in der Konsole aus OperatorHub und leg dann die Custom Resource an, die der Operator beobachtet; er installiert dasselbe Chart wie der helm-Weg.

Operator ini dipublikasikan di operatorhub.io, di mana saat ini tertulis 0.17.0. Konsol OpenShift membaca dari katalog terpisah yang disegarkan menurut jadwalnya sendiri, dan hari ini katalog itulah yang lebih tua di antara keduanya, yaitu 0.16.0, jadi baca versi yang ditampilkan konsol sebelum Anda memasang. Pasang dari OperatorHub di konsol, lalu buat custom resource yang diawasi operator; ia memasang chart yang sama dengan yang dipakai jalur helm.

O operator é publicado no operatorhub.io, onde hoje aparece como 0.17.0. O console do OpenShift lê de um catálogo separado, atualizado no ritmo dele, e hoje ele é o mais antigo dos dois, na 0.16.0, então veja a versão que o console mostra antes de instalar. Instale pelo OperatorHub no console e depois crie o custom resource que o operator observa; ele instala o mesmo chart que o caminho helm usa.

Reaching it

Cómo llegar

到達の仕方

Как добраться

اس تک پہنچنا

怎么访问

怎麼存取

Jak do niego dotrzeć

L'atteindre

Come raggiungerlo

Wie du es erreichst

Menjangkaunya

Como alcançar

A cluster install usually sits behind an ingress that terminates TLS, which is the case where AUTH_COOKIE_SECURE should stay unset: over HTTPS the browser keeps a Secure cookie, so the advice in the home-server panels is the opposite situation, not this one. Where nothing is exposed yet, kubectl port-forward is enough to look around.

Una instalación en clúster suele estar detrás de un ingress que termina TLS, que es justo el caso en el que AUTH_COOKIE_SECURE debe quedarse sin definir: por HTTPS el navegador conserva una cookie Secure, así que el consejo de los paneles de servidor doméstico es la situación contraria, no esta. Donde todavía no haya nada expuesto, kubectl port-forward basta para echar un vistazo.

クラスターへの導入はたいてい TLS を終端する ingress の背後に置かれます。これは AUTH_COOKIE_SECURE を未設定のままにすべき場合です。HTTPS ならブラウザーは Secure Cookie を保持するので、家庭用サーバー向けパネルの助言は逆の状況の話であり、ここには当てはまりません。まだ何も公開していないなら、様子を見るには kubectl port-forward で十分です。

Установка в кластере обычно стоит за ingress, который терминирует TLS, а это именно тот случай, когда AUTH_COOKIE_SECURE следует оставить незаданным: по HTTPS браузер сохраняет Secure-куку, так что совет из панелей про домашний сервер относится к обратной ситуации, а не к этой. Пока наружу ничего не выставлено, осмотреться хватит kubectl port-forward.

کلسٹر پر تنصیب عموماً ایسے ingress کے پیچھے ہوتی ہے جو TLS ختم کرتا ہے، اور یہی وہ صورت ہے جہاں AUTH_COOKIE_SECURE کو غیر مقرر ہی رہنا چاہیے: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے، سو گھریلو سرور والے پینلوں کی نصیحت اُلٹی صورت کی ہے، اس کی نہیں۔ جہاں ابھی کچھ باہر نہیں کھولا گیا، وہاں دیکھنے بھالنے کے لیے kubectl port-forward کافی ہے۔

集群里的安装通常挂在一个负责终结 TLS 的 ingress 后面，而这正是 AUTH_COOKIE_SECURE 该保持不设的情形：HTTPS 下浏览器会保留 Secure cookie，所以家用服务器那几个面板的建议说的是相反的情况，不是这里。要是还什么都没暴露出去，用 kubectl port-forward 看看就够了。

叢集裡的安裝通常掛在一個負責終結 TLS 的 ingress 後面，而這正是 AUTH_COOKIE_SECURE 該保持不設的情形：HTTPS 下瀏覽器會保留 Secure cookie，所以家用伺服器那幾個面板的建議說的是相反的情況，不是這裡。要是還什麼都沒暴露出去，用 kubectl port-forward 看看就夠了。

Instalacja w klastrze zwykle siedzi za ingressem, który terminuje TLS, a to właśnie przypadek, w którym AUTH_COOKIE_SECURE powinno zostać nieustawione: po HTTPS przeglądarka utrzymuje ciasteczko Secure, więc rada z paneli o serwerach domowych dotyczy odwrotnej sytuacji, nie tej. Kiedy nic nie jest jeszcze wystawione, do rozejrzenia się wystarczy kubectl port-forward.

Une installation en cluster se trouve d'ordinaire derrière un ingress qui termine le TLS, et c'est le cas où AUTH_COOKIE_SECURE doit rester non défini : en HTTPS le navigateur conserve un cookie Secure, donc le conseil des panneaux serveur domestique vise la situation inverse, pas celle-ci. Là où rien n'est encore exposé, kubectl port-forward suffit pour regarder.

Un'installazione su cluster di solito sta dietro un ingress che termina il TLS, ed è il caso in cui AUTH_COOKIE_SECURE dovrebbe restare non impostato: in HTTPS il browser tiene un cookie Secure, quindi il consiglio nei pannelli dei server casalinghi riguarda la situazione opposta, non questa. Dove non è ancora esposto niente, kubectl port-forward basta per dare un'occhiata.

Eine Cluster-Installation sitzt meist hinter einem Ingress, der TLS terminiert, und das ist der Fall, in dem AUTH_COOKIE_SECURE ungesetzt bleiben sollte: über HTTPS behält der Browser ein Secure-Cookie, der Rat aus den Heimserver-Panels gilt also der umgekehrten Lage, nicht dieser. Wo noch nichts nach außen gestellt ist, reicht kubectl port-forward, um sich umzusehen.

Instalasi di cluster biasanya berada di belakang ingress yang menerminasi TLS, dan itulah kasus di mana AUTH_COOKIE_SECURE sebaiknya tetap tidak diset: lewat HTTPS browser menyimpan cookie Secure, jadi saran di panel home server adalah situasi sebaliknya, bukan yang ini. Kalau belum ada yang diekspos, kubectl port-forward sudah cukup untuk melihat-lihat.

Uma instalação em cluster geralmente fica atrás de um ingress que termina o TLS, que é o caso em que AUTH_COOKIE_SECURE deve ficar sem valor: em HTTPS o navegador guarda um cookie Secure, então o conselho dos painéis de home server é a situação oposta, não esta. Onde nada está exposto ainda, kubectl port-forward basta para dar uma olhada.

The chart in Rancher's partner catalogue.

El chart en el catálogo de partners de Rancher.

Rancher のパートナーカタログにあるチャート。

Чарт в партнёрском каталоге Rancher.

Rancher کے پارٹنر کیٹلاگ میں موجود چارٹ۔

Rancher 合作伙伴目录里的 chart。

Rancher 合作夥伴目錄裡的 chart。

Chart w katalogu partnerskim Rancher.

Le chart du catalogue partenaire de Rancher.

Il chart nel catalogo partner di Rancher.

Das Chart in Ranchers Partnerkatalog.

Chart di katalog partner Rancher.

O chart no catálogo de parceiros da Rancher.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

This catalogue currently installs 0.16.1, one release behind the 0.17.0 these pages describe. Catalogues are refreshed on their own schedule rather than with the release, so check what the entry says before you plan around anything written here.

Este catálogo instala actualmente 0.16.1, una release por detrás de la 0.17.0 que describen estas páginas. Los catálogos se refrescan según su propio calendario y no con la versión, así que comprueba lo que dice la entrada antes de planificar en torno a nada de lo escrito aquí.

このカタログが現在入れるのは 0.16.1 で、これらのページが説明している 0.17.0 より一つ前のリリースです。カタログはリリースに合わせてではなく、それぞれの都合で更新されます。ここに書かれていることを前提に計画する前に、掲載側の表示を確かめてください。

Этот каталог сейчас ставит 0.16.1, то есть на один выпуск позади 0.17.0, о которой эти страницы. Каталоги обновляются по своему расписанию, а не вместе с релизом, поэтому загляните в запись каталога, прежде чем строить планы на написанном здесь.

یہ کیٹلاگ اِس وقت 0.16.1 نصب کرتا ہے، جو ان صفحات کی 0.17.0 سے ایک ریلیز پیچھے ہے۔ کیٹلاگ ریلیز کے ساتھ نہیں، اپنے وقت پر تازہ ہوتے ہیں، سو یہاں لکھی کسی بات پر منصوبہ بنانے سے پہلے وہاں کا اندراج دیکھ لیں۔

这个目录目前装的是 0.16.1，比这些页面讲的 0.17.0 落后一个版本。目录是按自己的节奏刷新的，不是跟着发布走，所以在把这里写的东西当前提之前，先看一眼条目上写的是什么。

這個目錄目前裝的是 0.16.1，比這些頁面講的 0.17.0 落後一個版本。目錄是按自己的節奏更新的，不是跟著發布走，所以在把這裡寫的東西當成前提之前，先看一眼項目上寫的是什麼。

Ten katalog instaluje obecnie 0.16.1, o jedno wydanie za 0.17.0, którą opisują te strony. Katalogi odświeżają się we własnym rytmie, a nie razem z wydaniem, więc sprawdź, co mówi wpis, zanim oprzesz plany na czymkolwiek, co tu napisałem.

Ce catalogue installe actuellement la 0.16.1, une release derrière la 0.17.0 que ces pages décrivent. Les catalogues sont rafraîchis à leur propre rythme plutôt qu'avec la release, vérifiez donc ce que dit l'entrée avant de bâtir sur quoi que ce soit d'écrit ici.

Questo catalogo al momento installa la 0.16.1, una release indietro rispetto alla 0.17.0 che queste pagine descrivono. I cataloghi vengono aggiornati con i loro tempi e non insieme alla release, quindi controlla cosa dice la voce prima di fare piani su qualcosa scritto qui.

Dieser Katalog installiert derzeit 0.16.1, ein Release hinter dem 0.17.0, das diese Seiten beschreiben. Kataloge werden nach eigenem Zeitplan aufgefrischt und nicht mit dem Release, schau also nach, was der Eintrag sagt, bevor du um irgendetwas hier Geschriebenes herum planst.

Katalog ini saat ini memasang 0.16.1, satu rilis di belakang 0.17.0 yang dibahas halaman-halaman ini. Katalog disegarkan menurut jadwalnya sendiri, bukan bersama rilis, jadi periksa apa yang tertulis di entri itu sebelum Anda menyusun rencana di sekitar apa pun yang ditulis di sini.

Este catálogo hoje instala a 0.16.1, uma release atrás da 0.17.0 que estas páginas descrevem. Catálogos são atualizados no ritmo deles e não junto com a release, então veja o que a entrada diz antes de planejar em cima de qualquer coisa escrita aqui.

Reaching it

Cómo llegar

到達の仕方

Как добраться

اس تک پہنچنا

怎么访问

怎麼存取

Jak do niego dotrzeć

L'atteindre

Come raggiungerlo

Wie du es erreichst

Menjangkaunya

Como alcançar

A cluster install usually sits behind an ingress that terminates TLS, which is the case where AUTH_COOKIE_SECURE should stay unset: over HTTPS the browser keeps a Secure cookie, so the advice in the home-server panels is the opposite situation, not this one. Where nothing is exposed yet, kubectl port-forward is enough to look around.

Una instalación en clúster suele estar detrás de un ingress que termina TLS, que es justo el caso en el que AUTH_COOKIE_SECURE debe quedarse sin definir: por HTTPS el navegador conserva una cookie Secure, así que el consejo de los paneles de servidor doméstico es la situación contraria, no esta. Donde todavía no haya nada expuesto, kubectl port-forward basta para echar un vistazo.

クラスターへの導入はたいてい TLS を終端する ingress の背後に置かれます。これは AUTH_COOKIE_SECURE を未設定のままにすべき場合です。HTTPS ならブラウザーは Secure Cookie を保持するので、家庭用サーバー向けパネルの助言は逆の状況の話であり、ここには当てはまりません。まだ何も公開していないなら、様子を見るには kubectl port-forward で十分です。

Установка в кластере обычно стоит за ingress, который терминирует TLS, а это именно тот случай, когда AUTH_COOKIE_SECURE следует оставить незаданным: по HTTPS браузер сохраняет Secure-куку, так что совет из панелей про домашний сервер относится к обратной ситуации, а не к этой. Пока наружу ничего не выставлено, осмотреться хватит kubectl port-forward.

کلسٹر پر تنصیب عموماً ایسے ingress کے پیچھے ہوتی ہے جو TLS ختم کرتا ہے، اور یہی وہ صورت ہے جہاں AUTH_COOKIE_SECURE کو غیر مقرر ہی رہنا چاہیے: HTTPS پر براؤزر Secure کوکی رکھ لیتا ہے، سو گھریلو سرور والے پینلوں کی نصیحت اُلٹی صورت کی ہے، اس کی نہیں۔ جہاں ابھی کچھ باہر نہیں کھولا گیا، وہاں دیکھنے بھالنے کے لیے kubectl port-forward کافی ہے۔

集群里的安装通常挂在一个负责终结 TLS 的 ingress 后面，而这正是 AUTH_COOKIE_SECURE 该保持不设的情形：HTTPS 下浏览器会保留 Secure cookie，所以家用服务器那几个面板的建议说的是相反的情况，不是这里。要是还什么都没暴露出去，用 kubectl port-forward 看看就够了。

叢集裡的安裝通常掛在一個負責終結 TLS 的 ingress 後面，而這正是 AUTH_COOKIE_SECURE 該保持不設的情形：HTTPS 下瀏覽器會保留 Secure cookie，所以家用伺服器那幾個面板的建議說的是相反的情況，不是這裡。要是還什麼都沒暴露出去，用 kubectl port-forward 看看就夠了。

Instalacja w klastrze zwykle siedzi za ingressem, który terminuje TLS, a to właśnie przypadek, w którym AUTH_COOKIE_SECURE powinno zostać nieustawione: po HTTPS przeglądarka utrzymuje ciasteczko Secure, więc rada z paneli o serwerach domowych dotyczy odwrotnej sytuacji, nie tej. Kiedy nic nie jest jeszcze wystawione, do rozejrzenia się wystarczy kubectl port-forward.

Une installation en cluster se trouve d'ordinaire derrière un ingress qui termine le TLS, et c'est le cas où AUTH_COOKIE_SECURE doit rester non défini : en HTTPS le navigateur conserve un cookie Secure, donc le conseil des panneaux serveur domestique vise la situation inverse, pas celle-ci. Là où rien n'est encore exposé, kubectl port-forward suffit pour regarder.

Un'installazione su cluster di solito sta dietro un ingress che termina il TLS, ed è il caso in cui AUTH_COOKIE_SECURE dovrebbe restare non impostato: in HTTPS il browser tiene un cookie Secure, quindi il consiglio nei pannelli dei server casalinghi riguarda la situazione opposta, non questa. Dove non è ancora esposto niente, kubectl port-forward basta per dare un'occhiata.

Eine Cluster-Installation sitzt meist hinter einem Ingress, der TLS terminiert, und das ist der Fall, in dem AUTH_COOKIE_SECURE ungesetzt bleiben sollte: über HTTPS behält der Browser ein Secure-Cookie, der Rat aus den Heimserver-Panels gilt also der umgekehrten Lage, nicht dieser. Wo noch nichts nach außen gestellt ist, reicht kubectl port-forward, um sich umzusehen.

Instalasi di cluster biasanya berada di belakang ingress yang menerminasi TLS, dan itulah kasus di mana AUTH_COOKIE_SECURE sebaiknya tetap tidak diset: lewat HTTPS browser menyimpan cookie Secure, jadi saran di panel home server adalah situasi sebaliknya, bukan yang ini. Kalau belum ada yang diekspos, kubectl port-forward sudah cukup untuk melihat-lihat.

Uma instalação em cluster geralmente fica atrás de um ingress que termina o TLS, que é o caso em que AUTH_COOKIE_SECURE deve ficar sem valor: em HTTPS o navegador guarda um cookie Secure, então o conselho dos painéis de home server é a situação oposta, não esta. Onde nada está exposto ainda, kubectl port-forward basta para dar uma olhada.

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Unraid

Community Applications. No terminal. The template pins 0.17.0, the release these pages describe, but Community Applications serves what its own periodic catalogue build picked up and that is still 0.16.0, so the version you install today is two releases behind the template. Read the version on the entry before you install rather than the one here.

Community Applications. Sin terminal. La plantilla fija la 0.17.0, la release que describen estas páginas, pero Community Applications sirve lo que recogió su propia compilación periódica del catálogo y eso sigue siendo la 0.16.0, así que la versión que instalas hoy va dos releases por detrás de la plantilla. Antes de instalar, lee la versión que figura en la entrada y no la de aquí.

Community Applications。端末は要りません。テンプレートが固定しているのは 0.17.0、つまりこれらのページが説明しているリリースですが、Community Applications が配るのは自前の定期カタログビルドが拾ったもので、それはまだ 0.16.0 です。つまり今日入るのはテンプレートより二つ前のリリースです。入れる前に、ここに書かれた版ではなく登録項目に出ている版を読んでください。

Community Applications. Без терминала. Шаблон закрепляет 0.17.0, то есть выпуск, о котором эти страницы, но Community Applications отдаёт то, что подхватила её собственная периодическая сборка каталога, а это всё ещё 0.16.0, так что версия, которую вы ставите сегодня, на два выпуска позади шаблона. Перед установкой читайте версию в самой записи каталога, а не здесь.

Community Applications۔ ٹرمینل کی ضرورت نہیں۔ ٹیمپلیٹ 0.17.0 پر پن کرتا ہے، یعنی وہی ریلیز جو یہ صفحات بیان کرتے ہیں، مگر Community Applications وہ پیش کرتا ہے جو اُس کی اپنی وقتاً فوقتاً بننے والی فہرست نے پکڑا تھا، اور وہ اب بھی 0.16.0 ہے، سو آج آپ جو نسخہ نصب کرتے ہیں وہ ٹیمپلیٹ سے دو ریلیز پیچھے ہے۔ نصب کرنے سے پہلے یہاں کا نہیں بلکہ اندراج پر لکھا ہوا نسخہ پڑھیے۔

Community Applications。不需要终端。模板钉的是 0.17.0，也就是这些页面讲的那个版本，但 Community Applications 供的是它自己定期构建的目录抓到的东西，那还是 0.16.0，所以你今天装上的版本比模板落后两个版本。安装之前请读条目上写的版本，而不是这里写的。

Community Applications。不需要終端機。範本釘的是 0.17.0，也就是這些頁面講的那個版本，但 Community Applications 供的是它自己定期建置的目錄抓到的東西，那還是 0.16.0，所以你今天裝上的版本比範本落後兩個版本。安裝之前請讀條目上寫的版本，而不是這裡寫的。

Community Applications. Bez terminala. Szablon przypina 0.17.0, wydanie opisywane na tych stronach, ale Community Applications podaje to, co złapała jego własna okresowa kompilacja katalogu, a to wciąż 0.16.0, więc wersja, którą instalujesz dzisiaj, jest dwa wydania za szablonem. Przed instalacją czytaj wersję z samego wpisu, a nie tę stąd.

Community Applications. Pas de terminal. Le template épingle la 0.17.0, la release que ces pages décrivent, mais Community Applications sert ce que sa propre compilation périodique du catalogue a récupéré, et c’est encore la 0.16.0 : la version que vous installez aujourd’hui a donc deux releases de retard sur le template. Avant d’installer, lisez la version affichée sur la fiche plutôt que celle d’ici.

Community Applications. Nessun terminale. Il template fissa la 0.17.0, la release che queste pagine descrivono, ma Community Applications serve quello che ha raccolto la sua build periodica del catalogo, e quella è ancora la 0.16.0, quindi la versione che installi oggi è due release indietro rispetto al template. Prima di installare leggi la versione scritta sulla scheda, non quella qui.

Community Applications. Kein Terminal. Das Template pinnt 0.17.0, das Release, das diese Seiten beschreiben, aber Community Applications liefert das, was der eigene periodische Katalog-Build aufgegriffen hat, und das ist immer noch 0.16.0, die Version, die du heute installierst, liegt also zwei Releases hinter dem Template. Lies vor der Installation die Version auf dem Eintrag und nicht die hier.

Community Applications. Tanpa terminal. Template-nya mematok 0.17.0, rilis yang dibahas halaman-halaman ini, tetapi Community Applications menyajikan apa yang ditangkap build katalog berkalanya sendiri dan itu masih 0.16.0, jadi versi yang Anda pasang hari ini tertinggal dua rilis dari template. Sebelum memasang, baca versi yang tertera di entrinya, bukan yang di sini.

Community Applications. Sem terminal. O template fixa a 0.17.0, a release que estas páginas descrevem, mas o Community Applications serve o que a própria compilação periódica do catálogo dele capturou, e isso ainda é a 0.16.0, então a versão que você instala hoje está duas releases atrás do template. Antes de instalar, leia a versão que está na entrada e não a daqui.

What you need

Qué necesitas

必要なもの

Что нужно

آپ کو کیا درکار ہے

你需要什么

你需要什麼

Czego potrzebujesz

Ce qu'il vous faut

Cosa ti serve

Was du brauchst

Yang Anda perlukan

O que você precisa

An Unraid server with the Community Applications plugin installed. Nothing else.

Un servidor Unraid con el complemento Community Applications instalado. Nada más.

Community Applications プラグインを入れた Unraid サーバー。ほかには何も要りません。

Сервер Unraid с установленным плагином Community Applications. Больше ничего.

ایک Unraid سرور جس پر Community Applications پلگ اِن نصب ہو۔ اور کچھ نہیں۔

一台装了 Community Applications 插件的 Unraid 服务器。别的都不需要。

一台裝了 Community Applications 外掛的 Unraid 伺服器。別的都不需要。

Serwera Unraid z zainstalowaną wtyczką Community Applications. Nic więcej.

Un serveur Unraid avec le plugin Community Applications installé. Rien d'autre.

Un server Unraid con il plugin Community Applications installato. Nient'altro.

Einen Unraid-Server mit installiertem Community-Applications-Plugin. Sonst nichts.

Sebuah server Unraid dengan plugin Community Applications terpasang. Tidak ada yang lain.

Um servidor Unraid com o plugin Community Applications instalado. Mais nada.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Open the Apps tab.
2. Search for LibreDB Studio and press Install.
3. Fill in the three required fields in the Add Container form: ADMIN_EMAIL, ADMIN_PASSWORD and JWT_SECRET. Only the last has a length the server checks, and it is 32 characters.
4. Press Apply and wait for the pull.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

The WebUI button on the Docker tab opens http://your-unraid-host:3006. Host port 3006 is the template default, mapped to container port 3000. The template deliberately avoids 3000 on the host because it collides with other Unraid apps so often. Any free port works if you want a different one.

El botón WebUI de la pestaña Docker abre http://your-unraid-host:3006. El puerto 3006 del host es el valor por defecto de la plantilla, mapeado al puerto 3000 del contenedor. La plantilla evita a propósito el 3000 en el host porque choca con otras aplicaciones de Unraid demasiado a menudo. Cualquier puerto libre sirve si quieres otro.

Docker タブの WebUI ボタンが http://your-unraid-host:3006 を開きます。ホスト側ポート 3006 はテンプレートの既定値で、コンテナ側のポート 3000 に対応づけられています。ホスト側で 3000 を避けているのは意図的で、ほかの Unraid アプリとあまりによく衝突するからです。別のポートが良ければ、空いていればどれでも構いません。

Кнопка WebUI на вкладке Docker открывает http://your-unraid-host:3006. Порт хоста 3006 задан в шаблоне по умолчанию, он отображён на порт 3000 контейнера. Шаблон намеренно избегает 3000 на хосте, потому что тот слишком часто конфликтует с другими приложениями Unraid. Подойдёт любой свободный порт, если хотите другой.

Docker ٹیب پر WebUI کا بٹن http://your-unraid-host:3006 کھولتا ہے۔ ہوسٹ پورٹ 3006 ٹیمپلیٹ کی طے شدہ قدر ہے، جو کنٹینر کے پورٹ 3000 سے منسلک ہے۔ ٹیمپلیٹ ہوسٹ پر 3000 سے جان بوجھ کر بچتا ہے، کیونکہ وہ دوسری Unraid ایپس سے بہت زیادہ ٹکراتا ہے۔ کوئی اور پورٹ چاہیے تو جو بھی خالی ہو، چل جائے گا۔

Docker 标签页上的 WebUI 按钮会打开 http://your-unraid-host:3006。主机端口 3006 是模板的默认值，映射到容器的 3000 端口。模板刻意避开主机上的 3000，因为它和其他 Unraid 应用冲突得实在太频繁。想换别的端口，只要空着都行。

Docker 分頁上的 WebUI 按鈕會打開 http://your-unraid-host:3006。主機連接埠 3006 是範本的預設值，映射到容器的 3000 連接埠。範本刻意避開主機上的 3000，因為它和其他 Unraid 應用衝突得實在太頻繁。想換別的連接埠，只要空著都行。

Przycisk WebUI na karcie Docker otwiera http://your-unraid-host:3006. Port 3006 na hoście to domyślna wartość szablonu, zmapowana na port 3000 w kontenerze. Szablon celowo omija 3000 po stronie hosta, bo ten tak często zderza się z innymi aplikacjami Unraida. Jeśli chcesz inny, zadziała dowolny wolny port.

Le bouton WebUI de l'onglet Docker ouvre http://your-unraid-host:3006. Le port hôte 3006 est la valeur par défaut du template, mappée sur le port 3000 du container. Le template évite délibérément le 3000 sur l'hôte parce qu'il entre si souvent en conflit avec d'autres applications Unraid. N'importe quel port libre convient si vous en voulez un autre.

Il pulsante WebUI nella scheda Docker apre http://your-unraid-host:3006. La porta host 3006 è il default del template, mappata sulla porta 3000 del container. Il template evita di proposito la 3000 sull'host perché va in conflitto con altre app Unraid troppo spesso. Se ne vuoi una diversa, va bene qualsiasi porta libera.

Der WebUI-Button im Docker-Tab öffnet http://your-unraid-host:3006. Host-Port 3006 ist die Voreinstellung des Templates, gemappt auf Container-Port 3000. Das Template meidet 3000 auf dem Host absichtlich, weil er so oft mit anderen Unraid-Apps kollidiert. Wenn du einen anderen willst, geht jeder freie Port.

Tombol WebUI di tab Docker membuka http://your-unraid-host:3006. Port host 3006 adalah default template, dipetakan ke port container 3000. Template ini sengaja menghindari 3000 di host karena port itu terlalu sering bentrok dengan aplikasi Unraid lain. Port kosong mana pun bisa dipakai kalau Anda ingin yang lain.

O botão WebUI na aba Docker abre http://your-unraid-host:3006. A porta 3006 no host é o padrão do template, mapeada para a porta 3000 do container. O template evita de propósito a 3000 no host porque ela colide com outros apps do Unraid com muita frequência. Qualquer porta livre funciona se você quiser outra.

Sign in with the email and password you typed into the form.

Entra con el correo y la contraseña que escribiste en el formulario.

フォームに入力したメールアドレスとパスワードでサインインします。

Войдите с почтой и паролем, которые вы вписали в форму.

فارم میں لکھی ہوئی ای میل اور پاس ورڈ سے سائن اِن کریں۔

用你在表单里填的邮箱和密码登录。

用你在表單裡填的電子郵件和密碼登入。

Zaloguj się e-mailem i hasłem, które wpisałeś w formularzu.

Connectez-vous avec l'e-mail et le mot de passe que vous avez saisis dans le formulaire.

Accedi con l'email e la password che hai digitato nel modulo.

Melde dich mit der E-Mail-Adresse und dem Passwort an, die du ins Formular getippt hast.

Masuk dengan email dan password yang Anda ketik di formulir.

Entre com o e-mail e a senha que você digitou no formulário.

What to back up

Qué respaldar

バックアップすべきもの

Что бэкапить

کس چیز کا بیک اپ لینا ہے

该备份什么

該備份什麼

Co obejmować kopią zapasową

Ce qu'il faut sauvegarder

Cosa mettere in backup

Was du sichern solltest

Apa yang perlu di-backup

O que fazer backup

App data is /mnt/user/appdata/libredb-studio, mapped to /app/data. That directory holds the SQLite store with your saved connections and query history, and it is what survives a container update or recreate. Back up that directory and keep your credentials somewhere separate.

Los datos de la aplicación están en /mnt/user/appdata/libredb-studio, mapeado a /app/data. Ese directorio contiene el almacén SQLite con tus conexiones guardadas y el historial de consultas, y es lo que sobrevive a una actualización o a una recreación del contenedor. Respalda ese directorio y guarda tus credenciales en otro sitio.

アプリのデータは /mnt/user/appdata/libredb-studio にあり、/app/data に対応づけられています。このディレクトリに、保存済みの接続とクエリ履歴が入った SQLite ストアが置かれていて、コンテナの更新や作り直しを越えて残るのもここです。このディレクトリをバックアップし、認証情報は別の場所に保管してください。

Данные приложения лежат в /mnt/user/appdata/libredb-studio, отображённом на /app/data. В этом каталоге находится хранилище SQLite с сохранёнными подключениями и историей запросов, и именно оно переживает обновление или пересоздание контейнера. Бэкапьте этот каталог, а учётные данные держите отдельно.

ایپ کا ڈیٹا /mnt/user/appdata/libredb-studio میں ہے، جو /app/data سے منسلک ہے۔ اسی ڈائریکٹری میں وہ SQLite اسٹور ہے جس میں آپ کے محفوظ کنکشن اور کوئری کی تاریخ ہے، اور کنٹینر کی اپ ڈیٹ یا دوبارہ تخلیق کے بعد یہی باقی رہتا ہے۔ اس ڈائریکٹری کا بیک اپ لیں اور سندات الگ کہیں محفوظ رکھیں۔

应用数据在 /mnt/user/appdata/libredb-studio，映射到 /app/data。这个目录里存着 SQLite 库，包含你保存的连接和查询历史，也正是它能熬过容器更新或重建。备份这个目录，并把凭据另外保管。

應用資料在 /mnt/user/appdata/libredb-studio，映射到 /app/data。這個目錄裡存著 SQLite 庫，包含你儲存的連線和查詢歷史，也正是它能熬過容器更新或重建。備份這個目錄，並把認證資訊另外保管。

Dane aplikacji leżą w /mnt/user/appdata/libredb-studio, zmapowanym na /app/data. Ten katalog trzyma magazyn SQLite z twoimi zapisanymi połączeniami i historią zapytań i to on przeżywa aktualizację albo odtworzenie kontenera. Rób kopię zapasową tego katalogu, a dane logowania trzymaj gdzie indziej.

Les données de l'application sont dans /mnt/user/appdata/libredb-studio, mappé sur /app/data. Ce répertoire contient le store SQLite avec vos connexions enregistrées et l'historique des requêtes, et c'est lui qui survit à une mise à jour ou à une recréation du container. Sauvegardez ce répertoire et gardez vos identifiants ailleurs.

I dati dell'app stanno in /mnt/user/appdata/libredb-studio, mappata su /app/data. Quella directory contiene lo store SQLite con le tue connessioni salvate e la cronologia delle query, ed è quello che sopravvive a un aggiornamento o a una ricreazione del container. Fai il backup di quella directory e tieni le credenziali da un'altra parte.

Die App-Daten liegen unter /mnt/user/appdata/libredb-studio, gemappt auf /app/data. In diesem Verzeichnis liegt der SQLite-Speicher mit deinen gespeicherten Verbindungen und dem Abfrageverlauf, und es ist das, was ein Container-Update oder ein Neuanlegen überlebt. Sichere dieses Verzeichnis und leg deine Zugangsdaten getrennt davon ab.

Data aplikasi ada di /mnt/user/appdata/libredb-studio, dipetakan ke /app/data. Direktori itu memuat store SQLite berisi koneksi tersimpan dan riwayat query Anda, dan itulah yang selamat dari update atau pembuatan ulang container. Backup direktori itu dan simpan kredensial Anda di tempat yang terpisah.

Os dados do app ficam em /mnt/user/appdata/libredb-studio, mapeado para /app/data. Esse diretório guarda o store SQLite com as suas conexões salvas e o histórico de consultas, e é o que sobrevive a uma atualização ou recriação do container. Faça backup desse diretório e guarde suas credenciais em outro lugar.

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

TrueNAS SCALE

Community train. Catalog version 1.0.11 ships app version 0.16.0, two releases behind the 0.17.0 these pages describe.

Tren community. La versión de catálogo 1.0.11 entrega la versión 0.16.0 de la aplicación, dos releases por detrás de la 0.17.0 que describen estas páginas.

community トレイン。カタログ版 1.0.11 が配布するアプリのバージョンは 0.16.0 で、これらのページが説明している 0.17.0 より二つ前のリリースです。

Ветка community. Версия каталога 1.0.11 поставляет приложение 0.16.0, то есть на два выпуска позади 0.17.0, о которой эти страницы.

community ٹرین۔ کیٹلاگ ورژن 1.0.11 ایپ کا ورژن 0.16.0 دیتا ہے، جو ان صفحات کی 0.17.0 سے دو ریلیز پیچھے ہے۔

community 通道。目录版本 1.0.11 发的应用版本是 0.16.0，比这些页面讲的 0.17.0 旧两个版本。

community 通道。目錄版本 1.0.11 發的應用版本是 0.16.0，比這些頁面講的 0.17.0 舊兩個版本。

Train community. Wersja katalogowa 1.0.11 wydaje wersję aplikacji 0.16.0, o dwa wydania za 0.17.0, którą opisują te strony.

Train community. La version de catalogue 1.0.11 livre la version applicative 0.16.0, deux releases derrière la 0.17.0 que ces pages décrivent.

Train community. La versione di catalogo 1.0.11 distribuisce la versione applicativa 0.16.0, due release indietro rispetto alla 0.17.0 che queste pagine descrivono.

Community-Train. Katalogversion 1.0.11 liefert App-Version 0.16.0, zwei Releases hinter dem 0.17.0, das diese Seiten beschreiben.

Train community. Katalog versi 1.0.11 mengirim aplikasi versi 0.16.0, dua rilis di belakang 0.17.0 yang dibahas halaman-halaman ini.

Train community. A versão 1.0.11 do catálogo entrega a versão de app 0.16.0, duas releases atrás da 0.17.0 que estas páginas descrevem.

What you need

Qué necesitas

必要なもの

Что нужно

آپ کو کیا درکار ہے

你需要什么

你需要什麼

Czego potrzebujesz

Ce qu'il vous faut

Cosa ti serve

Was du brauchst

Yang Anda perlukan

O que você precisa

TrueNAS SCALE with its apps catalog, and a dataset you are happy to hand to the app.

TrueNAS SCALE con su catálogo de aplicaciones, y un dataset que no te importe entregar a la aplicación.

アプリカタログのある TrueNAS SCALE と、アプリに渡してかまわないデータセット。

TrueNAS SCALE с его каталогом приложений и датасет, который вам не жалко отдать приложению.

TrueNAS SCALE اپنے ایپس کیٹلاگ کے ساتھ، اور ایک ڈیٹاسیٹ جو ایپ کے حوالے کرنے میں آپ کو اعتراض نہ ہو۔

带应用目录的 TrueNAS SCALE，以及一个你愿意交给这个应用的数据集。

帶應用目錄的 TrueNAS SCALE，以及一個你願意交給這個應用的資料集。

TrueNAS SCALE z jego katalogiem aplikacji i dataset, który bez żalu oddasz aplikacji.

TrueNAS SCALE avec son catalogue d'applications, et un dataset que vous acceptez de confier à l'application.

TrueNAS SCALE con il suo catalogo di app, e un dataset che ti va di affidare all'app.

TrueNAS SCALE mit seinem Apps-Katalog und ein Dataset, das du der App guten Gewissens überlässt.

TrueNAS SCALE dengan katalog apps-nya, dan satu dataset yang rela Anda serahkan ke aplikasi ini.

TrueNAS SCALE com o catálogo de apps, e um dataset que você não se importe de entregar ao app.

The clicks

Los clics

操作手順

Куда нажимать

کہاں کلک کرنا ہے

点击步骤

點選步驟

Kliknięcia

Les clics

I clic

Die Klicks

Klik-kliknya

Os cliques

1. Apps, then Discover Apps, then search for LibreDB Studio.
2. Press Install.
3. Under the LibreDB section, set Admin Email, Admin Password (8 characters minimum) and JWT Secret (32 characters minimum).
4. Under Storage, choose an ix-volume or point it at a host path for the data directory.
5. Leave the rest alone and install.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

The WebUI port defaults to 30469, not 3000, which is normal for the TrueNAS apps catalog. Open the portal link from the app card, or go to http://your-nas:30469 directly.

El puerto de la WebUI es 30469 por defecto, no 3000, lo cual es normal en el catálogo de aplicaciones de TrueNAS. Abre el enlace del portal desde la tarjeta de la aplicación, o ve directamente a http://your-nas:30469.

WebUI のポートは既定で 3000 ではなく 30469 です。TrueNAS のアプリカタログでは普通のことです。アプリカードのポータルリンクを開くか、直接 http://your-nas:30469 へ行ってください。

Порт WebUI по умолчанию задан как 30469, а не 3000, и для каталога приложений TrueNAS это нормально. Откройте ссылку портала с карточки приложения или зайдите напрямую на http://your-nas:30469.

WebUI کا پورٹ طے شدہ طور پر 30469 ہوتا ہے، 3000 نہیں، اور TrueNAS کے ایپس کیٹلاگ میں یہ معمول کی بات ہے۔ ایپ کارڈ سے پورٹل کا لنک کھولیں، یا براہِ راست http://your-nas:30469 پر جائیں۔

WebUI 端口默认是 30469 而不是 3000，这在 TrueNAS 应用目录里是正常的。从应用卡片上打开门户链接，或者直接访问 http://your-nas:30469。

WebUI 連接埠預設是 30469 而不是 3000，這在 TrueNAS 應用目錄裡是正常的。從應用卡片上打開入口連結，或者直接存取 http://your-nas:30469。

Port WebUI to domyślnie 30469, a nie 3000, co dla katalogu aplikacji TrueNAS jest normalne. Otwórz link do portalu z kafelka aplikacji albo wejdź prosto na http://your-nas:30469.

Le port WebUI est par défaut 30469, pas 3000, ce qui est normal pour le catalogue d'applications TrueNAS. Ouvrez le lien du portail depuis la carte de l'application, ou allez directement sur http://your-nas:30469.

La porta della WebUI è di default 30469, non 3000, il che è normale per il catalogo di app di TrueNAS. Apri il link al portale dalla card dell'app, oppure vai direttamente su http://your-nas:30469.

Der WebUI-Port ist standardmäßig 30469, nicht 3000, was für den TrueNAS-Apps-Katalog normal ist. Öffne den Portal-Link auf der App-Karte oder geh direkt auf http://your-nas:30469.

Port WebUI defaultnya 30469, bukan 3000, dan itu normal untuk katalog apps TrueNAS. Buka tautan portal dari kartu aplikasinya, atau langsung ke http://your-nas:30469.

A porta da WebUI vem como 30469, não 3000, o que é normal no catálogo de apps do TrueNAS. Abra o link do portal no card do app, ou vá direto em http://your-nas:30469.

The app runs as uid and gid 568, which is the standard apps user, so the dataset you pick needs to be readable and writable by it. TrueNAS handles that for you if you use an ix-volume.

La aplicación se ejecuta con uid y gid 568, que es el usuario estándar de apps, así que el dataset que elijas tiene que ser legible y escribible por él. TrueNAS se encarga de eso por ti si usas un ix-volume.

アプリは uid と gid が 568 で動きます。これは標準のアプリ用ユーザーなので、選んだデータセットはこのユーザーから読み書きできる必要があります。ix-volume を使えば TrueNAS が面倒を見てくれます。

Приложение работает с uid и gid 568, это стандартный пользователь приложений, так что выбранный датасет должен быть доступен ему на чтение и запись. Если вы используете ix-volume, TrueNAS делает это за вас.

ایپ uid اور gid 568 کے ساتھ چلتی ہے، جو ایپس کا معیاری صارف ہے، اس لیے آپ جو ڈیٹاسیٹ چنیں وہ اس کے لیے پڑھنے اور لکھنے کے قابل ہونا چاہیے۔ ix-volume استعمال کریں تو TrueNAS یہ کام خود سنبھال لیتا ہے۔

应用以 uid 和 gid 568 运行，这是标准的应用用户，所以你选的数据集必须能被它读写。如果你用 ix-volume，TrueNAS 会替你处理好。

應用以 uid 和 gid 568 執行，這是標準的應用使用者，所以你選的資料集必須能被它讀寫。如果你用 ix-volume，TrueNAS 會替你處理好。

Aplikacja działa jako uid i gid 568, czyli standardowy użytkownik aplikacji, więc dataset, który wybierzesz, musi być dla niego do odczytu i zapisu. TrueNAS załatwia to za ciebie, jeśli użyjesz ix-volume.

L'application tourne sous l'uid et le gid 568, qui est l'utilisateur standard des applications, donc le dataset que vous choisissez doit être lisible et inscriptible par lui. TrueNAS s'en charge pour vous si vous utilisez un ix-volume.

L'app gira come uid e gid 568, che è l'utente standard delle app, quindi il dataset che scegli deve essere leggibile e scrivibile da quell'utente. Se usi un ix-volume ci pensa TrueNAS per te.

Die App läuft unter uid und gid 568, dem Standard-Apps-Benutzer, das Dataset, das du wählst, muss für ihn also les- und schreibbar sein. Mit einem ix-volume erledigt TrueNAS das für dich.

Aplikasi berjalan sebagai uid dan gid 568, yaitu user apps standar, jadi dataset yang Anda pilih harus bisa dibaca dan ditulis olehnya. TrueNAS mengurus itu untuk Anda kalau Anda memakai ix-volume.

O app roda com uid e gid 568, que é o usuário padrão dos apps, então o dataset que você escolher precisa ser legível e gravável por ele. O TrueNAS resolve isso para você se usar um ix-volume.

Adding your own settings

Añadir tus propios ajustes

自分の設定を足す

Добавить свои настройки

اپنی ترتیبات شامل کرنا

加上你自己的设置

加上你自己的設定

Dokładanie własnych ustawień

Ajouter vos propres réglages

Aggiungere le tue impostazioni

Eigene Einstellungen hinzufügen

Menambahkan setelan Anda sendiri

Adicionar suas próprias configurações

The install form has an Additional Environment Variables list, for names the template does not already set itself. The AI features need a key rather than a full description: LLM_API_KEY alone is enough, because LLM_PROVIDER defaults to Gemini and LLM_MODEL defaults per provider. Name them only to choose something else, and use LLM_API_URL instead of a key for an OpenAI-compatible endpoint. Single sign-on goes here too, as NEXT_PUBLIC_AUTH_PROVIDER=oidc with the OIDC settings beside it.

El formulario de instalación tiene una lista Additional Environment Variables, para nombres que la plantilla no fija ya por su cuenta. Las funciones de IA necesitan una clave más que una descripción completa: basta con LLM_API_KEY, porque LLM_PROVIDER usa Gemini por defecto y LLM_MODEL tiene un valor por defecto por proveedor. Nómbralos solo si quieres elegir otra cosa, y usa LLM_API_URL en lugar de una clave para un endpoint compatible con OpenAI. El inicio de sesión único también va aquí, como NEXT_PUBLIC_AUTH_PROVIDER=oidc con los ajustes OIDC al lado.

インストールフォームには Additional Environment Variables の一覧があります。テンプレートが自分で設定していない名前は、ここに入れます。AI 機能に必要なのは細かな指定より鍵のほうで、LLM_API_KEY だけで足ります。LLM_PROVIDER は既定で Gemini、LLM_MODEL はプロバイダーごとの既定値があるからです。別のものを選びたいときにだけ指定してください。OpenAI 互換のエンドポイントなら、鍵の代わりに LLM_API_URL を使います。シングルサインオンもここで、NEXT_PUBLIC_AUTH_PROVIDER=oidc と OIDC の設定を並べて指定します。

В форме установки есть список Additional Environment Variables: для имён, которые шаблон не задаёт сам. Функциям ИИ нужен скорее ключ, чем полное описание: достаточно одного LLM_API_KEY, потому что LLM_PROVIDER по умолчанию Gemini, а у LLM_MODEL есть значение по умолчанию для каждого провайдера. Указывайте их, только если хотите выбрать другое, а для OpenAI-совместимого эндпоинта вместо ключа используйте LLM_API_URL. Единый вход задаётся здесь же: NEXT_PUBLIC_AUTH_PROVIDER=oidc и рядом настройки OIDC.

انسٹال فارم میں Additional Environment Variables کی فہرست ہے، اُن ناموں کے لیے جو ٹیمپلیٹ خود مقرر نہیں کرتا۔ اے آئی خصوصیات کو پوری تفصیل سے زیادہ ایک کلید درکار ہے: اکیلا LLM_API_KEY کافی ہے، کیونکہ LLM_PROVIDER طے شدہ طور پر Gemini ہے اور LLM_MODEL کی ہر فراہم کنندہ کے لیے اپنی طے شدہ قدر ہے۔ انہیں صرف تب لکھیں جب کچھ اور چننا ہو، اور OpenAI سے ہم آہنگ اینڈ پوائنٹ کے لیے کلید کے بجائے LLM_API_URL استعمال کریں۔ سنگل سائن آن بھی یہیں جاتا ہے، NEXT_PUBLIC_AUTH_PROVIDER=oidc اور ساتھ OIDC کی ترتیبات کے طور پر۔

安装表单里有一份 Additional Environment Variables 列表，用来填模板自己没设的那些名字。AI 功能要的是一把钥匙，而不是一整套描述：只给 LLM_API_KEY 就够了，因为 LLM_PROVIDER 默认是 Gemini，LLM_MODEL 也按提供方各有默认值。只有想换别的时候才点名它们；要接兼容 OpenAI 的端点，就用 LLM_API_URL 代替钥匙。单点登录也写在这里，形式是 NEXT_PUBLIC_AUTH_PROVIDER=oidc 外加旁边的 OIDC 设置。

安裝表單裡有一份 Additional Environment Variables 列表，用來填範本自己沒設的那些名字。AI 功能要的是一把鑰匙，而不是一整套描述：只給 LLM_API_KEY 就夠了，因為 LLM_PROVIDER 預設是 Gemini，LLM_MODEL 也按提供者各有預設值。只有想換別的時候才點名它們；要接相容 OpenAI 的端點，就用 LLM_API_URL 代替鑰匙。單一登入也寫在這裡，形式是 NEXT_PUBLIC_AUTH_PROVIDER=oidc 外加旁邊的 OIDC 設定。

Formularz instalacji ma listę Additional Environment Variables na nazwy, których szablon sam nie ustawia. Funkcje AI potrzebują klucza, a nie pełnego opisu: wystarczy samo LLM_API_KEY, bo LLM_PROVIDER domyślnie wskazuje Gemini, a LLM_MODEL ma wartość domyślną zależną od dostawcy. Wpisuj je tylko wtedy, gdy chcesz wybrać coś innego, a zamiast klucza użyj LLM_API_URL dla endpointu zgodnego z OpenAI. Logowanie jednokrotne też idzie tutaj, jako NEXT_PUBLIC_AUTH_PROVIDER=oidc z ustawieniami OIDC obok.

Le formulaire d'installation a une liste Additional Environment Variables, pour les noms que le template ne définit pas déjà lui-même. Les fonctions IA ont besoin d'une clé plutôt que d'une description complète : LLM_API_KEY suffit à lui seul, parce que LLM_PROVIDER vaut Gemini par défaut et que LLM_MODEL a une valeur par défaut propre à chaque fournisseur. Ne les nommez que pour choisir autre chose, et utilisez LLM_API_URL à la place d'une clé pour un endpoint compatible OpenAI. L'authentification unique se place ici aussi, sous la forme NEXT_PUBLIC_AUTH_PROVIDER=oidc avec les réglages OIDC à côté.

Il modulo di installazione ha una lista Additional Environment Variables, per i nomi che il template non imposta già da sé. Alle funzioni AI serve una chiave più che una descrizione completa: LLM_API_KEY da sola basta, perché LLM_PROVIDER vale Gemini di default e LLM_MODEL ha un default per ogni provider. Nominali solo per scegliere qualcos'altro, e per un endpoint compatibile con OpenAI usa LLM_API_URL invece di una chiave. Anche il single sign-on va qui, come NEXT_PUBLIC_AUTH_PROVIDER=oidc con accanto le impostazioni OIDC.

Im Installationsformular gibt es eine Liste Additional Environment Variables, für Namen, die das Template nicht schon selbst setzt. Die KI-Funktionen brauchen einen Schlüssel statt einer vollständigen Beschreibung: LLM_API_KEY allein reicht, denn LLM_PROVIDER steht standardmäßig auf Gemini und LLM_MODEL hat pro Anbieter eine Voreinstellung. Nenn sie nur, wenn du etwas anderes wählen willst, und nimm für einen OpenAI-kompatiblen Endpunkt LLM_API_URL statt eines Schlüssels. Single Sign-on kommt auch hierher, als NEXT_PUBLIC_AUTH_PROVIDER=oidc mit den OIDC-Einstellungen daneben.

Formulir instalasinya punya daftar Additional Environment Variables, untuk nama-nama yang belum diset sendiri oleh template. Fitur AI butuh sebuah kunci, bukan deskripsi lengkap: LLM_API_KEY saja sudah cukup, karena LLM_PROVIDER defaultnya Gemini dan LLM_MODEL punya default per provider. Sebut keduanya hanya kalau ingin memilih yang lain, dan pakai LLM_API_URL alih-alih sebuah kunci untuk endpoint yang kompatibel dengan OpenAI. Single sign-on juga masuk ke sini, sebagai NEXT_PUBLIC_AUTH_PROVIDER=oidc dengan setelan OIDC di sebelahnya.

O formulário de instalação tem uma lista Additional Environment Variables, para nomes que o template já não define sozinho. Os recursos de IA precisam de uma chave, não de uma descrição completa: LLM_API_KEY sozinha basta, porque LLM_PROVIDER tem Gemini como padrão e LLM_MODEL tem um padrão por provedor. Só nomeie os dois para escolher outra coisa, e use LLM_API_URL em vez de uma chave para um endpoint compatível com OpenAI. Single sign-on também entra aqui, como NEXT_PUBLIC_AUTH_PROVIDER=oidc com as configurações de OIDC do lado.

An entry in the CasaOS App Store. Host port 3016.

Una entrada en la App Store de CasaOS. Puerto de host 3016.

CasaOS アプリストアの項目。ホスト側ポートは 3016。

Запись в App Store CasaOS. Порт на хосте 3016.

CasaOS ایپ اسٹور میں ایک اندراج۔ ہوسٹ پورٹ 3016۔

CasaOS 应用商店里的一个条目。主机端口 3016。

CasaOS 應用商店裡的一個項目。主機連接埠 3016。

Wpis w CasaOS App Store. Port 3016 na hoście.

Une entrée dans le CasaOS App Store. Port hôte 3016.

Una voce nell'App Store di CasaOS. Porta host 3016.

Ein Eintrag im CasaOS App Store. Host-Port 3016.

Sebuah entri di CasaOS App Store. Port host 3016.

Uma entrada na CasaOS App Store. Porta 3016 no host.

Replace the two values it ships with

Sustituye los dos valores con los que viene

同梱の二つの値は入れ替える

Замените два значения, с которыми он приходит

ساتھ آنے والی دو قدریں بدلیں

把它自带的两个值换掉

把它自帶的兩個值換掉

Podmień dwie wartości, z którymi przychodzi

Remplacez les deux valeurs qu'il livre

Sostituisci i due valori con cui arriva

Ersetz die zwei Werte, die er mitbringt

Ganti dua nilai yang ia bawa

Troque os dois valores que ela já traz

The store entry carries a JWT_SECRET and an administrator password already filled in, and both work. The secret is sixty-three characters, comfortably over the application's thirty-two character minimum, so it starts silently rather than being refused. That is worth stopping for: the value is published in a public catalogue, and under sqlite storage the same value also derives the key that encrypts your saved database passwords. Change both in the install form before you press install, not after.

La entrada de la tienda trae un JWT_SECRET y una contraseña de administrador ya rellenados, y ambos funcionan. El secreto tiene sesenta y tres caracteres, holgadamente por encima del mínimo de treinta y dos de la aplicación, así que arranca en silencio en lugar de ser rechazado. Vale la pena detenerse aquí: el valor está publicado en un catálogo público y, con almacenamiento sqlite, ese mismo valor deriva además la clave que cifra tus contraseñas de base de datos guardadas. Cambia los dos en el formulario de instalación antes de pulsar instalar, no después.

ストアの項目には JWT_SECRET と管理者パスワードがあらかじめ入っており、どちらも有効です。秘密鍵は六十三文字あり、アプリの下限である三十二文字を余裕で超えるため、拒否されずに静かに起動します。ここは立ち止まる価値があります。その値は公開カタログに掲載されており、さらに sqlite ストレージでは同じ値から、保存したデータベースのパスワードを暗号化する鍵も導かれます。インストールを押す前に、フォームで両方を変えてください。押した後ではありません。

Запись в магазине приходит с уже заполненными JWT_SECRET и паролем администратора, и оба работают. Секрет длиной шестьдесят три символа, с запасом выше тридцати двух, которые требует приложение, поэтому оно запускается молча, а не отказывается. На этом стоит остановиться: значение опубликовано в общедоступном каталоге, а при хранилище sqlite из того же значения выводится ключ, которым шифруются ваши сохранённые пароли к базам. Поменяйте оба в форме установки до того, как нажмёте установить, а не после.

اسٹور کے اندراج میں JWT_SECRET اور منتظم کا پاس ورڈ پہلے سے بھرے آتے ہیں، اور دونوں کام کرتے ہیں۔ راز تریسٹھ حروف کا ہے، ایپ کی بتیس حروف کی حد سے آرام سے اوپر، سو یہ رد ہونے کے بجائے خاموشی سے چل پڑتا ہے۔ یہاں رکنا بنتا ہے: یہ قدر ایک عوامی کیٹلاگ میں چھپی ہوئی ہے، اور sqlite ذخیرے کے ساتھ یہی قدر وہ کلید بھی نکالتی ہے جو آپ کے محفوظ ڈیٹابیس پاس ورڈز کو خفیہ کرتی ہے۔ انسٹال دبانے سے پہلے فارم میں دونوں بدلیں، بعد میں نہیں۔

商店条目带着一个已经填好的 JWT_SECRET 和管理员密码，两者都能用。那个密钥有六十三个字符，远超应用要求的三十二，所以它不会被拒绝，而是悄悄就起来了。这里值得停一下：这个值发布在一个公开目录里，而且在 sqlite 存储下，同一个值还会派生出加密你已保存数据库密码的那把钥匙。在按下安装之前就在安装表单里把两者都改掉，不是之后。

商店項目帶著一個已經填好的 JWT_SECRET 和管理員密碼，兩者都能用。那個金鑰有六十三個字元，遠超應用要求的三十二，所以它不會被拒絕，而是悄悄就起來了。這裡值得停一下：這個值發布在一個公開目錄裡，而且在 sqlite 儲存下，同一個值還會派生出加密你已儲存資料庫密碼的那把鑰匙。在按下安裝之前就在安裝表單裡把兩者都改掉，不是之後。

Wpis w sklepie niesie już wypełnione JWT_SECRET i hasło administratora, i oba działają. Sekret ma sześćdziesiąt trzy znaki, wygodnie ponad wymagane przez aplikację minimum trzydziestu dwóch, więc start przechodzi po cichu, zamiast zostać odrzucony. Przy tym warto się zatrzymać: ta wartość jest opublikowana w publicznym katalogu, a przy magazynie sqlite z tej samej wartości wyprowadzany jest klucz szyfrujący twoje zapisane hasła do baz danych. Zmień obie w formularzu instalacji, zanim naciśniesz install, a nie po.

L'entrée du store porte un JWT_SECRET et un mot de passe administrateur déjà remplis, et les deux fonctionnent. Le secret fait soixante-trois caractères, confortablement au-dessus du minimum de trente-deux caractères de l'application, donc elle démarre silencieusement au lieu d'être refusée. Cela vaut la peine de s'y arrêter : la valeur est publiée dans un catalogue public, et sous le stockage sqlite cette même valeur dérive aussi la clé qui chiffre les mots de passe de vos bases enregistrées. Changez les deux dans le formulaire d'installation avant d'appuyer sur install, pas après.

La voce dello store porta un JWT_SECRET e una password di amministratore già compilati, e funzionano entrambi. Il segreto è di sessantatré caratteri, ben oltre il minimo di trentadue dell'applicazione, quindi parte in silenzio invece di essere rifiutato. Su questo vale la pena fermarsi: il valore è pubblicato in un catalogo pubblico, e con lo storage sqlite dallo stesso valore deriva anche la chiave che cifra le password dei tuoi database salvate. Cambiali tutti e due nel modulo di installazione prima di premere install, non dopo.

Der Store-Eintrag bringt ein JWT_SECRET und ein Administrator-Passwort schon ausgefüllt mit, und beide funktionieren. Das Secret hat dreiundsechzig Zeichen, deutlich über dem Minimum von zweiunddreißig Zeichen der Anwendung, sie startet also stillschweigend, statt es abzulehnen. Dabei lohnt es sich innezuhalten: der Wert steht in einem öffentlichen Katalog, und unter sqlite-Speicher leitet derselbe Wert auch den Schlüssel ab, der deine gespeicherten Datenbankpasswörter verschlüsselt. Ändere beide im Installationsformular, bevor du auf Installieren drückst, nicht danach.

Entri di store itu membawa JWT_SECRET dan sebuah password administrator yang sudah terisi, dan keduanya berfungsi. Secret-nya enam puluh tiga karakter, jauh di atas minimum tiga puluh dua karakter aplikasi, jadi ia start tanpa suara alih-alih ditolak. Itu layak dihentikan sejenak: nilai itu dipublikasikan di katalog publik, dan di bawah penyimpanan sqlite nilai yang sama juga menurunkan kunci yang mengenkripsi password database yang Anda simpan. Ganti keduanya di formulir instalasi sebelum Anda menekan install, bukan sesudahnya.

A entrada da loja carrega um JWT_SECRET e uma senha de administrador já preenchidos, e os dois funcionam. O segredo tem sessenta e três caracteres, folgadamente acima do mínimo de trinta e dois da aplicação, então ela sobe em silêncio em vez de recusar. Vale parar nisso: o valor está publicado num catálogo público, e com armazenamento sqlite o mesmo valor também deriva a chave que criptografa as senhas de banco que você salva. Troque os dois no formulário de instalação antes de apertar install, não depois.

What it gets right

Qué hace bien

正しくできていること

Что сделано правильно

یہ کیا ٹھیک کرتا ہے

它做对了什么

它做對了什麼

Co robi dobrze

Ce qu'il fait bien

Cosa fa bene

Was er richtig macht

Apa yang sudah benar di sini

O que ela acerta

It sets AUTH_COOKIE_SECURE to false, which is the right call for a box reached over plain HTTP on a local network, and its container health check points at /api/db/health rather than at the root. The TrueNAS template gets both of those right too. The Unraid one sets the cookie variable but defines no health check at all, and the image carries none of its own to fall back on. What is unique to CasaOS is where the image comes from: it pulls libredb/libredb-studio from Docker Hub rather than the registry every other path uses. It installs 0.15.0 today, behind the 0.17.0 these pages describe.

Pone AUTH_COOKIE_SECURE a false, que es lo correcto para una máquina a la que se llega por HTTP plano en una red local, y su comprobación de salud del contenedor apunta a /api/db/health y no a la raíz. La plantilla de TrueNAS también acierta en ambas cosas. La de Unraid pone la variable de la cookie pero no define ninguna comprobación de salud, y la imagen tampoco trae una propia a la que recurrir. Lo que sí es exclusivo de CasaOS es de dónde viene la imagen: descarga libredb/libredb-studio de Docker Hub en lugar del registro que usan todos los demás caminos. Hoy instala 0.15.0, por detrás de la 0.17.0 que describen estas páginas.

AUTH_COOKIE_SECURE を false に設定しており、ローカルネットワーク上の平文 HTTP で触る機械には正しい判断です。コンテナのヘルスチェックもルートではなく /api/db/health を指しています。TrueNAS のテンプレートも、この二点は同じく正しくできています。Unraid のものは Cookie の変数は設定しますが、ヘルスチェックはまったく定義しておらず、頼りにできるヘルスチェックはイメージ側にもありません。CasaOS だけの特徴はイメージの出どころです。他のすべての経路が使うレジストリではなく、Docker Hub から libredb/libredb-studio を取得します。今日入るのは 0.15.0 で、これらのページが説明している 0.17.0 より古いものです。

Он ставит AUTH_COOKIE_SECURE в false (верное решение для машины, доступной по обычному HTTP в локальной сети), и его проверка состояния контейнера указывает на /api/db/health, а не на корень. Шаблон TrueNAS делает и то и другое правильно тоже. В шаблоне Unraid переменная для куки задана, но проверки состояния нет вовсе, и в самом образе её тоже нет, чтобы на неё опереться. Уникально для CasaOS другое: откуда берётся образ. Он тянет libredb/libredb-studio с Docker Hub, а не из реестра, которым пользуются все остальные пути. Сегодня он ставит 0.15.0, то есть позади 0.17.0, о которой эти страницы.

یہ AUTH_COOKIE_SECURE کو false کرتا ہے، اور مقامی نیٹ ورک پر سادہ HTTP سے پہنچی جانے والی مشین کے لیے یہی درست فیصلہ ہے؛ اس کی کنٹینر ہیلتھ چیک بھی جڑ کے بجائے /api/db/health کی طرف ہے۔ TrueNAS کا ٹیمپلیٹ بھی یہ دونوں باتیں ٹھیک کرتا ہے۔ Unraid والا کوکی کا متغیر تو مقرر کرتا ہے مگر ہیلتھ چیک سرے سے بیان ہی نہیں کرتا، اور امیج کے پاس بھی اپنی کوئی ہیلتھ چیک نہیں جس پر بھروسا کیا جا سکے۔ CasaOS میں جو منفرد ہے وہ یہ کہ امیج کہاں سے آتی ہے: یہ libredb/libredb-studio کو Docker Hub سے لیتا ہے، اُس رجسٹری سے نہیں جو باقی سب راستے استعمال کرتے ہیں۔ آج یہ 0.15.0 نصب کرتا ہے، جو ان صفحات کی 0.17.0 سے پیچھے ہے۔

它把 AUTH_COOKIE_SECURE 设成 false，对于一台在局域网内走明文 HTTP 访问的机器来说这是对的；它的容器健康检查也指向 /api/db/health 而不是根路径。TrueNAS 的模板这两点也都做对了。Unraid 那个设了 cookie 变量，但根本没定义健康检查，镜像自身也没有一个可以兜底的。CasaOS 真正独有的是镜像的来源：它从 Docker Hub 拉 libredb/libredb-studio，而不是其他所有路径都在用的那个镜像仓库。它今天装的是 0.15.0，比这些页面讲的 0.17.0 旧。

它把 AUTH_COOKIE_SECURE 設成 false，對於一台在區域網路內走明文 HTTP 存取的機器來說這是對的；它的容器健康檢查也指向 /api/db/health 而不是根路徑。TrueNAS 的範本這兩點也都做對了。Unraid 那個設了 cookie 變數，但根本沒定義健康檢查，映像檔自身也沒有一個可以兜底的。CasaOS 真正獨有的是映像檔的來源：它從 Docker Hub 拉 libredb/libredb-studio，而不是其他所有路徑都在用的那個映像檔儲存庫。它今天裝的是 0.15.0，比這些頁面講的 0.17.0 舊。

Ustawia AUTH_COOKIE_SECURE na false, co jest słuszne dla maszyny, do której sięgasz po zwykłym HTTP w sieci lokalnej, a health check kontenera celuje w /api/db/health, a nie w root. Szablon TrueNAS też ma oba te punkty zrobione dobrze. Ten z Unraida ustawia zmienną ciasteczka, ale nie definiuje żadnego health checku, a obraz nie niesie własnego, na który dałoby się spaść. Unikalne dla CasaOS jest to, skąd bierze obraz: ciągnie libredb/libredb-studio z Docker Huba, a nie z rejestru, którego używa każda inna ścieżka. Dziś instaluje 0.15.0, czyli mniej niż 0.17.0 opisywana na tych stronach.

Il règle AUTH_COOKIE_SECURE sur false, ce qui est le bon choix pour une machine atteinte en HTTP simple sur un réseau local, et son health check de container pointe sur /api/db/health plutôt que sur la racine. Le template TrueNAS fait bien ces deux choses aussi. Celui d'Unraid définit la variable de cookie mais ne définit aucun health check, et l'image n'en porte aucun sur lequel se rabattre. Ce qui est propre à CasaOS, c'est la provenance de l'image : il tire libredb/libredb-studio depuis Docker Hub plutôt que depuis le registre qu'utilisent tous les autres chemins. Il installe aujourd'hui la 0.15.0, derrière la 0.17.0 que ces pages décrivent.

Imposta AUTH_COOKIE_SECURE a false, che è la scelta giusta per una macchina raggiunta in HTTP semplice su una rete locale, e il suo health check del container punta su /api/db/health invece che sulla radice. Anche il template TrueNAS azzecca tutte e due queste cose. Quello di Unraid imposta la variabile del cookie ma non definisce nessun health check, e l'immagine non ne porta uno suo su cui ripiegare. Quello che è unico di CasaOS è da dove viene l'immagine: scarica libredb/libredb-studio da Docker Hub invece che dal registry che usano tutte le altre strade. Oggi installa la 0.15.0, indietro rispetto alla 0.17.0 che queste pagine descrivono.

Er setzt AUTH_COOKIE_SECURE auf false, was für eine Maschine richtig ist, die im lokalen Netz über einfaches HTTP erreicht wird, und sein Container-Health-Check zeigt auf /api/db/health statt auf die Wurzel. Das TrueNAS-Template trifft beides ebenfalls. Das von Unraid setzt die Cookie-Variable, definiert aber überhaupt keinen Health-Check, und das Image bringt auch keinen eigenen mit, auf den man zurückfallen könnte. Einzig bei CasaOS ist, woher das Image kommt: es zieht libredb/libredb-studio von Docker Hub statt aus der Registry, die jeder andere Weg nimmt. Installiert wird heute 0.15.0, hinter dem 0.17.0, das diese Seiten beschreiben.

Ia men-set AUTH_COOKIE_SECURE ke false, dan itu pilihan yang tepat untuk mesin yang dijangkau lewat HTTP biasa di jaringan lokal, dan health check container-nya menunjuk ke /api/db/health, bukan ke root. Template TrueNAS juga benar di kedua hal itu. Yang Unraid men-set variabel cookie tetapi sama sekali tidak mendefinisikan health check, sementara image-nya sendiri tidak membawa satu pun sebagai cadangan. Yang khas pada CasaOS adalah dari mana image-nya berasal: ia menarik libredb/libredb-studio dari Docker Hub, bukan dari registry yang dipakai semua jalur lain. Hari ini ia memasang 0.15.0, di belakang 0.17.0 yang dibahas halaman-halaman ini.

Ela põe AUTH_COOKIE_SECURE em false, que é a decisão certa para uma máquina acessada por HTTP puro numa rede local, e o health check do container dela aponta para /api/db/health e não para a raiz. O template do TrueNAS acerta essas duas também. O do Unraid define a variável do cookie mas não define health check nenhum, e a imagem não traz um próprio para servir de reserva. O que é único do CasaOS é de onde vem a imagem: ele puxa libredb/libredb-studio do Docker Hub e não do registry que todos os outros caminhos usam. Hoje ele instala a 0.15.0, atrás da 0.17.0 que estas páginas descrevem.

An app in the YunoHost catalogue. No container; it runs under systemd on your own domain.

Una aplicación del catálogo de YunoHost. Sin contenedor; corre bajo systemd en tu propio dominio.

YunoHost のカタログにあるアプリ。コンテナはなく、自分のドメインで systemd の下で動きます。

Приложение из каталога YunoHost. Без контейнера; работает под systemd на вашем собственном домене.

YunoHost کی فہرست میں ایک ایپ۔ کوئی کنٹینر نہیں؛ یہ آپ کے اپنے ڈومین پر systemd کے تحت چلتی ہے۔

YunoHost 目录里的一个应用。没有容器；它在你自己的域名上、在 systemd 下跑。

YunoHost 目錄裡的一個應用。沒有容器；它在你自己的網域上、在 systemd 下跑。

Aplikacja z katalogu YunoHost. Bez kontenera; działa pod systemd na twojej własnej domenie.

Une application du catalogue YunoHost. Pas de container ; elle tourne sous systemd sur votre propre domaine.

Un'app nel catalogo di YunoHost. Niente container; gira sotto systemd sul tuo dominio.

Eine App im YunoHost-Katalog. Kein Container; sie läuft unter systemd auf deiner eigenen Domain.

Sebuah aplikasi di katalog YunoHost. Tanpa container; ia berjalan di bawah systemd pada domain Anda sendiri.

Um app no catálogo do YunoHost. Sem container; roda sob systemd no seu próprio domínio.

The one catalogue here that installs no container

El único catálogo aquí que no instala ningún contenedor

ここで唯一、コンテナを入れないカタログ

Единственный здесь каталог, который не ставит контейнер

یہاں کا واحد کیٹلاگ جو کوئی کنٹینر نصب نہیں کرتا

这里唯一不装容器的目录

這裡唯一不裝容器的目錄

Jedyny tu katalog, który nie instaluje kontenera

Le seul catalogue ici qui n'installe aucun container

L'unico catalogo qui che non installa nessun container

Der einzige Katalog hier, der keinen Container installiert

Satu-satunya katalog di sini yang tidak memasang container

O único catálogo aqui que não instala container nenhum

YunoHost unpacks the standalone Linux tarball into its own directory, makes a system user for it and runs server.js under systemd, behind the nginx it already has, on a domain you already own. Nothing is pulled and no port is published: the app listens on 127.0.0.1 on a port YunoHost picks, and nginx puts it on your domain. Install it with sudo yunohost app install libredb_studio, or from the admin web interface. The catalogue carries 0.16.1~ynh2 today, behind the 0.17.0 these pages describe.

YunoHost descomprime el tarball de Linux independiente en un directorio propio, le crea un usuario de sistema y ejecuta server.js bajo systemd, detrás del nginx que ya tiene, en un dominio que ya es tuyo. No se descarga nada y no se publica ningún puerto: la aplicación escucha en 127.0.0.1 en un puerto que elige YunoHost, y nginx la pone en tu dominio. Instálala con sudo yunohost app install libredb_studio, o desde la interfaz web de administración. El catálogo lleva hoy 0.16.1~ynh2, por detrás de la 0.17.0 que describen estas páginas.

YunoHost は単体の Linux tarball を自分のディレクトリに展開し、そのためのシステムユーザーを作って、すでにある nginx の後ろ、すでにあなたが持っているドメインで、server.js を systemd の下で動かします。取得されるものはなく、公開されるポートもありません。アプリは YunoHost が選んだポートで 127.0.0.1 を待ち受け、nginx がそれをあなたのドメインに載せます。導入は sudo yunohost app install libredb_studio で、あるいは管理用のウェブ画面から。カタログが今日運んでいるのは 0.16.1~ynh2 で、これらのページが説明している 0.17.0 より古いものです。

YunoHost распаковывает самостоятельный Linux-tarball в собственный каталог, заводит для него системного пользователя и запускает server.js под systemd, за тем nginx, который у него уже есть, на домене, который уже ваш. Ничего не тянется и ни один порт не публикуется: приложение слушает 127.0.0.1 на порту, который выбирает YunoHost, а nginx выводит его на ваш домен. Ставьте командой sudo yunohost app install libredb_studio или из веб-интерфейса администратора. Сегодня каталог несёт 0.16.1~ynh2, то есть позади 0.17.0, о которой эти страницы.

YunoHost خودمختار Linux tarball کو اپنی ایک ڈائریکٹری میں کھولتا ہے، اس کے لیے ایک سسٹم صارف بناتا ہے اور server.js کو systemd کے تحت چلاتا ہے، اُسی nginx کے پیچھے جو اس کے پاس پہلے سے ہے، اُسی ڈومین پر جو پہلے سے آپ کا ہے۔ کچھ کھینچا نہیں جاتا اور کوئی پورٹ شائع نہیں ہوتی: ایپ 127.0.0.1 پر اُس پورٹ کو سنتی ہے جو YunoHost چنتا ہے، اور nginx اسے آپ کے ڈومین پر لے آتا ہے۔ اسے sudo yunohost app install libredb_studio سے نصب کریں، یا منتظم کے ویب انٹرفیس سے۔ فہرست آج 0.16.1~ynh2 رکھتی ہے، جو ان صفحات کی 0.17.0 سے پیچھے ہے۔

YunoHost 把那个独立的 Linux tarball 解包到它自己的目录里，给它建一个系统用户，然后在它本来就有的 nginx 后面、在你本来就拥有的域名上，用 systemd 跑 server.js。没有任何东西被拉取，也没有端口被发布：应用在 127.0.0.1 上监听一个由 YunoHost 挑的端口，再由 nginx 把它放到你的域名上。用 sudo yunohost app install libredb_studio 安装，或者从管理后台的网页界面装。目录今天带的是 0.16.1~ynh2，比这些页面讲的 0.17.0 旧。

YunoHost 把那個獨立的 Linux tarball 解開到它自己的目錄裡，給它建一個系統使用者，然後在它本來就有的 nginx 後面、在你本來就擁有的網域上，用 systemd 跑 server.js。沒有任何東西被拉取，也沒有連接埠被發布：應用在 127.0.0.1 上監聽一個由 YunoHost 挑的連接埠，再由 nginx 把它放到你的網域上。用 sudo yunohost app install libredb_studio 安裝，或者從管理後台的網頁介面裝。目錄今天帶的是 0.16.1~ynh2，比這些頁面講的 0.17.0 舊。

YunoHost rozpakowuje samodzielny linuksowy tarball do własnego katalogu, zakłada dla niego użytkownika systemowego i uruchamia server.js pod systemd, za nginxem, którego już ma, na domenie, którą już masz. Nic nie jest ściągane i żaden port nie jest publikowany: aplikacja słucha na 127.0.0.1 na porcie, który wybiera YunoHost, a nginx wystawia ją na twojej domenie. Zainstaluj poleceniem sudo yunohost app install libredb_studio albo z webowego panelu administratora. Katalog niesie dziś 0.16.1~ynh2, czyli mniej niż 0.17.0 opisywana na tych stronach.

YunoHost décompresse le tarball Linux autonome dans un répertoire à lui, lui crée un utilisateur système et fait tourner server.js sous systemd, derrière le nginx qu'il a déjà, sur un domaine qui est déjà le vôtre. Rien n'est tiré et aucun port n'est publié : l'application écoute sur 127.0.0.1 sur un port choisi par YunoHost, et nginx la pose sur votre domaine. Installez-la avec sudo yunohost app install libredb_studio, ou depuis l'interface web d'administration. Le catalogue porte aujourd'hui 0.16.1~ynh2, derrière la 0.17.0 que ces pages décrivent.

YunoHost scompatta il tarball Linux autonomo in una directory sua, gli crea un utente di sistema e fa girare server.js sotto systemd, dietro il nginx che ha già, su un dominio che è già tuo. Non si scarica niente e non si pubblica nessuna porta: l'applicazione ascolta su 127.0.0.1 su una porta che sceglie YunoHost, e nginx la mette sul tuo dominio. Installala con sudo yunohost app install libredb_studio, oppure dall'interfaccia web di amministrazione. Il catalogo oggi porta la 0.16.1~ynh2, indietro rispetto alla 0.17.0 che queste pagine descrivono.

YunoHost packt den eigenständigen Linux-Tarball in ein eigenes Verzeichnis aus, legt einen Systembenutzer dafür an und lässt server.js unter systemd laufen, hinter dem nginx, das es ohnehin hat, auf einer Domain, die dir ohnehin gehört. Es wird nichts gezogen und kein Port veröffentlicht: die Anwendung lauscht auf 127.0.0.1 auf einem Port, den YunoHost wählt, und nginx legt sie auf deine Domain. Installiert wird mit sudo yunohost app install libredb_studio oder über die Administrations-Weboberfläche. Der Katalog führt heute 0.16.1~ynh2, hinter dem 0.17.0, das diese Seiten beschreiben.

YunoHost membongkar tarball Linux mandiri itu ke direktorinya sendiri, membuatkan sebuah user sistem untuknya, lalu menjalankan server.js di bawah systemd, di belakang nginx yang sudah ia punya, pada domain yang sudah Anda miliki. Tidak ada yang ditarik dan tidak ada port yang dipublikasikan: aplikasinya mendengarkan di 127.0.0.1 pada port yang dipilih YunoHost, dan nginx yang memasangnya di domain Anda. Pasang dengan sudo yunohost app install libredb_studio, atau dari antarmuka web administrator. Katalognya hari ini membawa 0.16.1~ynh2, di belakang 0.17.0 yang dibahas halaman-halaman ini.

O YunoHost descompacta o tarball Linux independente num diretório próprio, cria um usuário de sistema para ele e roda server.js sob systemd, atrás do nginx que ele já tem, num domínio que já é seu. Nada é baixado e nenhuma porta é publicada: a aplicação escuta em 127.0.0.1 numa porta que o YunoHost escolhe, e o nginx a coloca no seu domínio. Instale com sudo yunohost app install libredb_studio, ou pela interface web de administração. O catálogo carrega hoje a 0.16.1~ynh2, atrás da 0.17.0 que estas páginas descrevem.

The password is printed once, where only root can read it

La contraseña se imprime una vez, donde solo root puede leerla

パスワードは一度だけ、root にしか読めない場所へ出る

Пароль печатается один раз: там, где его прочитает только root

پاس ورڈ ایک ہی بار چھپتا ہے، وہاں جہاں صرف root پڑھ سکتا ہے

密码只打印一次，打在只有 root 能读到的地方

密碼只印一次，印在只有 root 能讀到的地方

Hasło jest wypisywane raz, tam gdzie przeczyta je tylko root

Le mot de passe est écrit une fois, là où seul root peut le lire

La password viene stampata una volta sola, dove solo root può leggerla

Das Passwort wird einmal ausgegeben, dort wo nur root es lesen kann

Password-nya dicetak sekali, di tempat yang hanya root bisa baca

A senha é impressa uma vez, onde só o root consegue ler

The first run generates the administrator password and writes it once to /var/log/libredb_studio/libredb_studio.log. That file is the only copy, and the package keeps it to root and the app's own user, so read it there rather than widening it. The rest is already set: STORAGE_PROVIDER is sqlite with the store in a data directory an upgrade does not replace, and JWT_SECRET lives in YunoHost's app settings, so an upgrade or a restore does not end every session. YunoHost's own single sign-on is left off, because the app has its own login. One thing to check before you install: the manifest still asks for YunoHost 12.0.9, but the Node.js resource the package uses arrived later in the 12.1 line (I found it missing on 12.0.9 and 12.1.0 and present on 12.1.20) so install on a server that is up to date.

El primer arranque genera la contraseña de administrador y la escribe una sola vez en /var/log/libredb_studio/libredb_studio.log. Ese archivo es la única copia, y el paquete lo deja accesible solo a root y al usuario propio de la aplicación, así que léela ahí en lugar de ampliar los permisos. Lo demás ya viene puesto: STORAGE_PROVIDER es sqlite, con el almacén en un directorio de datos que una actualización no sustituye, y JWT_SECRET vive en los ajustes de la aplicación dentro de YunoHost, así que una actualización o una restauración no terminan todas las sesiones. El inicio de sesión único propio de YunoHost se deja apagado, porque la aplicación tiene el suyo. Una cosa que comprobar antes de instalar: el manifiesto sigue pidiendo YunoHost 12.0.9, pero el recurso de Node.js que usa el paquete llegó más tarde, ya dentro de la línea 12.1 (lo encontré ausente en 12.0.9 y en 12.1.0, y presente en 12.1.20), así que instala en un servidor que esté al día.

初回起動で管理者パスワードが生成され、一度だけ /var/log/libredb_studio/libredb_studio.log に書き出されます。そのファイルが唯一の控えで、パッケージはそれを root とアプリ自身のユーザーだけに閉じているので、権限を広げるのではなく、そこで読んでください。ほかはすでに整っています。STORAGE_PROVIDER は sqlite で、保存先は更新で置き換えられないデータディレクトリの中にあり、JWT_SECRET は YunoHost のアプリ設定に収まっているため、更新や復元をしてもすべてのセッションが切れることはありません。YunoHost 自身のシングルサインオンは、アプリに自前のログインがあるので切ってあります。入れる前に一つ確かめること。マニフェストはいまも YunoHost 12.0.9 を求めますが、パッケージが使う Node.js のリソースが入ったのはもっと後、12.1 系の途中です。12.0.9 と 12.1.0 では見つからず、12.1.20 にはありました。ですから、最新に追いついたサーバーへ入れてください。

Первый запуск генерирует пароль администратора и один раз записывает его в /var/log/libredb_studio/libredb_studio.log. Этот файл является единственной копией, и пакет держит его доступным только root и собственному пользователю приложения, так что читайте пароль там, а не расширяйте доступ. Остальное уже выставлено: STORAGE_PROVIDER задан как sqlite, хранилище лежит в каталоге данных, который обновление не подменяет, а JWT_SECRET живёт в настройках приложения внутри YunoHost, поэтому обновление или восстановление не обрывает все сессии. Собственный единый вход YunoHost оставлен выключенным, потому что у приложения свой вход. Одно стоит проверить до установки: манифест до сих пор требует YunoHost 12.0.9, но ресурс Node.js, которым пользуется пакет, появился позже, уже в линии 12.1 (на 12.0.9 и на 12.1.0 я его не нашёл, а на 12.1.20 он есть), так что ставьте на сервер, который обновлён.

پہلی بار چلنے پر منتظم کا پاس ورڈ بنتا ہے اور ایک ہی بار /var/log/libredb_studio/libredb_studio.log میں لکھا جاتا ہے۔ وہی فائل واحد نقل ہے، اور پیکج اسے صرف root اور ایپ کے اپنے صارف تک محدود رکھتا ہے، سو اجازتیں کھولنے کے بجائے پاس ورڈ وہیں سے پڑھیں۔ باقی سب پہلے سے طے ہے: STORAGE_PROVIDER sqlite ہے اور ذخیرہ ایسی ڈیٹا ڈائریکٹری میں ہے جسے اپ گریڈ بدلتا نہیں، اور JWT_SECRET YunoHost کی ایپ ترتیبات میں رہتا ہے، اس لیے اپ گریڈ یا بحالی ہر سیشن ختم نہیں کر دیتی۔ YunoHost کا اپنا واحد سائن آن بند چھوڑا گیا ہے، کیونکہ ایپ کا اپنا لاگ اِن ہے۔ نصب کرنے سے پہلے ایک بات جانچ لیں: مینی فیسٹ اب بھی YunoHost 12.0.9 مانگتا ہے، مگر جو Node.js وسیلہ پیکج استعمال کرتا ہے وہ بعد میں، 12.1 کی قطار کے اندر آیا، میں نے اسے 12.0.9 اور 12.1.0 پر غائب پایا اور 12.1.20 پر موجود، سو ایسے سرور پر نصب کریں جو اپ ٹو ڈیٹ ہو۔

首次启动会生成管理员密码，并且只写一次到 /var/log/libredb_studio/libredb_studio.log。那个文件就是唯一的一份，而且包把它只留给 root 和应用自己的用户，所以去那里读，而不是把权限放宽。其余的已经配好了：STORAGE_PROVIDER 是 sqlite，存放的位置在一个更新时不会被换掉的数据目录里，JWT_SECRET 存在 YunoHost 的应用设置里，所以一次更新或一次恢复不会把所有会话都结束掉。YunoHost 自带的单点登录是关着的，因为应用有自己的登录。装之前有一件事要确认：清单里仍然要求 YunoHost 12.0.9，但这个包用到的 Node.js 资源是后来才进来的，已经在 12.1 这一条线里（我在 12.0.9 和 12.1.0 上都没找到它，在 12.1.20 上找到了），所以要装在一台已经跟上版本的服务器上。

首次啟動會產生管理員密碼，而且只寫一次到 /var/log/libredb_studio/libredb_studio.log。那個檔案就是唯一的一份，而且套件把它只留給 root 和應用自己的使用者，所以去那裡讀，而不是把權限放寬。其餘的已經配好了：STORAGE_PROVIDER 是 sqlite，存放的位置在一個更新時不會被換掉的資料目錄裡，JWT_SECRET 存在 YunoHost 的應用設定裡，所以一次更新或一次還原不會把所有工作階段都結束掉。YunoHost 自帶的單一登入是關著的，因為應用有自己的登入。裝之前有一件事要確認：清單裡仍然要求 YunoHost 12.0.9，但這個套件用到的 Node.js 資源是後來才進來的，已經在 12.1 這一條線裡（我在 12.0.9 和 12.1.0 上都沒找到它，在 12.1.20 上找到了），所以要裝在一台已經跟上版本的伺服器上。

Pierwsze uruchomienie generuje hasło administratora i zapisuje je raz do /var/log/libredb_studio/libredb_studio.log. Ten plik jest jedyną kopią, a pakiet trzyma go tylko dla root i własnego użytkownika aplikacji, więc przeczytaj hasło tam, zamiast rozszerzać dostęp. Reszta jest już ustawiona: STORAGE_PROVIDER to sqlite, magazyn leży w katalogu danych, którego aktualizacja nie podmienia, a JWT_SECRET mieszka w ustawieniach aplikacji po stronie YunoHost, więc aktualizacja albo odtworzenie z kopii nie kończy wszystkich sesji. Własne pojedyncze logowanie YunoHost jest zostawione wyłączone, bo aplikacja ma swoje. Jedno warto sprawdzić przed instalacją: manifest wciąż prosi o YunoHost 12.0.9, ale zasób Node.js, z którego pakiet korzysta, pojawił się później, już w linii 12.1: na 12.0.9 i na 12.1.0 go nie znalazłem, a na 12.1.20 jest, więc instaluj na serwerze, który jest aktualny.

Le premier démarrage génère le mot de passe administrateur et l'écrit une seule fois dans /var/log/libredb_studio/libredb_studio.log. Ce fichier est la seule copie, et le paquet le réserve à root et à l'utilisateur propre de l'application, donc lisez-le là plutôt que d'élargir les droits. Le reste est déjà réglé : STORAGE_PROVIDER vaut sqlite, avec le stockage dans un répertoire de données qu'une mise à jour ne remplace pas, et JWT_SECRET vit dans les réglages d'application de YunoHost, si bien qu'une mise à jour ou une restauration ne met pas fin à toutes les sessions. L'authentification unique propre à YunoHost est laissée désactivée, parce que l'application a sa propre connexion. Une chose à vérifier avant d'installer : le manifeste demande toujours YunoHost 12.0.9, mais la ressource Node.js qu'utilise le paquet est arrivée plus tard, déjà dans la ligne 12.1 (je l'ai trouvée absente en 12.0.9 et en 12.1.0, et présente en 12.1.20), installez donc sur un serveur à jour.

Il primo avvio genera la password di amministratore e la scrive una volta sola in /var/log/libredb_studio/libredb_studio.log. Quel file è l'unica copia, e il pacchetto lo tiene riservato a root e all'utente proprio dell'applicazione, quindi leggila lì invece di allargare i permessi. Il resto è già a posto: STORAGE_PROVIDER è sqlite, con l'archivio in una directory di dati che un aggiornamento non sostituisce, e JWT_SECRET sta nelle impostazioni dell'app dentro YunoHost, così un aggiornamento o un ripristino non chiudono tutte le sessioni. Il single sign-on di YunoHost è lasciato spento, perché l'applicazione ha il proprio accesso. Una cosa da controllare prima di installare: il manifest chiede ancora YunoHost 12.0.9, ma la risorsa Node.js che il pacchetto usa è arrivata più tardi, già nella linea 12.1: l'ho trovata assente su 12.0.9 e su 12.1.0, e presente su 12.1.20, quindi installa su un server aggiornato.

Der erste Start erzeugt das Administrator-Passwort und schreibt es einmal nach /var/log/libredb_studio/libredb_studio.log. Diese Datei ist die einzige Kopie, und das Paket hält sie auf root und den eigenen Benutzer der Anwendung beschränkt, lies es also dort, statt die Rechte aufzumachen. Der Rest steht schon: STORAGE_PROVIDER ist sqlite, der Speicher liegt in einem Datenverzeichnis, das ein Upgrade nicht ersetzt, und JWT_SECRET wohnt in den App-Einstellungen von YunoHost, ein Upgrade oder eine Wiederherstellung beendet also nicht jede Sitzung. Das eigene Single Sign-on von YunoHost bleibt aus, weil die Anwendung ihren eigenen Login hat. Eine Sache vor der Installation: das Manifest verlangt weiterhin YunoHost 12.0.9, aber die Node.js-Ressource, die das Paket nutzt, kam später, schon mitten in der 12.1-Reihe (auf 12.0.9 und auf 12.1.0 habe ich sie nicht gefunden, auf 12.1.20 war sie da), installiere also auf einem Server, der aktuell ist.

Run pertama membuat password administrator dan menuliskannya sekali ke /var/log/libredb_studio/libredb_studio.log. File itulah satu-satunya salinan, dan paketnya menjaganya tetap milik root dan user aplikasi itu sendiri, jadi bacalah di sana alih-alih melebarkan izinnya. Sisanya sudah diatur: STORAGE_PROVIDER adalah sqlite dengan penyimpanannya di direktori data yang tidak diganti oleh upgrade, dan JWT_SECRET tinggal di pengaturan aplikasi milik YunoHost, jadi upgrade atau restore tidak mengakhiri semua sesi. Single sign-on milik YunoHost sendiri dibiarkan mati, karena aplikasinya punya login sendiri. Satu hal yang perlu dicek sebelum Anda memasang: manifesnya masih meminta YunoHost 12.0.9, tetapi resource Node.js yang dipakai paket itu baru datang belakangan, sudah di jalur 12.1 (saya menemukannya tidak ada di 12.0.9 dan di 12.1.0, dan ada di 12.1.20), jadi pasanglah di server yang sudah mutakhir.

A primeira execução gera a senha de administrador e a escreve uma única vez em /var/log/libredb_studio/libredb_studio.log. Esse arquivo é a única cópia, e o pacote o mantém restrito ao root e ao usuário próprio da aplicação, então leia a senha ali em vez de afrouxar as permissões. O resto já vem definido: STORAGE_PROVIDER é sqlite, com o armazenamento num diretório de dados que uma atualização não substitui, e JWT_SECRET mora nas configurações do app dentro do YunoHost, então uma atualização ou uma restauração não encerra todas as sessões. O single sign-on do próprio YunoHost fica desligado, porque a aplicação tem o login dela. Uma coisa para conferir antes de instalar: o manifesto ainda pede o YunoHost 12.0.9, mas o recurso Node.js que o pacote usa chegou depois, já na linha 12.1 (eu o encontrei ausente na 12.0.9 e na 12.1.0, e presente na 12.1.20), então instale num servidor que esteja em dia.

An app in the okxlin community store for 1Panel. Host port 3000.

Una aplicación en la tienda comunitaria okxlin para 1Panel. Puerto de host 3000.

1Panel 向けの okxlin コミュニティストアにあるアプリ。ホスト側ポートは 3000。

Приложение в магазине сообщества okxlin для 1Panel. Порт на хосте 3000.

okxlin کمیونٹی اسٹور کی ایک ایپ، 1Panel کے لیے۔ ہوسٹ پورٹ 3000۔

1Panel 的 okxlin 社区商店里的一个应用。主机端口 3000。

1Panel 的 okxlin 社群商店裡的一個應用。主機連接埠 3000。

Aplikacja w społecznościowym sklepie okxlin dla 1Panel. Port 3000 na hoście.

Une application du store communautaire okxlin pour 1Panel. Port hôte 3000.

Un'app nello store della community okxlin per 1Panel. Porta host 3000.

Eine App im Community-Store okxlin für 1Panel. Host-Port 3000.

Sebuah aplikasi di store komunitas okxlin untuk 1Panel. Port host 3000.

Um app na loja comunitária okxlin para o 1Panel. Porta 3000 no host.

Turn on server-side storage yourself

El almacenamiento en el servidor lo enciendes tú

サーバー側の保存は自分で入れる

Хранилище на сервере включайте сами

سرور کی طرف کا ذخیرہ خود آن کریں

服务端存储要你自己打开

伺服器端儲存要你自己打開

Magazyn po stronie serwera włącz sam

Activez vous-même le stockage côté serveur

Lo storage lato server accendilo tu

Den Speicher auf dem Server schaltest du selbst ein

Penyimpanan di sisi server Anda nyalakan sendiri

Ligue você mesmo o armazenamento no servidor

The template mounts a data volume and points STORAGE_SQLITE_PATH at a file inside it, which reads like saved connections will be kept on the server. They are not. It never sets STORAGE_PROVIDER, so that stays at local: I asked the running container and it answered {"provider":"local","serverMode":false}, and the configured path is never written. What the volume does get is the two sample databases and auth-bootstrap.json, which holds the generated administrator password and the signing secret in clear text, so give that directory the care you would give a password file. Add STORAGE_PROVIDER=sqlite to the app's environment and the same question answers sqlite with serverMode true.

La plantilla monta un volumen de datos y apunta STORAGE_SQLITE_PATH a un archivo dentro de él, lo que se lee como si las conexiones guardadas fueran a quedarse en el servidor. No se quedan. Nunca pone STORAGE_PROVIDER, así que eso sigue en local: se lo pregunté al contenedor en marcha y respondió {"provider":"local","serverMode":false}, y la ruta configurada no se escribe nunca. Lo que el volumen sí recibe son las dos bases de datos de ejemplo y auth-bootstrap.json, que guarda en claro la contraseña de administrador generada y el secreto de firma, así que trata ese directorio con el cuidado que le darías a un archivo de contraseñas. Añade STORAGE_PROVIDER=sqlite al entorno de la aplicación y la misma pregunta responde sqlite, con serverMode en true.

テンプレートはデータ用のボリュームをマウントし、STORAGE_SQLITE_PATH をその中のファイルに向けます。保存した接続がサーバーに残るように読めます。残りません。STORAGE_PROVIDER は一度も設定されないので、そこは local のままです。動いているコンテナに尋ねたところ {"provider":"local","serverMode":false} と返ってきました。設定されたパスは一度も書かれません。ボリュームに実際に入るのは、二つのサンプルデータベースと auth-bootstrap.json です。このファイルには、生成された管理者パスワードと署名用のシークレットが平文で入っています。そのディレクトリはパスワードファイルと同じように扱ってください。アプリの環境に STORAGE_PROVIDER=sqlite を足せば、同じ問いは sqlite と答え、serverMode も true になります。

Шаблон монтирует том для данных и направляет STORAGE_SQLITE_PATH на файл внутри него: это читается так, будто сохранённые подключения останутся на сервере. Не останутся. STORAGE_PROVIDER он не задаёт вовсе, так что тот остаётся в local: я спросил работающий контейнер, и он ответил {"provider":"local","serverMode":false}, а настроенный путь не пишется никогда. В том попадают две базы-примера и auth-bootstrap.json, где открытым текстом лежат сгенерированный пароль администратора и секрет подписи, так что относитесь к этому каталогу так же бережно, как к файлу с паролями. Добавьте STORAGE_PROVIDER=sqlite в окружение приложения, и тот же вопрос ответит sqlite, а serverMode станет true.

ٹیمپلیٹ ایک ڈیٹا والیوم ماؤنٹ کرتا ہے اور STORAGE_SQLITE_PATH کو اس کے اندر کی ایک فائل کی طرف کرتا ہے، جس سے یوں پڑھا جاتا ہے کہ محفوظ کنکشن سرور پر رہیں گے۔ نہیں رہتے۔ یہ STORAGE_PROVIDER کبھی مقرر ہی نہیں کرتا، سو وہ local پر ہی رہتا ہے: میں نے چلتے ہوئے کنٹینر سے پوچھا تو اس نے {"provider":"local","serverMode":false} جواب دیا، اور مقرر کردہ راستے پر کبھی کچھ لکھا نہیں جاتا۔ والیوم میں جو چیزیں واقعی آتی ہیں وہ دو نمونہ ڈیٹابیس اور auth-bootstrap.json ہیں، اور اس فائل میں تیار کردہ منتظم کا پاس ورڈ اور دستخط کا خفیہ راز سادہ متن میں پڑے ہوتے ہیں، سو اُس ڈائریکٹری کا اتنا ہی خیال رکھیں جتنا آپ پاس ورڈ کی فائل کا رکھتے ہیں۔ ایپ کے ماحول میں STORAGE_PROVIDER=sqlite شامل کریں تو وہی سوال sqlite جواب دیتا ہے اور serverMode true ہوتا ہے۔

模板挂了一个数据卷，并把 STORAGE_SQLITE_PATH 指向卷里的一个文件，读起来就像保存的连接会留在服务器上。并不会。它从来没有设过 STORAGE_PROVIDER，所以那一项一直停在 local：我问了正在跑的容器，它回答 {"provider":"local","serverMode":false}，配置里的那个路径也从来没被写过。卷里真正装进去的，是那两个示例数据库和 auth-bootstrap.json，后者以明文存着自动生成的管理员密码和签名密钥，所以请像对待一个密码文件那样对待那个目录。给应用的环境里加上 STORAGE_PROVIDER=sqlite，同一个问题就答 sqlite，serverMode 也是 true。

範本掛了一個資料磁碟區，並把 STORAGE_SQLITE_PATH 指向磁碟區裡的一個檔案，讀起來就像儲存的連線會留在伺服器上。並不會。它從來沒有設過 STORAGE_PROVIDER，所以那一項一直停在 local：我問了正在跑的容器，它回答 {"provider":"local","serverMode":false}，設定裡的那個路徑也從來沒被寫過。磁碟區裡真正裝進去的，是那兩個範例資料庫和 auth-bootstrap.json，後者以明文存著自動產生的管理員密碼和簽章金鑰，所以請像對待一個密碼檔案那樣對待那個目錄。給應用的環境裡加上 STORAGE_PROVIDER=sqlite，同一個問題就答 sqlite，serverMode 也是 true。

Szablon montuje wolumen na dane i kieruje STORAGE_SQLITE_PATH na plik w środku, co czyta się tak, jakby zapisane połączenia miały zostać na serwerze. Nie zostają. STORAGE_PROVIDER nie jest ustawiane w ogóle, więc zostaje na local: zapytałem działający kontener i odpowiedział {"provider":"local","serverMode":false}, a skonfigurowana ścieżka nigdy nie jest zapisywana. W wolumenie lądują natomiast dwie przykładowe bazy i auth-bootstrap.json, w którym czystym tekstem leży wygenerowane hasło administratora i sekret podpisujący, więc traktuj ten katalog z taką samą ostrożnością jak plik z hasłami. Dodaj STORAGE_PROVIDER=sqlite do środowiska aplikacji, a to samo pytanie odpowie sqlite, z serverMode na true.

Le template monte un volume de données et pointe STORAGE_SQLITE_PATH sur un fichier à l'intérieur, ce qui se lit comme si les connexions enregistrées allaient rester sur le serveur. Elles ne restent pas. Il ne règle jamais STORAGE_PROVIDER, qui reste donc sur local : j'ai posé la question au container en marche et il a répondu {"provider":"local","serverMode":false}, et le chemin configuré n'est jamais écrit. Ce que le volume reçoit, en revanche, ce sont les deux bases d'exemple et auth-bootstrap.json, qui contient en clair le mot de passe administrateur généré et le secret de signature, alors accordez à ce répertoire le soin que vous accorderiez à un fichier de mots de passe. Ajoutez STORAGE_PROVIDER=sqlite à l'environnement de l'application et la même question répond sqlite, avec serverMode à true.

Il template monta un volume per i dati e punta STORAGE_SQLITE_PATH su un file al suo interno, il che si legge come se le connessioni salvate restassero sul server. Non restano. STORAGE_PROVIDER non viene mai impostato, quindi resta su local: l'ho chiesto al container in esecuzione e ha risposto {"provider":"local","serverMode":false}, e il percorso configurato non viene mai scritto. Quello che nel volume finisce davvero sono i due database di esempio e auth-bootstrap.json, che tiene in chiaro la password di amministratore generata e il segreto di firma, quindi tratta quella directory con la cura che riserveresti a un file di password. Aggiungi STORAGE_PROVIDER=sqlite all'ambiente dell'app e la stessa domanda risponde sqlite, con serverMode a true.

Das Template hängt ein Daten-Volume ein und zeigt mit STORAGE_SQLITE_PATH auf eine Datei darin, was sich liest, als blieben gespeicherte Verbindungen auf dem Server. Sie bleiben nicht. STORAGE_PROVIDER setzt es nie, das steht also weiter auf local: ich habe den laufenden Container gefragt, und er antwortete {"provider":"local","serverMode":false}, und der konfigurierte Pfad wird nie beschrieben. Was im Volume tatsächlich landet, sind die beiden Beispieldatenbanken und auth-bootstrap.json, worin das erzeugte Administrator-Passwort und das Signaturgeheimnis im Klartext stehen, behandle dieses Verzeichnis also so sorgfältig wie eine Passwortdatei. Nimm STORAGE_PROVIDER=sqlite in die Umgebung der App auf, dann antwortet dieselbe Frage sqlite, mit serverMode auf true.

Template-nya me-mount sebuah volume data dan mengarahkan STORAGE_SQLITE_PATH ke sebuah file di dalamnya, yang terbaca seolah koneksi yang disimpan akan tinggal di server. Tidak begitu. Ia tidak pernah men-set STORAGE_PROVIDER, jadi nilainya tetap local: saya bertanya ke container yang sedang jalan dan ia menjawab {"provider":"local","serverMode":false}, dan path yang dikonfigurasi tidak pernah ditulisi. Yang benar-benar masuk ke volume itu adalah dua database contoh dan auth-bootstrap.json, yang menyimpan password administrator hasil generate dan secret penandatanganan dalam teks polos, jadi jagalah direktori itu seperti Anda menjaga sebuah file password. Tambahkan STORAGE_PROVIDER=sqlite ke environment aplikasinya dan pertanyaan yang sama menjawab sqlite dengan serverMode true.

O template monta um volume de dados e aponta STORAGE_SQLITE_PATH para um arquivo dentro dele, o que se lê como se as conexões salvas fossem ficar no servidor. Não ficam. Ele nunca define STORAGE_PROVIDER, então isso continua em local: perguntei ao container em execução e ele respondeu {"provider":"local","serverMode":false}, e o caminho configurado nunca é escrito. O que o volume recebe de fato são os dois bancos de exemplo e auth-bootstrap.json, que guarda em texto puro a senha de administrador gerada e o segredo de assinatura, então dê a esse diretório o cuidado que você daria a um arquivo de senhas. Acrescente STORAGE_PROVIDER=sqlite ao ambiente do app e a mesma pergunta responde sqlite, com serverMode true.

What else it leaves to you

Qué más te deja a ti

ほかに任されること

Что ещё оставлено вам

اور کیا کیا آپ پر چھوڑا گیا ہے

它还把什么留给你

它還把什麼留給你

Co jeszcze zostawia tobie

Ce qu'il vous laisse d'autre

Cos'altro lascia a te

Was es dir sonst überlässt

Apa lagi yang ia serahkan ke Anda

O que mais ele deixa para você

This is the community store rather than 1Panel's own, and it pins libredb/libredb-studio:0.16.1 from Docker Hub, behind the 0.17.0 these pages describe. The install form offers three fields (port, timezone and the data directory) and no AUTH_COOKIE_SECURE, which is the variable a looping login needs on a box reached over plain HTTP; the image does read it, so add it to the app yourself, or reach the app over HTTPS instead. The administrator password is generated on the first start and printed to the container log, the same as every other container path on these pages.

Esta es la tienda de la comunidad y no la propia de 1Panel, y fija libredb/libredb-studio:0.16.1 de Docker Hub, por detrás de la 0.17.0 que describen estas páginas. El formulario de instalación ofrece tres campos (puerto, zona horaria y el directorio de datos) y ningún AUTH_COOKIE_SECURE, que es justo la variable que necesita un inicio de sesión en bucle en una máquina a la que se llega por HTTP plano; la imagen sí la lee, así que añádela tú mismo a la aplicación, o llega a ella por HTTPS. La contraseña de administrador se genera en el primer arranque y se imprime en el log del contenedor, igual que en todos los demás caminos con contenedor de estas páginas.

これは 1Panel 自身のストアではなくコミュニティのストアで、Docker Hub の libredb/libredb-studio:0.16.1 に固定されています。これらのページが説明している 0.17.0 より古いものです。インストールのフォームが出す項目は、ポートとタイムゾーンとデータディレクトリの三つだけで、AUTH_COOKIE_SECURE はありません。平文 HTTP で触る機械でログインが堂々巡りになったとき、必要になるのがその変数です。イメージ側はそれを読むので、自分でアプリに足すか、代わりに HTTPS 経由で到達してください。管理者パスワードは初回起動時に生成され、コンテナのログへ出力されます。これらのページのほかのコンテナ経路と、そこは同じです。

Это магазин сообщества, а не собственный магазин 1Panel, и он закрепляет libredb/libredb-studio:0.16.1 с Docker Hub, то есть позади 0.17.0, о которой эти страницы. Форма установки предлагает три поля (порт, часовой пояс и каталог данных) и ни одного AUTH_COOKIE_SECURE, а это как раз та переменная, которая нужна зацикленному входу на машине, доступной по обычному HTTP; образ её читает, так что добавьте её в приложение сами или заходите по HTTPS. Пароль администратора генерируется при первом запуске и печатается в журнал контейнера, так же, как на любом другом контейнерном пути этих страниц.

یہ 1Panel کا اپنا اسٹور نہیں بلکہ کمیونٹی کا اسٹور ہے، اور یہ libredb/libredb-studio:0.16.1 پر سیٹ ہے، جو Docker Hub سے آتی ہے اور ان صفحات کی 0.17.0 سے پیچھے ہے۔ انسٹال کا فارم تین خانے دیتا ہے: پورٹ، ٹائم زون اور ڈیٹا ڈائریکٹری، اور AUTH_COOKIE_SECURE نہیں دیتا، حالانکہ سادہ HTTP سے پہنچی جانے والی مشین پر چکر کھاتے لاگ اِن کو یہی متغیر درکار ہوتا ہے؛ امیج اسے پڑھتی ضرور ہے، سو اسے خود ایپ میں شامل کریں، یا پھر ایپ تک HTTPS سے پہنچیں۔ منتظم کا پاس ورڈ پہلی بار چلنے پر بنتا ہے اور کنٹینر کے لاگ میں چھپتا ہے، بالکل ان صفحات کے ہر دوسرے کنٹینر راستے کی طرح۔

这是社区商店，不是 1Panel 自己的商店，它把镜像钉在 Docker Hub 的 libredb/libredb-studio:0.16.1 上，比这些页面讲的 0.17.0 旧。安装表单给了三个字段（端口、时区和数据目录），却没有 AUTH_COOKIE_SECURE，而那正是一台走明文 HTTP 访问的机器上登录打转时要用的变量；镜像本身是读它的，所以自己把它加到这个应用里，或者改走 HTTPS 访问。管理员密码在首次启动时生成，并打到容器日志里，和这些页面上其他所有容器路径一样。

這是社群商店，不是 1Panel 自己的商店，它把映像檔釘在 Docker Hub 的 libredb/libredb-studio:0.16.1 上，比這些頁面講的 0.17.0 舊。安裝表單給了三個欄位（連接埠、時區和資料目錄），卻沒有 AUTH_COOKIE_SECURE，而那正是一台走明文 HTTP 存取的機器上登入打轉時要用的變數；映像檔本身是讀它的，所以自己把它加到這個應用裡，或者改走 HTTPS 存取。管理員密碼在首次啟動時產生，並打到容器日誌裡，和這些頁面上其他所有容器路徑一樣。

To sklep społecznościowy, a nie własny sklep 1Panel, i przypina libredb/libredb-studio:0.16.1 z Docker Huba, czyli mniej niż 0.17.0 opisywana na tych stronach. Formularz instalacji daje trzy pola: port, strefę czasową i katalog danych, i żadnego AUTH_COOKIE_SECURE, a to właśnie ta zmienna, której potrzebuje zapętlone logowanie na maszynie dostępnej po zwykłym HTTP; obraz ją czyta, więc dodaj ją do aplikacji sam albo sięgnij do niej po HTTPS. Hasło administratora jest generowane przy pierwszym starcie i wypisywane do logu kontenera, tak samo jak na każdej innej kontenerowej ścieżce na tych stronach.

C'est le store communautaire et non celui de 1Panel, et il épingle libredb/libredb-studio:0.16.1 depuis Docker Hub, derrière la 0.17.0 que ces pages décrivent. Le formulaire d'installation propose trois champs : port, fuseau horaire et répertoire de données, et pas de AUTH_COOKIE_SECURE, qui est justement la variable dont a besoin une connexion qui boucle sur une machine atteinte en HTTP simple ; l'image, elle, la lit, alors ajoutez-la vous-même à l'application, ou atteignez plutôt l'application en HTTPS. Le mot de passe administrateur est généré au premier démarrage et écrit dans le log du container, comme sur tous les autres chemins en container de ces pages.

Questo è lo store della community e non quello di 1Panel, e fissa libredb/libredb-studio:0.16.1 da Docker Hub, indietro rispetto alla 0.17.0 che queste pagine descrivono. Il modulo di installazione offre tre campi (porta, fuso orario e la directory dei dati) e nessun AUTH_COOKIE_SECURE, che è proprio la variabile di cui ha bisogno un login che va in loop su una macchina raggiunta in HTTP semplice; l'immagine lo legge davvero, quindi aggiungilo tu all'app, oppure raggiungi l'app in HTTPS. La password di amministratore viene generata al primo avvio e stampata nel log del container, come su ogni altra strada con container di queste pagine.

Das hier ist der Community-Store und nicht der von 1Panel, und er nagelt libredb/libredb-studio:0.16.1 von Docker Hub fest, hinter dem 0.17.0, das diese Seiten beschreiben. Das Installationsformular bietet drei Felder: Port, Zeitzone und das Datenverzeichnis, und kein AUTH_COOKIE_SECURE, und genau diese Variable braucht ein Login, das sich auf einer über einfaches HTTP erreichten Maschine im Kreis dreht; das Image liest sie sehr wohl, trag sie also selbst in die App ein, oder erreiche die App stattdessen über HTTPS. Das Administrator-Passwort wird beim ersten Start erzeugt und ins Container-Log geschrieben, genau wie auf jedem anderen Container-Weg dieser Seiten.

Ini store komunitas, bukan store 1Panel sendiri, dan ia mematok libredb/libredb-studio:0.16.1 dari Docker Hub, di belakang 0.17.0 yang dibahas halaman-halaman ini. Formulir instalasinya menawarkan tiga kolom (port, zona waktu dan direktori data), dan tidak ada AUTH_COOKIE_SECURE, padahal itulah variabel yang dibutuhkan login yang berputar-putar di mesin yang dijangkau lewat HTTP biasa; image-nya memang membacanya, jadi tambahkan sendiri ke aplikasinya, atau jangkau aplikasinya lewat HTTPS saja. Password administrator dibuat pada start pertama dan dicetak ke log container, sama seperti semua jalur container lain di halaman-halaman ini.

Esta é a loja da comunidade e não a do próprio 1Panel, e ela fixa libredb/libredb-studio:0.16.1 do Docker Hub, atrás da 0.17.0 que estas páginas descrevem. O formulário de instalação oferece três campos (porta, fuso horário e o diretório de dados) e nenhum AUTH_COOKIE_SECURE, que é justamente a variável de que um login em loop precisa numa máquina acessada por HTTP puro; a imagem lê essa variável, então acrescente você mesmo ao app, ou alcance o app por HTTPS. A senha de administrador é gerada no primeiro start e impressa no log do container, igual a todos os outros caminhos com container destas páginas.

One-click app on your own CapRover box.

Aplicación de un clic en tu propio CapRover.

自分の CapRover サーバーでのワンクリックアプリ。

Приложение в один клик на вашем собственном CapRover.

آپ کے اپنے CapRover باکس پر ایک کلک والی ایپ۔

装在你自己 CapRover 机器上的一键应用。

裝在你自己 CapRover 機器上的一鍵應用。

Aplikacja one-click na twojej własnej maszynie z CapRoverem.

Application one-click sur votre propre machine CapRover.

App one-click sulla tua macchina CapRover.

One-Click-App auf deiner eigenen CapRover-Maschine.

Aplikasi satu klik di mesin CapRover Anda sendiri.

App de um clique na sua própria máquina CapRover.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

This template makes the image tag a field on the install form, pre-filled with 0.16.0 rather than the 0.17.0 these pages describe, so type the tag you want there before you install. The form offers no AUTH_COOKIE_SECURE, which is the variable a looping login needs on a box reached over plain HTTP: the image does read it, so set it on the app yourself, or reach the app over HTTPS instead.

Esta plantilla hace de la etiqueta de la imagen un campo del formulario de instalación, rellenado de antemano con 0.16.0 y no con la 0.17.0 que describen estas páginas, así que escribe ahí la etiqueta que quieras antes de instalar. El formulario no ofrece AUTH_COOKIE_SECURE, que es la variable que necesita un inicio de sesión en bucle en una máquina a la que se llega por HTTP plano: la imagen sí la lee, así que ponla tú mismo en la aplicación, o llega a la aplicación por HTTPS.

このテンプレートはイメージのタグをインストールフォームの項目にしていて、そこにはこれらのページが説明している 0.17.0 ではなく 0.16.0 があらかじめ入っています。ですからインストールの前に、欲しいタグをそこへ書いてください。フォームには AUTH_COOKIE_SECURE がありません。平文 HTTP で触る機械のログインループが必要とするのは、その変数です。イメージ自体はこれを読み取るので、アプリに自分で設定するか、代わりに HTTPS 経由で到達してください。

Этот шаблон выносит тег образа в поле на форме установки, заранее заполненное значением 0.16.0, а не 0.17.0, о которой эти страницы, так что впишите туда нужный тег до установки. Переменной AUTH_COOKIE_SECURE в форме нет, а именно она нужна зацикленному входу на машине, доступной по обычному HTTP: образ её читает, так что задайте её приложению сами или заходите по HTTPS.

یہ ٹیمپلیٹ امیج کے ٹیگ کو تنصیبی فارم کا ایک خانہ بنا دیتا ہے، جو پہلے سے 0.16.0 سے بھرا ہوتا ہے، نہ کہ اُس 0.17.0 سے جو یہ صفحات بیان کرتے ہیں؛ سو نصب کرنے سے پہلے وہاں اپنی مرضی کا ٹیگ لکھ دیں۔ فارم AUTH_COOKIE_SECURE پیش نہیں کرتا، اور سادہ HTTP سے پہنچی جانے والی مشین پر چکر کھاتے لاگ اِن کو یہی متغیر درکار ہوتا ہے: امیج اسے پڑھتی ضرور ہے، سو اسے ایپ پر خود مقرر کریں، یا ایپ تک HTTPS سے پہنچیں۔

这个模板把镜像标签做成了安装表单上的一个字段，预填的是 0.16.0，而不是这些页面讲的 0.17.0，所以装之前先在那儿填上你想要的标签。表单里没有 AUTH_COOKIE_SECURE，而在一台走明文 HTTP 访问的机器上，登录死循环要的正是这个变量：镜像本身是会读它的，所以请自己在应用上把它设好，或者改用 HTTPS 访问。

這個範本把映像檔標籤做成了安裝表單上的一個欄位，預先填的是 0.16.0，而不是這些頁面講的 0.17.0，所以裝之前先在那兒填上你想要的標籤。表單裡沒有 AUTH_COOKIE_SECURE，而在一台走明文 HTTP 存取的機器上，登入死迴圈要的正是這個變數：映像檔本身是會讀它的，所以請自己在應用上把它設好，或者改用 HTTPS 存取。

Ten szablon robi z tagu obrazu pole na formularzu instalacji, wypełnione z góry wartością 0.16.0, a nie 0.17.0 opisywaną na tych stronach, więc wpisz tam tag, którego chcesz, zanim zainstalujesz. Formularz nie oferuje AUTH_COOKIE_SECURE, a to zmienna, której potrzebuje zapętlone logowanie na maszynie osiąganej po czystym HTTP: obraz ją czyta, więc ustaw ją sam na aplikacji albo sięgaj do niej po HTTPS.

Ce template fait du tag de l'image un champ du formulaire d'installation, prérempli avec la 0.16.0 plutôt qu'avec la 0.17.0 que ces pages décrivent, tapez donc le tag que vous voulez avant d'installer. Le formulaire ne propose aucun AUTH_COOKIE_SECURE, qui est la variable dont a besoin une connexion qui boucle sur une machine atteinte en HTTP simple : l'image, elle, la lit, définissez-la donc vous-même sur l'application, ou atteignez plutôt l'application en HTTPS.

Questo template fa del tag dell'immagine un campo del modulo di installazione, precompilato con 0.16.0 e non con la 0.17.0 che queste pagine descrivono, quindi scrivici il tag che vuoi prima di installare. Il modulo non offre AUTH_COOKIE_SECURE, che è la variabile che serve a un login che va in ciclo su una macchina raggiunta in HTTP semplice: l'immagine la legge, quindi impostala tu sull'app, oppure raggiungi l'app in HTTPS.

Dieses Template macht den Image-Tag zu einem Feld im Installationsformular, vorbelegt mit 0.16.0 statt mit dem 0.17.0, das diese Seiten beschreiben. Tipp dort also den Tag ein, den du willst, bevor du installierst. Das Formular bietet kein AUTH_COOKIE_SECURE an, und das ist die Variable, die eine Login-Schleife auf einer über einfaches HTTP erreichten Maschine braucht: das Image liest sie sehr wohl, setz sie also selbst an der App, oder erreiche die App stattdessen über HTTPS.

Template ini menjadikan tag image sebagai kolom di formulir instalasi, terisi awal dengan 0.16.0 alih-alih 0.17.0 yang dibahas halaman-halaman ini, jadi ketik tag yang Anda mau di sana sebelum memasang. Formulirnya tidak menawarkan AUTH_COOKIE_SECURE, padahal itulah variabel yang dibutuhkan login yang berputar di mesin yang dijangkau lewat HTTP polos: image-nya sendiri membacanya, jadi set sendiri di aplikasinya, atau jangkau aplikasinya lewat HTTPS sebagai gantinya.

Este template transforma a tag da imagem num campo do formulário de instalação, já preenchido com 0.16.0 e não com a 0.17.0 que estas páginas descrevem, então digite ali a tag que você quer antes de instalar. O formulário não oferece AUTH_COOKIE_SECURE, que é a variável de que um login em loop precisa numa máquina acessada por HTTP puro: a imagem lê essa variável, então defina você mesmo no app, ou acesse o app por HTTPS.

Where saved connections go

Dónde van las conexiones guardadas

保存した接続の行き先

Куда попадают сохранённые подключения

محفوظ کنکشن کہاں جاتے ہیں

保存的连接去了哪里

儲存的連線去了哪裡

Gdzie trafiają zapisane połączenia

Où vont les connexions enregistrées

Dove finiscono le connessioni salvate

Wohin gespeicherte Verbindungen gehen

Ke mana koneksi tersimpan pergi

Para onde vão as conexões salvas

All three of these templates already set STORAGE_PROVIDER to sqlite and mount a volume at /app/data, so saved connections are on the server and survive a restart. You do not have to change either. That also puts them where the database agent can re-resolve them, though on PostgreSQL the agent has a second condition: it refuses a role that is a superuser or can read or write server files or run programs, so give it a least-privilege role rather than the owner.

Las tres plantillas ya ponen STORAGE_PROVIDER a sqlite y montan un volumen en /app/data, así que las conexiones guardadas están en el servidor y sobreviven a un reinicio. No tienes que cambiar ninguna de las dos cosas. Eso también las deja donde el agente de base de datos puede volver a resolverlas, aunque en PostgreSQL el agente tiene una segunda condición: rechaza un rol que sea superusuario o que pueda leer o escribir archivos del servidor o ejecutar programas, así que dale un rol de mínimo privilegio y no el propietario.

これら三つのテンプレートは、いずれもすでに STORAGE_PROVIDER を sqlite にし、/app/data にボリュームをマウントしています。保存した接続はサーバー側にあり、再起動しても残ります。どちらも変える必要はありません。おかげでデータベースエージェントが接続を解決し直せる場所にも置かれます。ただし PostgreSQL では、エージェントにもう一つ条件があります。スーパーユーザーであるロール、サーバーのファイルを読み書きできるロール、プログラムを実行できるロールは拒まれます。所有者ではなく、最小権限のロールを渡してください。

Все три шаблона уже ставят STORAGE_PROVIDER в sqlite и монтируют том в /app/data, так что сохранённые подключения лежат на сервере и переживают перезапуск. Менять ничего не нужно. Заодно они оказываются там, где агент базы данных сможет их заново разрешить, правда, на PostgreSQL у агента есть второе условие: он отказывает роли, которая является суперпользователем либо может читать и писать файлы сервера или запускать программы, так что дайте ему роль с минимальными правами, а не владельца.

یہ تینوں ٹیمپلیٹ پہلے ہی STORAGE_PROVIDER کو sqlite کرتے ہیں اور /app/data پر ایک والیوم لگاتے ہیں، سو محفوظ کیے گئے کنکشن سرور پر رہتے ہیں اور ری اسٹارٹ کے بعد بھی باقی۔ آپ کو ان میں سے کچھ بدلنے کی ضرورت نہیں۔ اس سے وہ اُس جگہ بھی آ جاتے ہیں جہاں ڈیٹابیس ایجنٹ انہیں دوبارہ حل کر سکے، اگرچہ PostgreSQL پر ایجنٹ کی ایک دوسری شرط بھی ہے: وہ ایسے رول کو رد کرتا ہے جو سپر یوزر ہو، یا سرور کی فائلیں پڑھ لکھ سکتا ہو، یا پروگرام چلا سکتا ہو۔ سو اسے مالک کے بجائے کم سے کم اختیار والا رول دیں۔

这三个模板都已经把 STORAGE_PROVIDER 设成 sqlite，并在 /app/data 挂了卷，所以保存的连接在服务端，重启也还在。两样都不用你改。这也把它们放在了数据库智能体能重新解析到的地方，不过在 PostgreSQL 上智能体还有第二个条件：它会拒绝超级用户角色，以及能读写服务端文件或执行程序的角色，所以请给它一个最小权限的角色，而不是属主。

這三個範本都已經把 STORAGE_PROVIDER 設成 sqlite，並在 /app/data 掛了磁碟區，所以儲存的連線在伺服器端，重啟也還在。兩樣都不用你改。這也把它們放在了資料庫智慧代理能重新解析到的地方。不過在 PostgreSQL 上智慧代理還有第二個條件：它會拒絕超級使用者角色，以及能讀寫伺服器端檔案或執行程式的角色，所以請給它一個最小權限的角色，而不是擁有者。

Wszystkie trzy te szablony ustawiają już STORAGE_PROVIDER na sqlite i montują wolumen w /app/data, więc zapisane połączenia są na serwerze i przeżywają restart. Żadnego z tych dwóch nie musisz zmieniać. To stawia je też tam, gdzie agent bazy danych może je ponownie rozwiązać, choć na PostgreSQL-u agent ma drugi warunek: odmawia roli, która jest superuserem albo potrafi czytać i zapisywać pliki serwera lub uruchamiać programy, więc daj mu rolę o minimalnych uprawnieniach, a nie właściciela.

Ces trois templates règlent déjà STORAGE_PROVIDER sur sqlite et montent un volume sur /app/data, si bien que les connexions enregistrées sont sur le serveur et survivent à un redémarrage. Vous n'avez à changer ni l'un ni l'autre. Cela les place aussi là où l'agent de base de données peut les re-résoudre, même si sur PostgreSQL l'agent a une seconde condition : il refuse un rôle superuser ou capable de lire ou d'écrire des fichiers serveur ou d'exécuter des programmes, donnez-lui donc un rôle à privilèges minimaux plutôt que le propriétaire.

Tutti e tre questi template impostano già STORAGE_PROVIDER a sqlite e montano un volume su /app/data, quindi le connessioni salvate stanno sul server e sopravvivono a un riavvio. Non devi cambiare né l'uno né l'altro. Questo le mette anche dove l'agente di database può risolverle di nuovo, anche se su PostgreSQL l'agente ha una seconda condizione: rifiuta un ruolo che sia superuser o che possa leggere o scrivere file sul server o eseguire programmi, quindi dagli un ruolo con i privilegi minimi invece del proprietario.

Alle drei dieser Templates setzen STORAGE_PROVIDER bereits auf sqlite und hängen ein Volume unter /app/data ein, gespeicherte Verbindungen liegen also auf dem Server und überstehen einen Neustart. Du musst an beidem nichts ändern. Damit liegen sie auch dort, wo der Datenbank-Agent sie neu auflösen kann, wobei der Agent auf PostgreSQL eine zweite Bedingung hat: er verweigert eine Rolle, die Superuser ist oder Serverdateien lesen oder schreiben oder Programme ausführen kann. Gib ihm also eine Rolle mit minimalen Rechten statt des Owners.

Ketiga template ini sudah men-set STORAGE_PROVIDER ke sqlite dan me-mount volume di /app/data, jadi koneksi tersimpan ada di server dan selamat dari restart. Anda tidak perlu mengubah keduanya. Itu juga menaruhnya di tempat yang bisa di-resolve ulang oleh agent database, meski pada PostgreSQL agent punya syarat kedua: ia menolak role yang superuser atau yang bisa membaca dan menulis file server atau menjalankan program, jadi beri ia role dengan hak paling kecil, bukan pemiliknya.

Os três templates aqui já põem STORAGE_PROVIDER em sqlite e montam um volume em /app/data, então as conexões salvas ficam no servidor e sobrevivem a um restart. Você não precisa mudar nenhum dos dois. Isso também as deixa onde o agente de banco de dados consegue resolvê-las de novo, embora no PostgreSQL o agente tenha uma segunda condição: ele recusa uma role que seja superuser ou que possa ler ou escrever arquivos do servidor ou rodar programas, então dê a ele uma role de menor privilégio em vez da dona do banco.

A template in the Dokploy catalogue.

Una plantilla en el catálogo de Dokploy.

Dokploy のカタログにあるテンプレート。

Шаблон в каталоге Dokploy.

Dokploy کے کیٹلاگ میں ایک ٹیمپلیٹ۔

Dokploy 目录里的一个模板。

Dokploy 目錄裡的一個範本。

Szablon w katalogu Dokploy.

Un template dans le catalogue Dokploy.

Un template nel catalogo di Dokploy.

Ein Template im Dokploy-Katalog.

Sebuah template di katalog Dokploy.

Um template no catálogo do Dokploy.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

Both of these catalogues currently install 0.9.59, and that matters more than the age. AUTH_COOKIE_SECURE is not in that build, so the usual fix for a plain-HTTP login loop cannot work: set the variable and the cookie is still marked Secure, because nothing reads it. Correct the image tag to a current release where the platform lets you, and where it does not, reach the app over HTTPS instead.

Estos dos catálogos instalan actualmente 0.9.59, y eso importa más que la antigüedad. AUTH_COOKIE_SECURE no está en esa compilación, así que el arreglo habitual para un bucle de inicio de sesión por HTTP plano no puede funcionar: pones la variable y la cookie se sigue marcando Secure, porque nada la lee. Corrige la etiqueta de la imagen a una versión actual allí donde la plataforma te deje, y donde no, llega a la aplicación por HTTPS.

これら二つのカタログが現在入れるのは 0.9.59 で、これは古さ以上に重要です。そのビルドには AUTH_COOKIE_SECURE がありません。ですから平文 HTTP のログインループに対する通常の対処が効きません。変数を設定しても Cookie には Secure が付いたままです。読む側が無いからです。プラットフォームが許すならイメージのタグを現行リリースに直し、許さないなら HTTPS 経由で到達してください。

Оба эти каталога сейчас ставят 0.9.59, и это важнее возраста. В той сборке AUTH_COOKIE_SECURE нет, поэтому обычное решение для зацикленного входа по обычному HTTP не сработает: вы задаёте переменную, а кука всё равно помечается Secure, потому что её никто не читает. Там, где платформа позволяет, исправьте тег образа на текущий выпуск; где не позволяет, заходите по HTTPS.

یہ دونوں کیٹلاگ اِس وقت 0.9.59 نصب کرتے ہیں، اور یہ بات عمر سے زیادہ اہم ہے۔ اُس بلڈ میں AUTH_COOKIE_SECURE ہے ہی نہیں، سو سادہ HTTP والے لاگ اِن چکر کا معمول کا علاج کام نہیں کر سکتا: آپ متغیر مقرر کریں تب بھی کوکی پر Secure لگا رہتا ہے، کیونکہ اسے پڑھنے والا کوئی نہیں۔ جہاں پلیٹ فارم اجازت دے وہاں امیج کا ٹیگ موجودہ ریلیز پر درست کریں، اور جہاں نہ دے، ایپ تک HTTPS سے پہنچیں۔

这两个目录目前装的都是 0.9.59，而这件事比年纪更要紧。那个构建里根本没有 AUTH_COOKIE_SECURE，所以针对明文 HTTP 登录死循环的常规解法在这里不成立：你把变量设上，cookie 照样被打上 Secure，因为没有东西会去读它。平台允许的话，把镜像标签改成当前版本；不允许的话，就改用 HTTPS 访问。

這兩個目錄目前裝的都是 0.9.59，而這件事比年紀更要緊。那個建置裡根本沒有 AUTH_COOKIE_SECURE，所以針對明文 HTTP 登入死迴圈的常規解法在這裡不成立：你把變數設上，cookie 照樣被打上 Secure，因為沒有東西會去讀它。平台允許的話，把映像檔標籤改成目前版本；不允許的話，就改用 HTTPS 存取。

Oba te katalogi instalują obecnie 0.9.59, a to waży więcej niż sam wiek. W tamtym buildzie nie ma AUTH_COOKIE_SECURE, więc zwykła poprawka na pętlę logowania po czystym HTTP nie ma prawa zadziałać: ustawisz zmienną, a ciasteczko dalej jest oznaczone jako Secure, bo nic tej zmiennej nie czyta. Popraw tag obrazu na aktualne wydanie tam, gdzie platforma ci na to pozwala, a gdzie nie pozwala, sięgaj do aplikacji po HTTPS.

Ces deux catalogues installent actuellement la 0.9.59, et cela compte plus que leur âge. AUTH_COOKIE_SECURE n'est pas dans ce build, donc le remède habituel à une boucle de connexion en HTTP simple ne peut pas fonctionner : vous définissez la variable et le cookie reste marqué Secure, parce que rien ne la lit. Corrigez le tag de l'image vers une release actuelle là où la plateforme vous le permet, et là où elle ne le permet pas, atteignez plutôt l'application en HTTPS.

Tutti e due questi cataloghi al momento installano la 0.9.59, e questo conta più dell'età. AUTH_COOKIE_SECURE in quella build non c'è, quindi il rimedio solito per un ciclo di login in HTTP semplice non può funzionare: imposti la variabile e il cookie resta marcato Secure, perché non la legge nessuno. Correggi il tag dell'immagine su una release attuale dove la piattaforma te lo permette, e dove non te lo permette raggiungi l'app in HTTPS.

Beide dieser Kataloge installieren derzeit 0.9.59, und das wiegt schwerer als das Alter. AUTH_COOKIE_SECURE steckt in diesem Build nicht drin, die übliche Korrektur gegen eine Login-Schleife über einfaches HTTP kann also nicht greifen: du setzt die Variable, und das Cookie ist trotzdem als Secure markiert, weil sie niemand liest. Korrigiere den Image-Tag auf ein aktuelles Release, wo die Plattform dich lässt, und wo nicht, erreiche die App stattdessen über HTTPS.

Kedua katalog ini saat ini memasang 0.9.59, dan itu lebih penting daripada soal usia. AUTH_COOKIE_SECURE tidak ada di build itu, jadi perbaikan biasa untuk login loop di HTTP polos tidak bisa bekerja: set variabelnya dan cookie tetap ditandai Secure, karena tidak ada yang membacanya. Perbaiki tag image ke rilis terkini di platform yang mengizinkan Anda melakukannya, dan di platform yang tidak mengizinkan, jangkau aplikasinya lewat HTTPS sebagai gantinya.

Estes dois catálogos hoje instalam a 0.9.59, e isso pesa mais que a idade. AUTH_COOKIE_SECURE não está nesse build, então a correção de sempre para o loop de login em HTTP puro não funciona: você define a variável e o cookie continua marcado como Secure, porque nada lê essa variável. Corrija a tag da imagem para uma release atual onde a plataforma deixar, e onde não deixar, acesse o app por HTTPS.

Where saved connections go

Dónde van las conexiones guardadas

保存した接続の行き先

Куда попадают сохранённые подключения

محفوظ کنکشن کہاں جاتے ہیں

保存的连接去了哪里

儲存的連線去了哪裡

Gdzie trafiają zapisane połączenia

Où vont les connexions enregistrées

Dove finiscono le connessioni salvate

Wohin gespeicherte Verbindungen gehen

Ke mana koneksi tersimpan pergi

Para onde vão as conexões salvas

All three of these templates already set STORAGE_PROVIDER to sqlite and mount a volume at /app/data, so saved connections are on the server and survive a restart. You do not have to change either. That also puts them where the database agent can re-resolve them, though on PostgreSQL the agent has a second condition: it refuses a role that is a superuser or can read or write server files or run programs, so give it a least-privilege role rather than the owner.

Las tres plantillas ya ponen STORAGE_PROVIDER a sqlite y montan un volumen en /app/data, así que las conexiones guardadas están en el servidor y sobreviven a un reinicio. No tienes que cambiar ninguna de las dos cosas. Eso también las deja donde el agente de base de datos puede volver a resolverlas, aunque en PostgreSQL el agente tiene una segunda condición: rechaza un rol que sea superusuario o que pueda leer o escribir archivos del servidor o ejecutar programas, así que dale un rol de mínimo privilegio y no el propietario.

これら三つのテンプレートは、いずれもすでに STORAGE_PROVIDER を sqlite にし、/app/data にボリュームをマウントしています。保存した接続はサーバー側にあり、再起動しても残ります。どちらも変える必要はありません。おかげでデータベースエージェントが接続を解決し直せる場所にも置かれます。ただし PostgreSQL では、エージェントにもう一つ条件があります。スーパーユーザーであるロール、サーバーのファイルを読み書きできるロール、プログラムを実行できるロールは拒まれます。所有者ではなく、最小権限のロールを渡してください。

Все три шаблона уже ставят STORAGE_PROVIDER в sqlite и монтируют том в /app/data, так что сохранённые подключения лежат на сервере и переживают перезапуск. Менять ничего не нужно. Заодно они оказываются там, где агент базы данных сможет их заново разрешить, правда, на PostgreSQL у агента есть второе условие: он отказывает роли, которая является суперпользователем либо может читать и писать файлы сервера или запускать программы, так что дайте ему роль с минимальными правами, а не владельца.

یہ تینوں ٹیمپلیٹ پہلے ہی STORAGE_PROVIDER کو sqlite کرتے ہیں اور /app/data پر ایک والیوم لگاتے ہیں، سو محفوظ کیے گئے کنکشن سرور پر رہتے ہیں اور ری اسٹارٹ کے بعد بھی باقی۔ آپ کو ان میں سے کچھ بدلنے کی ضرورت نہیں۔ اس سے وہ اُس جگہ بھی آ جاتے ہیں جہاں ڈیٹابیس ایجنٹ انہیں دوبارہ حل کر سکے، اگرچہ PostgreSQL پر ایجنٹ کی ایک دوسری شرط بھی ہے: وہ ایسے رول کو رد کرتا ہے جو سپر یوزر ہو، یا سرور کی فائلیں پڑھ لکھ سکتا ہو، یا پروگرام چلا سکتا ہو۔ سو اسے مالک کے بجائے کم سے کم اختیار والا رول دیں۔

这三个模板都已经把 STORAGE_PROVIDER 设成 sqlite，并在 /app/data 挂了卷，所以保存的连接在服务端，重启也还在。两样都不用你改。这也把它们放在了数据库智能体能重新解析到的地方，不过在 PostgreSQL 上智能体还有第二个条件：它会拒绝超级用户角色，以及能读写服务端文件或执行程序的角色，所以请给它一个最小权限的角色，而不是属主。

這三個範本都已經把 STORAGE_PROVIDER 設成 sqlite，並在 /app/data 掛了磁碟區，所以儲存的連線在伺服器端，重啟也還在。兩樣都不用你改。這也把它們放在了資料庫智慧代理能重新解析到的地方。不過在 PostgreSQL 上智慧代理還有第二個條件：它會拒絕超級使用者角色，以及能讀寫伺服器端檔案或執行程式的角色，所以請給它一個最小權限的角色，而不是擁有者。

Wszystkie trzy te szablony ustawiają już STORAGE_PROVIDER na sqlite i montują wolumen w /app/data, więc zapisane połączenia są na serwerze i przeżywają restart. Żadnego z tych dwóch nie musisz zmieniać. To stawia je też tam, gdzie agent bazy danych może je ponownie rozwiązać, choć na PostgreSQL-u agent ma drugi warunek: odmawia roli, która jest superuserem albo potrafi czytać i zapisywać pliki serwera lub uruchamiać programy, więc daj mu rolę o minimalnych uprawnieniach, a nie właściciela.

Ces trois templates règlent déjà STORAGE_PROVIDER sur sqlite et montent un volume sur /app/data, si bien que les connexions enregistrées sont sur le serveur et survivent à un redémarrage. Vous n'avez à changer ni l'un ni l'autre. Cela les place aussi là où l'agent de base de données peut les re-résoudre, même si sur PostgreSQL l'agent a une seconde condition : il refuse un rôle superuser ou capable de lire ou d'écrire des fichiers serveur ou d'exécuter des programmes, donnez-lui donc un rôle à privilèges minimaux plutôt que le propriétaire.

Tutti e tre questi template impostano già STORAGE_PROVIDER a sqlite e montano un volume su /app/data, quindi le connessioni salvate stanno sul server e sopravvivono a un riavvio. Non devi cambiare né l'uno né l'altro. Questo le mette anche dove l'agente di database può risolverle di nuovo, anche se su PostgreSQL l'agente ha una seconda condizione: rifiuta un ruolo che sia superuser o che possa leggere o scrivere file sul server o eseguire programmi, quindi dagli un ruolo con i privilegi minimi invece del proprietario.

Alle drei dieser Templates setzen STORAGE_PROVIDER bereits auf sqlite und hängen ein Volume unter /app/data ein, gespeicherte Verbindungen liegen also auf dem Server und überstehen einen Neustart. Du musst an beidem nichts ändern. Damit liegen sie auch dort, wo der Datenbank-Agent sie neu auflösen kann, wobei der Agent auf PostgreSQL eine zweite Bedingung hat: er verweigert eine Rolle, die Superuser ist oder Serverdateien lesen oder schreiben oder Programme ausführen kann. Gib ihm also eine Rolle mit minimalen Rechten statt des Owners.

Ketiga template ini sudah men-set STORAGE_PROVIDER ke sqlite dan me-mount volume di /app/data, jadi koneksi tersimpan ada di server dan selamat dari restart. Anda tidak perlu mengubah keduanya. Itu juga menaruhnya di tempat yang bisa di-resolve ulang oleh agent database, meski pada PostgreSQL agent punya syarat kedua: ia menolak role yang superuser atau yang bisa membaca dan menulis file server atau menjalankan program, jadi beri ia role dengan hak paling kecil, bukan pemiliknya.

Os três templates aqui já põem STORAGE_PROVIDER em sqlite e montam um volume em /app/data, então as conexões salvas ficam no servidor e sobrevivem a um restart. Você não precisa mudar nenhum dos dois. Isso também as deixa onde o agente de banco de dados consegue resolvê-las de novo, embora no PostgreSQL o agente tenha uma segunda condição: ele recusa uma role que seja superuser ou que possa ler ou escrever arquivos do servidor ou rodar programas, então dê a ele uma role de menor privilégio em vez da dona do banco.

A servapp in the Cosmos marketplace.

Una servapp en el marketplace de Cosmos.

Cosmos マーケットプレイスの servapp。

Servapp в маркетплейсе Cosmos.

Cosmos مارکیٹ پلیس میں ایک servapp۔

Cosmos 市场里的一个 servapp。

Cosmos 市場裡的一個 servapp。

Servapp w marketplace Cosmos.

Une servapp dans la marketplace Cosmos.

Una servapp nel marketplace di Cosmos.

Eine Servapp im Cosmos-Marktplatz.

Sebuah servapp di marketplace Cosmos.

Um servapp no marketplace do Cosmos.

Check the version first

Primero comprueba la versión

まずバージョンを確かめる

Сначала проверьте версию

پہلے ورژن جانچیں

先看版本

先看版本

Najpierw sprawdź wersję

Vérifiez d'abord la version

Prima controlla la versione

Prüf zuerst die Version

Periksa versinya lebih dulu

Confira a versão primeiro

Both of these catalogues currently install 0.9.59, and that matters more than the age. AUTH_COOKIE_SECURE is not in that build, so the usual fix for a plain-HTTP login loop cannot work: set the variable and the cookie is still marked Secure, because nothing reads it. Correct the image tag to a current release where the platform lets you, and where it does not, reach the app over HTTPS instead.

Estos dos catálogos instalan actualmente 0.9.59, y eso importa más que la antigüedad. AUTH_COOKIE_SECURE no está en esa compilación, así que el arreglo habitual para un bucle de inicio de sesión por HTTP plano no puede funcionar: pones la variable y la cookie se sigue marcando Secure, porque nada la lee. Corrige la etiqueta de la imagen a una versión actual allí donde la plataforma te deje, y donde no, llega a la aplicación por HTTPS.

これら二つのカタログが現在入れるのは 0.9.59 で、これは古さ以上に重要です。そのビルドには AUTH_COOKIE_SECURE がありません。ですから平文 HTTP のログインループに対する通常の対処が効きません。変数を設定しても Cookie には Secure が付いたままです。読む側が無いからです。プラットフォームが許すならイメージのタグを現行リリースに直し、許さないなら HTTPS 経由で到達してください。

Оба эти каталога сейчас ставят 0.9.59, и это важнее возраста. В той сборке AUTH_COOKIE_SECURE нет, поэтому обычное решение для зацикленного входа по обычному HTTP не сработает: вы задаёте переменную, а кука всё равно помечается Secure, потому что её никто не читает. Там, где платформа позволяет, исправьте тег образа на текущий выпуск; где не позволяет, заходите по HTTPS.

یہ دونوں کیٹلاگ اِس وقت 0.9.59 نصب کرتے ہیں، اور یہ بات عمر سے زیادہ اہم ہے۔ اُس بلڈ میں AUTH_COOKIE_SECURE ہے ہی نہیں، سو سادہ HTTP والے لاگ اِن چکر کا معمول کا علاج کام نہیں کر سکتا: آپ متغیر مقرر کریں تب بھی کوکی پر Secure لگا رہتا ہے، کیونکہ اسے پڑھنے والا کوئی نہیں۔ جہاں پلیٹ فارم اجازت دے وہاں امیج کا ٹیگ موجودہ ریلیز پر درست کریں، اور جہاں نہ دے، ایپ تک HTTPS سے پہنچیں۔

这两个目录目前装的都是 0.9.59，而这件事比年纪更要紧。那个构建里根本没有 AUTH_COOKIE_SECURE，所以针对明文 HTTP 登录死循环的常规解法在这里不成立：你把变量设上，cookie 照样被打上 Secure，因为没有东西会去读它。平台允许的话，把镜像标签改成当前版本；不允许的话，就改用 HTTPS 访问。

這兩個目錄目前裝的都是 0.9.59，而這件事比年紀更要緊。那個建置裡根本沒有 AUTH_COOKIE_SECURE，所以針對明文 HTTP 登入死迴圈的常規解法在這裡不成立：你把變數設上，cookie 照樣被打上 Secure，因為沒有東西會去讀它。平台允許的話，把映像檔標籤改成目前版本；不允許的話，就改用 HTTPS 存取。

Oba te katalogi instalują obecnie 0.9.59, a to waży więcej niż sam wiek. W tamtym buildzie nie ma AUTH_COOKIE_SECURE, więc zwykła poprawka na pętlę logowania po czystym HTTP nie ma prawa zadziałać: ustawisz zmienną, a ciasteczko dalej jest oznaczone jako Secure, bo nic tej zmiennej nie czyta. Popraw tag obrazu na aktualne wydanie tam, gdzie platforma ci na to pozwala, a gdzie nie pozwala, sięgaj do aplikacji po HTTPS.

Ces deux catalogues installent actuellement la 0.9.59, et cela compte plus que leur âge. AUTH_COOKIE_SECURE n'est pas dans ce build, donc le remède habituel à une boucle de connexion en HTTP simple ne peut pas fonctionner : vous définissez la variable et le cookie reste marqué Secure, parce que rien ne la lit. Corrigez le tag de l'image vers une release actuelle là où la plateforme vous le permet, et là où elle ne le permet pas, atteignez plutôt l'application en HTTPS.

Tutti e due questi cataloghi al momento installano la 0.9.59, e questo conta più dell'età. AUTH_COOKIE_SECURE in quella build non c'è, quindi il rimedio solito per un ciclo di login in HTTP semplice non può funzionare: imposti la variabile e il cookie resta marcato Secure, perché non la legge nessuno. Correggi il tag dell'immagine su una release attuale dove la piattaforma te lo permette, e dove non te lo permette raggiungi l'app in HTTPS.

Beide dieser Kataloge installieren derzeit 0.9.59, und das wiegt schwerer als das Alter. AUTH_COOKIE_SECURE steckt in diesem Build nicht drin, die übliche Korrektur gegen eine Login-Schleife über einfaches HTTP kann also nicht greifen: du setzt die Variable, und das Cookie ist trotzdem als Secure markiert, weil sie niemand liest. Korrigiere den Image-Tag auf ein aktuelles Release, wo die Plattform dich lässt, und wo nicht, erreiche die App stattdessen über HTTPS.

Kedua katalog ini saat ini memasang 0.9.59, dan itu lebih penting daripada soal usia. AUTH_COOKIE_SECURE tidak ada di build itu, jadi perbaikan biasa untuk login loop di HTTP polos tidak bisa bekerja: set variabelnya dan cookie tetap ditandai Secure, karena tidak ada yang membacanya. Perbaiki tag image ke rilis terkini di platform yang mengizinkan Anda melakukannya, dan di platform yang tidak mengizinkan, jangkau aplikasinya lewat HTTPS sebagai gantinya.

Estes dois catálogos hoje instalam a 0.9.59, e isso pesa mais que a idade. AUTH_COOKIE_SECURE não está nesse build, então a correção de sempre para o loop de login em HTTP puro não funciona: você define a variável e o cookie continua marcado como Secure, porque nada lê essa variável. Corrija a tag da imagem para uma release atual onde a plataforma deixar, e onde não deixar, acesse o app por HTTPS.

Where saved connections go

Dónde van las conexiones guardadas

保存した接続の行き先

Куда попадают сохранённые подключения

محفوظ کنکشن کہاں جاتے ہیں

保存的连接去了哪里

儲存的連線去了哪裡

Gdzie trafiają zapisane połączenia

Où vont les connexions enregistrées

Dove finiscono le connessioni salvate

Wohin gespeicherte Verbindungen gehen

Ke mana koneksi tersimpan pergi

Para onde vão as conexões salvas

All three of these templates already set STORAGE_PROVIDER to sqlite and mount a volume at /app/data, so saved connections are on the server and survive a restart. You do not have to change either. That also puts them where the database agent can re-resolve them, though on PostgreSQL the agent has a second condition: it refuses a role that is a superuser or can read or write server files or run programs, so give it a least-privilege role rather than the owner.

Las tres plantillas ya ponen STORAGE_PROVIDER a sqlite y montan un volumen en /app/data, así que las conexiones guardadas están en el servidor y sobreviven a un reinicio. No tienes que cambiar ninguna de las dos cosas. Eso también las deja donde el agente de base de datos puede volver a resolverlas, aunque en PostgreSQL el agente tiene una segunda condición: rechaza un rol que sea superusuario o que pueda leer o escribir archivos del servidor o ejecutar programas, así que dale un rol de mínimo privilegio y no el propietario.

これら三つのテンプレートは、いずれもすでに STORAGE_PROVIDER を sqlite にし、/app/data にボリュームをマウントしています。保存した接続はサーバー側にあり、再起動しても残ります。どちらも変える必要はありません。おかげでデータベースエージェントが接続を解決し直せる場所にも置かれます。ただし PostgreSQL では、エージェントにもう一つ条件があります。スーパーユーザーであるロール、サーバーのファイルを読み書きできるロール、プログラムを実行できるロールは拒まれます。所有者ではなく、最小権限のロールを渡してください。

Все три шаблона уже ставят STORAGE_PROVIDER в sqlite и монтируют том в /app/data, так что сохранённые подключения лежат на сервере и переживают перезапуск. Менять ничего не нужно. Заодно они оказываются там, где агент базы данных сможет их заново разрешить, правда, на PostgreSQL у агента есть второе условие: он отказывает роли, которая является суперпользователем либо может читать и писать файлы сервера или запускать программы, так что дайте ему роль с минимальными правами, а не владельца.

یہ تینوں ٹیمپلیٹ پہلے ہی STORAGE_PROVIDER کو sqlite کرتے ہیں اور /app/data پر ایک والیوم لگاتے ہیں، سو محفوظ کیے گئے کنکشن سرور پر رہتے ہیں اور ری اسٹارٹ کے بعد بھی باقی۔ آپ کو ان میں سے کچھ بدلنے کی ضرورت نہیں۔ اس سے وہ اُس جگہ بھی آ جاتے ہیں جہاں ڈیٹابیس ایجنٹ انہیں دوبارہ حل کر سکے، اگرچہ PostgreSQL پر ایجنٹ کی ایک دوسری شرط بھی ہے: وہ ایسے رول کو رد کرتا ہے جو سپر یوزر ہو، یا سرور کی فائلیں پڑھ لکھ سکتا ہو، یا پروگرام چلا سکتا ہو۔ سو اسے مالک کے بجائے کم سے کم اختیار والا رول دیں۔

这三个模板都已经把 STORAGE_PROVIDER 设成 sqlite，并在 /app/data 挂了卷，所以保存的连接在服务端，重启也还在。两样都不用你改。这也把它们放在了数据库智能体能重新解析到的地方，不过在 PostgreSQL 上智能体还有第二个条件：它会拒绝超级用户角色，以及能读写服务端文件或执行程序的角色，所以请给它一个最小权限的角色，而不是属主。

這三個範本都已經把 STORAGE_PROVIDER 設成 sqlite，並在 /app/data 掛了磁碟區，所以儲存的連線在伺服器端，重啟也還在。兩樣都不用你改。這也把它們放在了資料庫智慧代理能重新解析到的地方。不過在 PostgreSQL 上智慧代理還有第二個條件：它會拒絕超級使用者角色，以及能讀寫伺服器端檔案或執行程式的角色，所以請給它一個最小權限的角色，而不是擁有者。

Wszystkie trzy te szablony ustawiają już STORAGE_PROVIDER na sqlite i montują wolumen w /app/data, więc zapisane połączenia są na serwerze i przeżywają restart. Żadnego z tych dwóch nie musisz zmieniać. To stawia je też tam, gdzie agent bazy danych może je ponownie rozwiązać, choć na PostgreSQL-u agent ma drugi warunek: odmawia roli, która jest superuserem albo potrafi czytać i zapisywać pliki serwera lub uruchamiać programy, więc daj mu rolę o minimalnych uprawnieniach, a nie właściciela.

Ces trois templates règlent déjà STORAGE_PROVIDER sur sqlite et montent un volume sur /app/data, si bien que les connexions enregistrées sont sur le serveur et survivent à un redémarrage. Vous n'avez à changer ni l'un ni l'autre. Cela les place aussi là où l'agent de base de données peut les re-résoudre, même si sur PostgreSQL l'agent a une seconde condition : il refuse un rôle superuser ou capable de lire ou d'écrire des fichiers serveur ou d'exécuter des programmes, donnez-lui donc un rôle à privilèges minimaux plutôt que le propriétaire.

Tutti e tre questi template impostano già STORAGE_PROVIDER a sqlite e montano un volume su /app/data, quindi le connessioni salvate stanno sul server e sopravvivono a un riavvio. Non devi cambiare né l'uno né l'altro. Questo le mette anche dove l'agente di database può risolverle di nuovo, anche se su PostgreSQL l'agente ha una seconda condizione: rifiuta un ruolo che sia superuser o che possa leggere o scrivere file sul server o eseguire programmi, quindi dagli un ruolo con i privilegi minimi invece del proprietario.

Alle drei dieser Templates setzen STORAGE_PROVIDER bereits auf sqlite und hängen ein Volume unter /app/data ein, gespeicherte Verbindungen liegen also auf dem Server und überstehen einen Neustart. Du musst an beidem nichts ändern. Damit liegen sie auch dort, wo der Datenbank-Agent sie neu auflösen kann, wobei der Agent auf PostgreSQL eine zweite Bedingung hat: er verweigert eine Rolle, die Superuser ist oder Serverdateien lesen oder schreiben oder Programme ausführen kann. Gib ihm also eine Rolle mit minimalen Rechten statt des Owners.

Ketiga template ini sudah men-set STORAGE_PROVIDER ke sqlite dan me-mount volume di /app/data, jadi koneksi tersimpan ada di server dan selamat dari restart. Anda tidak perlu mengubah keduanya. Itu juga menaruhnya di tempat yang bisa di-resolve ulang oleh agent database, meski pada PostgreSQL agent punya syarat kedua: ia menolak role yang superuser atau yang bisa membaca dan menulis file server atau menjalankan program, jadi beri ia role dengan hak paling kecil, bukan pemiliknya.

Os três templates aqui já põem STORAGE_PROVIDER em sqlite e montam um volume em /app/data, então as conexões salvas ficam no servidor e sobrevivem a um restart. Você não precisa mudar nenhum dos dois. Isso também as deixa onde o agente de banco de dados consegue resolvê-las de novo, embora no PostgreSQL o agente tenha uma segunda condição: ele recusa uma role que seja superuser ou que possa ler ou escrever arquivos do servidor ou rodar programas, então dê a ele uma role de menor privilégio em vez da dona do banco.

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

Proxmox VE

There is no Proxmox template. You run the container inside an LXC or a VM.

No hay plantilla de Proxmox. El contenedor se ejecuta dentro de un LXC o de una máquina virtual.

Proxmox 用のテンプレートはありません。LXC か VM の中でコンテナを動かします。

Шаблона для Proxmox нет. Контейнер запускается внутри LXC или виртуальной машины.

Proxmox کے لیے کوئی ٹیمپلیٹ نہیں ہے۔ کنٹینر آپ کسی LXC یا VM کے اندر چلاتے ہیں۔

没有 Proxmox 模板。容器要跑在 LXC 或虚拟机里面。

沒有 Proxmox 範本。容器要跑在 LXC 或虛擬機器裡面。

Nie ma szablonu dla Proxmoxa. Kontener uruchamiasz w LXC albo w maszynie wirtualnej.

Il n'y a pas de template Proxmox. Vous faites tourner le container dans un LXC ou une VM.

Non esiste un template Proxmox. Il container lo fai girare dentro un LXC o una VM.

Es gibt kein Proxmox-Template. Du betreibst den Container in einem LXC oder einer VM.

Tidak ada template Proxmox. Anda menjalankan container-nya di dalam sebuah LXC atau VM.

Não existe template de Proxmox. Você roda o container dentro de um LXC ou de uma VM.

Proxmox is not an app store, so there is nothing to click. What you do is create a small guest, install Docker in it, and then follow the Docker Compose instructions. This is worth saying plainly because the Proxmox variable is where the login loop bites hardest.

Proxmox no es una tienda de aplicaciones, así que no hay nada que pulsar. Lo que haces es crear un invitado pequeño, instalar Docker dentro y luego seguir las instrucciones de Docker Compose. Merece la pena decirlo claramente, porque la variante Proxmox es donde el bucle de inicio de sesión muerde más fuerte.

Proxmox はアプリストアではないので、押すものは何もありません。やることは、小さなゲストを作り、そこに Docker を入れ、あとは Docker Compose の手順に従うことです。これをはっきり書いておく価値があるのは、ログインループがいちばん強く噛みついてくるのが Proxmox 構成だからです。

Proxmox не магазин приложений, поэтому нажимать нечего. Вы создаёте небольшую гостевую машину, ставите в него Docker, а дальше идёте по инструкции Docker Compose. Это стоит сказать прямо, потому что именно в варианте с Proxmox цикл входа кусается сильнее всего.

Proxmox کوئی ایپ اسٹور نہیں، اس لیے یہاں کلک کرنے کو کچھ نہیں۔ آپ کو کرنا یہ ہے کہ ایک چھوٹا گیسٹ بنائیں، اس میں Docker نصب کریں، اور پھر Docker Compose کی ہدایات پر چلیں۔ یہ صاف کہہ دینا اس لیے ضروری ہے کہ لاگ اِن کا چکر سب سے زیادہ Proxmox والی صورت میں ہی کاٹتا ہے۔

Proxmox 不是应用商店，所以没有什么可点的。你要做的是建一个小的客户机，在里面装上 Docker，然后照着 Docker Compose 的说明走。这一点值得直说，因为登录死循环咬得最狠的就是 Proxmox 这条路。

Proxmox 不是應用商店，所以沒有什麼可點的。你要做的是建一個小的客戶機，在裡面裝上 Docker，然後照著 Docker Compose 的說明走。這一點值得直說，因為登入死迴圈咬得最狠的就是 Proxmox 這條路。

Proxmox nie jest sklepem z aplikacjami, więc nie ma tu nic do klikania. Robisz to tak: tworzysz małego gościa, instalujesz w nim Dockera, a potem idziesz za instrukcją dla Docker Compose. Mówię to wprost, bo to właśnie na wariancie z Proxmoxem pętla logowania gryzie najmocniej.

Proxmox n'est pas un magasin d'applications, il n'y a donc rien à cliquer. Ce que vous faites, c'est créer un petit invité, y installer Docker, puis suivre les instructions Docker Compose. Cela mérite d'être dit clairement parce que c'est dans le cas Proxmox que la boucle de connexion mord le plus fort.

Proxmox non è un app store, quindi non c'è niente da cliccare. Quello che fai è creare un piccolo guest, installarci Docker, e poi seguire le istruzioni di Docker Compose. Vale la pena dirlo chiaramente perché la variante Proxmox è quella in cui il ciclo di login morde più forte.

Proxmox ist kein App Store, es gibt also nichts zu klicken. Was du machst: einen kleinen Gast anlegen, Docker darin installieren und dann der Anleitung für Docker Compose folgen. Das gehört deutlich gesagt, denn bei Proxmox beißt die Login-Schleife am härtesten.

Proxmox bukan app store, jadi tidak ada yang bisa diklik. Yang Anda lakukan adalah membuat guest kecil, memasang Docker di dalamnya, lalu mengikuti instruksi Docker Compose. Ini layak dikatakan terus terang karena pada Proxmox-lah variabel itu paling menggigit lewat login loop.

O Proxmox não é uma loja de apps, então não há nada para clicar. O que você faz é criar um guest pequeno, instalar o Docker nele e depois seguir as instruções do Docker Compose. Vale dizer isso com clareza porque a variável do Proxmox é onde o loop de login morde mais forte.

A container-sized guest

Un invitado del tamaño de un contenedor

コンテナ相当のゲスト

Гость размером с контейнер

کنٹینر کے حجم کا ایک گیسٹ

一个容器大小的客户机

一個容器大小的客戶機

Gość wielkości kontenera

Un invité de la taille d'un container

Un guest della taglia di un container

Ein Gast in Containergröße

Guest seukuran container

Um guest do tamanho de um container

An unprivileged Debian 12 LXC with 1 vCPU, 1 GB RAM and 8 GB disk is enough. The app caps its own Node heap at 384 MB. If you prefer a VM, use whatever you normally use; nothing here is Proxmox specific past this point.

Un LXC Debian 12 sin privilegios con 1 vCPU, 1 GB de RAM y 8 GB de disco es suficiente. La aplicación limita su propio heap de Node a 384 MB. Si prefieres una máquina virtual, usa la que uses normalmente; a partir de aquí nada de esto es específico de Proxmox.

1 vCPU、1 GB RAM、8 GB ディスクの非特権 Debian 12 LXC で十分です。アプリは自分の Node ヒープを 384 MB に抑えます。VM のほうが良ければ普段お使いのもので構いません。ここから先に Proxmox 固有の話はありません。

Непривилегированного LXC с Debian 12, 1 vCPU, 1 ГБ ОЗУ и 8 ГБ диска достаточно. Приложение само ограничивает свою кучу Node 384 мегабайтами. Если предпочитаете виртуальную машину, берите ту, которой обычно пользуетесь; дальше ничего специфичного для Proxmox уже нет.

1 vCPU، 1 GB RAM اور 8 GB ڈسک والا ایک غیر مراعات یافتہ Debian 12 LXC کافی ہے۔ ایپ خود اپنی Node ہیپ 384 MB تک محدود رکھتی ہے۔ اگر آپ VM کو ترجیح دیں تو وہی استعمال کریں جو عام طور پر کرتے ہیں؛ اس نکتے کے بعد یہاں کچھ بھی Proxmox سے مخصوص نہیں۔

一个非特权的 Debian 12 LXC，1 vCPU、1 GB 内存、8 GB 磁盘就够了。应用会把自己的 Node 堆限制在 384 MB。如果你更喜欢虚拟机，用你平时用的那种就行；从这一步往后，就没有任何 Proxmox 特有的内容了。

一個非特權的 Debian 12 LXC，1 vCPU、1 GB 記憶體、8 GB 磁碟就夠了。應用會把自己的 Node 堆限制在 384 MB。如果你更喜歡虛擬機器，用你平時用的那種就行；從這一步往後，就沒有任何 Proxmox 特有的內容了。

Wystarczy nieuprzywilejowany LXC z Debianem 12, 1 vCPU, 1 GB RAM i dyskiem 8 GB. Aplikacja sama ogranicza swój heap Node do 384 MB. Jeśli wolisz maszynę wirtualną, użyj tej, której zwykle używasz; od tego miejsca nic tutaj nie jest specyficzne dla Proxmoxa.

Un LXC Debian 12 non privilégié avec 1 vCPU, 1 Go de RAM et 8 Go de disque suffit. L'application plafonne elle-même son heap Node à 384 Mo. Si vous préférez une VM, prenez celle que vous utilisez d'habitude ; rien ici n'est spécifique à Proxmox au-delà de ce point.

Un LXC Debian 12 non privilegiato con 1 vCPU, 1 GB di RAM e 8 GB di disco basta. L'app limita da sé il proprio heap di Node a 384 MB. Se preferisci una VM, usa quella che usi di solito; da qui in poi niente è specifico di Proxmox.

Ein unprivilegierter Debian-12-LXC mit 1 vCPU, 1 GB RAM und 8 GB Platte reicht. Die App deckelt ihren Node-Heap selbst bei 384 MB. Wenn dir eine VM lieber ist, nimm die, die du sonst nimmst; ab hier ist nichts mehr Proxmox-spezifisch.

Sebuah LXC Debian 12 unprivileged dengan 1 vCPU, RAM 1 GB dan disk 8 GB sudah cukup. Aplikasi membatasi heap Node-nya sendiri di 384 MB. Kalau Anda lebih suka VM, pakai apa pun yang biasa Anda pakai; lewat titik ini tidak ada lagi yang khas Proxmox.

Um LXC Debian 12 não privilegiado com 1 vCPU, 1 GB de RAM e 8 GB de disco basta. O app limita o próprio heap do Node em 384 MB. Se você preferir uma VM, use a que costuma usar; daqui em diante nada é específico do Proxmox.

Docker in an LXC

Docker dentro de un LXC

LXC の中の Docker

Docker внутри LXC

LXC کے اندر Docker

LXC 里的 Docker

LXC 裡的 Docker

Docker w LXC

Docker dans un LXC

Docker dentro un LXC

Docker in einem LXC

Docker di dalam LXC

Docker dentro de um LXC

Docker inside an unprivileged LXC needs nesting and keyctl turned on. From the Proxmox host shell, with your container ID in place of 120:

Docker dentro de un LXC sin privilegios necesita nesting y keyctl activados. Desde la shell del host Proxmox, con el ID de tu contenedor en lugar de 120:

非特権 LXC の中で Docker を動かすには nesting と keyctl を有効にする必要があります。Proxmox ホストのシェルから、120 の部分をご自分のコンテナ ID に置き換えて実行します。

Docker внутри непривилегированного LXC требует включённых nesting и keyctl. Из шелла хоста Proxmox, подставив свой ID контейнера вместо 120:

غیر مراعات یافتہ LXC کے اندر Docker کے لیے nesting اور keyctl کا فعال ہونا ضروری ہے۔ Proxmox ہوسٹ کے شیل سے، 120 کی جگہ اپنی کنٹینر ID رکھ کر:

在非特权 LXC 里跑 Docker，需要打开 nesting 和 keyctl。在 Proxmox 宿主机的 shell 里执行，把 120 换成你自己的容器 ID：

在非特權 LXC 裡跑 Docker，需要打開 nesting 和 keyctl。在 Proxmox 宿主機的 shell 裡執行，把 120 換成你自己的容器 ID：

Docker wewnątrz nieuprzywilejowanego LXC potrzebuje włączonych nesting i keyctl. Z powłoki hosta Proxmox, wstawiając ID swojego kontenera zamiast 120:

Docker à l'intérieur d'un LXC non privilégié a besoin de nesting et keyctl activés. Depuis le shell de l'hôte Proxmox, avec l'ID de votre container à la place de 120 :

Docker dentro un LXC non privilegiato ha bisogno di nesting e keyctl attivi. Dalla shell dell'host Proxmox, con l'ID del tuo container al posto di 120:

Docker in einem unprivilegierten LXC braucht eingeschaltetes nesting und keyctl. Aus der Shell des Proxmox-Hosts, mit deiner Container-ID statt 120:

Docker di dalam LXC unprivileged butuh nesting dan keyctl dinyalakan. Dari shell host Proxmox, dengan ID container Anda menggantikan 120:

Docker dentro de um LXC não privilegiado precisa de nesting e keyctl ligados. Pelo shell do host Proxmox, com o ID do seu container no lugar de 120:

pct set 120 -features nesting=1,keyctl=1
pct start 120   # pct reboot 120 if it is already running

Then inside the guest:

Y después, dentro del invitado:

続いてゲストの中で:

Затем внутри гостя:

پھر گیسٹ کے اندر:

然后在客户机内部：

然後在客戶機內部：

A potem w środku gościa:

Puis à l'intérieur de l'invité :

Poi dentro il guest:

Dann im Gast:

Lalu di dalam guest-nya:

Depois, dentro do guest:

apt update && apt install -y ca-certificates curl
curl -fsSL https://get.docker.com | sh

Then the compose file

Y ahora el fichero compose

そのあと compose ファイル

И потом compose-файл

اس کے بعد compose فائل

接下来是 compose 文件

接下來是 compose 檔案

Potem plik compose

Ensuite le fichier compose

Poi il file compose

Dann die Compose-Datei

Setelah itu compose file-nya

Aí o arquivo compose

Use exactly the compose file from the Docker Compose tab. One line in it matters more here than anywhere else:

Usa exactamente el fichero compose de la pestaña Docker Compose. Una línea importa aquí más que en ningún otro sitio:

Docker Compose タブの compose ファイルをそのまま使ってください。その中の 1 行が、ここではほかのどこよりも重要です。

Возьмите ровно тот compose-файл, что на вкладке Docker Compose. Одна строка в нём здесь важнее, чем где бы то ни было ещё:

بالکل وہی compose فائل استعمال کریں جو Docker Compose ٹیب میں ہے۔ اس کی ایک سطر یہاں کہیں اور کے مقابلے میں زیادہ اہم ہے:

直接用 Docker Compose 标签页里的那份 compose 文件。其中有一行，在这里比在任何别的地方都更要紧：

直接用 Docker Compose 分頁裡的那份 compose 檔案。其中有一行，在這裡比在任何別的地方都更要緊：

Użyj dokładnie tego pliku compose co na karcie Docker Compose. Jedna linia w nim ma tu większe znaczenie niż gdziekolwiek indziej:

Utilisez exactement le fichier compose de l'onglet Docker Compose. Une de ses lignes compte plus ici que partout ailleurs :

Usa esattamente il file compose della scheda Docker Compose. Una riga lì dentro conta qui più che altrove:

Nimm genau die Compose-Datei aus dem Tab Docker Compose. Eine Zeile darin zählt hier mehr als irgendwo sonst:

Pakai persis compose file dari tab Docker Compose. Satu baris di dalamnya lebih penting di sini daripada di mana pun:

Use exatamente o arquivo compose da aba Docker Compose. Uma linha dele importa mais aqui do que em qualquer outro lugar:

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

$ curl -s 192.168.1.50:3000/api/db/health
{"status":"healthy","timestamp":"...","service":"libredb-studio"}

If you are adding the app to a Proxmox monitoring check, use that path. Most of the rest of /api/ will mislead you: some paths redirect to the login screen and read 200 from there, so the check goes green without ever reaching the app.

Si vas a añadir la aplicación a una comprobación de monitorización de Proxmox, usa esa ruta. La mayor parte del resto de /api/ te engañará: algunas rutas redirigen a la pantalla de inicio de sesión y leen 200 desde ahí, así que la comprobación se pone en verde sin llegar nunca a la aplicación.

Proxmox の監視チェックにこのアプリを加えるなら、そのパスを使ってください。/api/ の残りの大半は誤解のもとです。ログイン画面へリダイレクトしてそこから 200 を読むパスがあり、チェックはアプリに届かないまま緑になります。

Если вы добавляете приложение в проверку мониторинга Proxmox, используйте этот путь. Большая часть остального в /api/ вас обманет: некоторые пути перенаправляют на экран входа и читают оттуда 200, так что проверка зеленеет, ни разу не дойдя до приложения.

اگر آپ ایپ کو Proxmox کی نگرانی کی جانچ میں شامل کر رہے ہیں تو وہی راستہ استعمال کریں۔ /api/ کا باقی بیشتر حصہ آپ کو گمراہ کرے گا: کچھ راستے لاگ اِن اسکرین کی طرف موڑ دیتے ہیں اور وہیں سے 200 پڑھا جاتا ہے، سو جانچ ایپ تک پہنچے بغیر سبز ہو جاتی ہے۔

如果你要把这个应用加进 Proxmox 的监控检查，就用这个路径。/api/ 下其余的大部分会误导你：有些路径会跳到登录页并从那里读到 200，于是检查根本没碰到应用就变绿了。

如果你要把這個應用加進 Proxmox 的監控檢查，就用這個路徑。/api/ 下其餘的大部分會誤導你：有些路徑會跳到登入頁並從那裡讀到 200，於是檢查根本沒碰到應用就變綠了。

Jeśli dopinasz aplikację do kontroli monitorującej w Proxmoxie, użyj tej ścieżki. Większość reszty /api/ wprowadzi cię w błąd: część ścieżek przekierowuje na ekran logowania i stamtąd zwraca 200, więc kontrola świeci na zielono, nigdy nie dotknąwszy aplikacji.

Si vous ajoutez l'application à un contrôle de supervision Proxmox, utilisez ce chemin. La plus grande partie du reste de /api/ vous induira en erreur : certains chemins redirigent vers l'écran de connexion et répondent 200 depuis là, si bien que le contrôle passe au vert sans jamais atteindre l'application.

Se stai aggiungendo l'app a un controllo di monitoraggio Proxmox, usa quel percorso. Quasi tutto il resto di /api/ ti porterà fuori strada: alcuni percorsi reindirizzano alla schermata di login e da lì danno 200, quindi il controllo diventa verde senza mai arrivare all'app.

Wenn du die App in eine Proxmox-Überwachung aufnimmst, nimm diesen Pfad. Der Rest von /api/ führt dich meist in die Irre: manche Pfade leiten auf den Login-Bildschirm um und liefern von dort 200, die Prüfung wird also grün, ohne die App je erreicht zu haben.

Kalau Anda menambahkan aplikasi ini ke pemeriksaan monitoring Proxmox, pakai path itu. Sebagian besar sisa /api/ akan menyesatkan Anda: sebagian path mengalihkan ke layar login dan terbaca 200 dari sana, jadi pemeriksaannya jadi hijau tanpa pernah sampai ke aplikasi.

Se você for incluir o app num check de monitoramento do Proxmox, use esse caminho. A maior parte do resto de /api/ vai te enganar: alguns caminhos redirecionam para a tela de login e respondem 200 de lá, então o check fica verde sem nunca chegar no app.

Your own machine, or no machine at all

Tu propia máquina, o ninguna

自分のマシン、あるいはマシンなしで

Своя машина или вообще никакой

آپ کی اپنی مشین، یا کوئی مشین ہی نہیں

你自己的机器，或者根本不用机器

你自己的機器，或者根本不用機器

Twoja własna maszyna albo żadna maszyna

Votre propre machine, ou aucune machine du tout

La tua macchina, o nessuna macchina

Dein eigener Rechner, oder gar kein Rechner

Mesin Anda sendiri, atau tanpa mesin sama sekali

Sua própria máquina, ou máquina nenhuma

Nine package channels and two hosted instances. No server required.

Nueve canales de paquetes y dos instancias alojadas. Sin servidor.

九つのパッケージ経路と、二つのホスト版。サーバーは要りません。

Девять пакетных каналов и два размещённых экземпляра. Сервер не нужен.

نو پیکیج راستے اور دو میزبان شدہ انسٹینس۔ سرور کی ضرورت نہیں۔

九条软件包渠道，两个托管实例。不需要服务器。

九條套件通道，兩個託管實例。不需要伺服器。

Dziewięć kanałów pakietowych i dwie hostowane instancje. Serwer niepotrzebny.

Neuf canaux de paquets et deux instances hébergées. Aucun serveur nécessaire.

Nove canali di pacchetti e due istanze ospitate. Nessun server richiesto.

Neun Paketkanäle und zwei gehostete Instanzen. Kein Server nötig.

Sembilan kanal paket dan dua instance yang sudah dihosting. Tidak perlu server.

Nove canais de pacote e duas instâncias hospedadas. Sem servidor.

Try it without installing anything

Pruébalo sin instalar nada

何もインストールせずに試す

Попробовать, ничего не устанавливая

کچھ نصب کیے بغیر آزمائیں

什么都不装就试用

什麼都不裝就試用

Wypróbuj bez instalowania czegokolwiek

Essayez-le sans rien installer

Provalo senza installare niente

Ausprobieren, ohne etwas zu installieren

Coba tanpa memasang apa pun

Experimente sem instalar nada

Two instances are already running and open to the public. app.libredb.org runs 0.17.0, the release described here, and is wired to single sign-on, so it is also what the OIDC screen from step 01 looks like in the wild. trial.libredb.org signs you in with a password instead: admin@libredb.org / Admin!2026 for the administrator, or user@libredb.org / User!2026 for the lower-privilege account, which is the quickest way to see what the two roles actually differ on. It is on 0.15.0 today, older than these pages, so treat small differences as age rather than error. Both open on the two sample databases that ship inside the image.

Hay dos instancias en marcha y abiertas al público. app.libredb.org ejecuta la 0.17.0, la versión descrita aquí, y está conectada a inicio de sesión único, así que también es el aspecto que tiene en la práctica la pantalla OIDC del paso 01. trial.libredb.org te deja entrar con contraseña: admin@libredb.org / Admin!2026 para el administrador, o user@libredb.org / User!2026 para la cuenta de menos privilegios, que es la forma más rápida de ver en qué se diferencian los dos roles. Hoy está en la 0.15.0, más antigua que estas páginas, así que toma las diferencias pequeñas como antigüedad y no como error. Las dos abren sobre las dos bases de datos de ejemplo que vienen dentro de la imagen.

公開されて動いているインスタンスが二つあります。app.libredb.org はここで説明しているリリース、0.17.0 で動き、シングルサインオンにつながっています。01 の OIDC 画面が実運用でどう見えるかも、ここで確かめられます。trial.libredb.org のほうはパスワードでログインします。管理者は admin@libredb.org / Admin!2026、権限の低いほうは user@libredb.org / User!2026 で、二つのロールが実際どこで違うのかを一番手早く確かめられます。こちらは今日の時点で 0.15.0、これらのページより古いので、細かな違いは誤りではなく古さと考えてください。どちらもイメージに同梱された二つのサンプルデータベースを開いた状態で始まります。

Два экземпляра работают и открыты для всех. app.libredb.org работает на 0.17.0 (том выпуске, о котором здесь речь) и подключён к единому входу, так что заодно показывает, как экран OIDC из шага 01 выглядит в жизни. trial.libredb.org пускает по паролю: admin@libredb.org / Admin!2026 для администратора или user@libredb.org / User!2026 для учётной записи с меньшими правами, это самый быстрый способ увидеть, чем две роли различаются. Сегодня он на 0.15.0, старше этих страниц, так что мелкие расхождения считайте возрастом, а не ошибкой. Оба открываются на двух демонстрационных базах, которые лежат внутри образа.

دو انسٹینس پہلے سے چل رہے ہیں اور سب کے لیے کھلے ہیں۔ app.libredb.org پر 0.17.0 چل رہی ہے، یعنی وہی ریلیز جو یہاں بیان ہوئی ہے، اور یہ سنگل سائن آن سے جڑی ہے؛ سو مرحلہ 01 والی OIDC اسکرین عملی دنیا میں کیسی لگتی ہے، وہ بھی یہیں دکھتا ہے۔ trial.libredb.org پاس ورڈ سے داخل کرتا ہے: منتظم کے لیے admin@libredb.org / Admin!2026، یا کم اختیار والے اکاؤنٹ کے لیے user@libredb.org / User!2026، اور یہی سب سے تیز طریقہ ہے یہ دیکھنے کا کہ دونوں کردار کہاں مختلف ہیں۔ آج یہ 0.15.0 پر ہے، ان صفحات سے پرانا، سو چھوٹے فرق کو غلطی نہیں، پرانا پن سمجھیں۔ دونوں اُن دو نمونہ ڈیٹابیسوں پر کھلتے ہیں جو امیج کے اندر آتے ہیں۔

有两个实例已经在跑，而且对所有人开放。app.libredb.org 跑的是 0.17.0，也就是这里讲的版本，并且接了单点登录，所以第 01 步那块 OIDC 界面在现实中的样子也能在这儿看到。trial.libredb.org 则用密码登录：管理员是 admin@libredb.org / Admin!2026，权限较低的账号是 user@libredb.org / User!2026，这是看清两种角色差在哪儿最快的办法。它今天在 0.15.0，比这些页面旧，所以细小的出入请当成年纪，不是错误。两个都会打开镜像里自带的那两个示例数据库。

有兩個實例已經在跑，而且對所有人開放。app.libredb.org 跑的是 0.17.0，也就是這裡講的版本，並且接了單一登入，所以第 01 步那塊 OIDC 介面在現實中的樣子也能在這兒看到。trial.libredb.org 則用密碼登入：管理員是 admin@libredb.org / Admin!2026，權限較低的帳號是 user@libredb.org / User!2026，這是看清兩種角色差在哪兒最快的辦法。它今天在 0.15.0，比這些頁面舊，所以細小的出入請當成年紀，不是錯誤。兩個都會打開映像檔裡自帶的那兩個範例資料庫。

Dwie instancje już działają i są otwarte dla wszystkich. app.libredb.org chodzi na 0.17.0, czyli wydaniu opisywanym tutaj, i jest podpięte do logowania jednokrotnego, więc przy okazji pokazuje, jak ekran OIDC z kroku 01 wygląda na żywo. trial.libredb.org loguje cię zamiast tego hasłem: admin@libredb.org / Admin!2026 dla administratora albo user@libredb.org / User!2026 dla konta o niższych uprawnieniach, co jest najszybszym sposobem, żeby zobaczyć, czym te dwie role faktycznie się różnią. Chodzi dziś na 0.15.0, starszej niż te strony, więc drobne różnice traktuj jak wiek, a nie błąd. Obie otwierają się na dwóch przykładowych bazach danych, które jadą w środku obrazu.

Deux instances tournent déjà et sont ouvertes au public. app.libredb.org fait tourner la 0.17.0, la release décrite ici, et elle est branchée sur l'authentification unique, c'est donc aussi à quoi ressemble l'écran OIDC de l'étape 01 dans la vraie vie. trial.libredb.org vous connecte plutôt par mot de passe : admin@libredb.org / Admin!2026 pour l'administrateur, ou user@libredb.org / User!2026 pour le compte à privilèges réduits, ce qui est le moyen le plus rapide de voir sur quoi les deux rôles diffèrent réellement. Elle est aujourd'hui en 0.15.0, plus ancienne que ces pages, traitez donc les petites différences comme un écart d'âge et non comme une erreur. Les deux s'ouvrent sur les deux bases de données d'exemple livrées dans l'image.

Due istanze sono già in funzione e aperte al pubblico. app.libredb.org gira sulla 0.17.0, la release descritta qui, ed è collegata al single sign-on, quindi è anche l'aspetto che la schermata OIDC del passo 01 ha sul campo. trial.libredb.org ti fa accedere con una password: admin@libredb.org / Admin!2026 per l'amministratore, oppure user@libredb.org / User!2026 per l'account con meno privilegi, che è il modo più rapido per vedere in cosa i due ruoli differiscono davvero. Oggi è sulla 0.15.0, più vecchia di queste pagine, quindi leggi le piccole differenze come età e non come errore. Tutte e due si aprono sui due database di esempio che viaggiano dentro l'immagine.

Zwei Instanzen laufen bereits und stehen allen offen. app.libredb.org läuft auf 0.17.0, dem hier beschriebenen Release, und hängt an Single Sign-on, damit siehst du dort auch, wie der OIDC-Bildschirm aus Schritt 01 in freier Wildbahn aussieht. trial.libredb.org meldet dich stattdessen mit einem Passwort an: admin@libredb.org / Admin!2026 für den Administrator oder user@libredb.org / User!2026 für das Konto mit den geringeren Rechten, und das ist der schnellste Weg zu sehen, worin sich die beiden Rollen tatsächlich unterscheiden. Sie steht heute auf 0.15.0, älter als diese Seiten, nimm kleine Unterschiede also als Alter und nicht als Fehler. Beide öffnen mit den zwei Beispieldatenbanken, die im Image stecken.

Dua instance sudah berjalan dan terbuka untuk umum. app.libredb.org menjalankan 0.17.0, rilis yang dijelaskan di sini, dan tersambung ke single sign-on, jadi itu juga wujud nyata layar OIDC dari langkah 01. trial.libredb.org memasukkan Anda dengan password: admin@libredb.org / Admin!2026 untuk administrator, atau user@libredb.org / User!2026 untuk akun berhak-rendah, dan itu cara tercepat untuk melihat di mana sebenarnya kedua role itu berbeda. Hari ini ia di 0.15.0, lebih tua daripada halaman-halaman ini, jadi anggap perbedaan kecil sebagai soal usia, bukan kesalahan. Keduanya terbuka dengan dua database contoh yang ikut di dalam image.

Duas instâncias já estão no ar e abertas ao público. app.libredb.org roda a 0.17.0, a release descrita aqui, e está ligada a single sign-on, então é também como a tela de OIDC do passo 01 aparece no mundo real. trial.libredb.org te autentica com senha: admin@libredb.org / Admin!2026 para o administrador, ou user@libredb.org / User!2026 para a conta de menor privilégio, que é o jeito mais rápido de ver no que os dois papéis realmente diferem. Hoje ela está na 0.15.0, mais antiga que estas páginas, então trate diferenças pequenas como idade e não como erro. As duas abrem com os dois bancos de exemplo que vêm dentro da imagem.

One command, nothing installed

Un comando, nada instalado

コマンド一つ、インストールなし

Одна команда, ничего не установлено

ایک کمانڈ، کچھ نصب نہیں

一条命令，什么都不装

一條命令，什麼都不裝

Jedno polecenie, nic nie instalujesz

Une commande, rien d'installé

Un comando, niente installato

Ein Befehl, nichts installiert

Satu perintah, tanpa memasang apa pun

Um comando, nada instalado

npx @libredb/studio --port 3888

If Node 24 or newer is on the machine, this is the shortest path there is. The launcher downloads the standalone archive for your platform from GitHub Releases, verifies it against the release's SHA256SUMS, and caches it under ~/.libredb-studio/0.17.0/. Later runs start straight from that cache. If the GitHub CLI is installed and signed in it also verifies the archive's signed build provenance; without it you get a warning, but an archive whose provenance is actively rejected stops the launcher.

Si hay Node 24 o más nuevo en la máquina, este es el camino más corto que existe. El lanzador descarga el archivo standalone de tu plataforma desde GitHub Releases, lo verifica contra el SHA256SUMS de la release, y lo cachea en ~/.libredb-studio/0.17.0/. Las ejecuciones posteriores arrancan directamente de esa caché. Si tienes el CLI de GitHub instalado y con sesión iniciada, también verifica la procedencia firmada del archivo; sin él recibes un aviso, pero un archivo cuya procedencia se rechaza activamente detiene el lanzador.

Node 24 以降が入っていれば、これが最短の道です。ランチャーは自分のプラットフォーム向けの standalone アーカイブを GitHub Releases から取得し、リリースの SHA256SUMS と照合して検証し、~/.libredb-studio/0.17.0/ にキャッシュします。次回以降はそのキャッシュから直接起動します。GitHub CLI が入っていてログイン済みなら、署名されたビルド由来も検証します。無い場合は警告が出るだけですが、由来がはっきり拒否されたアーカイブはランチャーを止めます。

Если на машине Node 24 или новее, это самый короткий путь. Лаунчер скачивает standalone-архив для вашей платформы из GitHub Releases, сверяет его с SHA256SUMS этого релиза и кладёт в кеш ~/.libredb-studio/0.17.0/. Последующие запуски идут прямо из кеша. Если установлен и авторизован GitHub CLI, он также проверяет подписанное происхождение сборки; без него вы получите предупреждение, но архив, чьё происхождение отвергнуто, лаунчер не запустит.

اگر مشین پر Node 24 یا نیا موجود ہے تو یہ سب سے مختصر راستہ ہے۔ لانچر آپ کے پلیٹ فارم کا standalone آرکائیو GitHub Releases سے اتارتا ہے، ریلیز کے SHA256SUMS سے اس کی تصدیق کرتا ہے، اور ~/.libredb-studio/0.17.0/ میں محفوظ کر لیتا ہے۔ بعد کی بار سیدھا اسی ذخیرے سے چلتا ہے۔ اگر GitHub CLI نصب اور سائن اِن ہو تو آرکائیو کی دستخط شدہ اصل کی بھی تصدیق ہوتی ہے؛ نہ ہو تو صرف ایک تنبیہ ملتی ہے، مگر جس آرکائیو کی اصل واضح طور پر رد ہو جائے، لانچر رک جاتا ہے۔

如果机器上有 Node 24 或更新版本，这就是最短的路。启动器会从 GitHub Releases 下载对应平台的 standalone 归档，用这次发布的 SHA256SUMS 做校验，然后缓存到 ~/.libredb-studio/0.17.0/。之后每次运行都直接从这份缓存启动。如果装了 GitHub CLI 并且已登录，它还会验证归档带签名的构建来源；没有就只是给个警告，但来源被明确拒绝的归档会让启动器停下来。

如果機器上有 Node 24 或更新版本，這就是最短的路。啟動器會從 GitHub Releases 下載對應平台的 standalone 封存，用這次發布的 SHA256SUMS 做校驗，然後快取到 ~/.libredb-studio/0.17.0/。之後每次執行都直接從這份快取啟動。如果裝了 GitHub CLI 並且已登入，它還會驗證封存帶簽章的建置來源；沒有就只是給個警告，但來源被明確拒絕的封存會讓啟動器停下來。

Jeśli na maszynie jest Node 24 albo nowszy, to najkrótsza droga, jaka istnieje. Launcher pobiera z GitHub Releases samodzielne archiwum dla twojej platformy, weryfikuje je względem SHA256SUMS z wydania i trzyma je w cache'u pod ~/.libredb-studio/0.17.0/. Kolejne uruchomienia startują prosto z tego cache'u. Jeśli masz zainstalowane i zalogowane GitHub CLI, weryfikuje też podpisane pochodzenie builda archiwum; bez niego dostajesz ostrzeżenie, ale archiwum, którego pochodzenie zostanie aktywnie odrzucone, zatrzymuje launcher.

Si Node 24 ou plus récent est sur la machine, c'est le chemin le plus court qui existe. Le lanceur télécharge l'archive standalone pour votre plateforme depuis GitHub Releases, la vérifie contre le SHA256SUMS de la release, et la met en cache sous ~/.libredb-studio/0.17.0/. Les lancements suivants démarrent directement depuis ce cache. Si la CLI GitHub est installée et connectée, il vérifie aussi la provenance de build signée de l'archive ; sans elle vous obtenez un avertissement, mais une archive dont la provenance est activement rejetée arrête le lanceur.

Se sulla macchina c'è Node 24 o più recente, questa è la strada più breve che esista. Il launcher scarica l'archivio standalone per la tua piattaforma da GitHub Releases, lo verifica contro il SHA256SUMS della release, e lo tiene in cache sotto ~/.libredb-studio/0.17.0/. Le esecuzioni successive partono direttamente da quella cache. Se la CLI di GitHub è installata e autenticata, verifica anche la provenance firmata della build dell'archivio; senza di essa ricevi un avviso, ma un archivio la cui provenance viene attivamente rifiutata ferma il launcher.

Wenn Node 24 oder neuer auf dem Rechner ist, ist das der kürzeste Weg, den es gibt. Der Launcher lädt das Standalone-Archiv für deine Plattform aus den GitHub Releases, prüft es gegen die SHA256SUMS des Releases und legt es unter ~/.libredb-studio/0.17.0/ im Cache ab. Spätere Läufe starten direkt aus diesem Cache. Ist die GitHub CLI installiert und angemeldet, prüft er zusätzlich die signierte Build-Provenance des Archivs; ohne sie bekommst du eine Warnung, aber ein Archiv, dessen Provenance aktiv abgelehnt wird, stoppt den Launcher.

Kalau Node 24 atau lebih baru ada di mesin itu, ini jalur terpendek yang ada. Launcher mengunduh arsip standalone untuk platform Anda dari GitHub Releases, memverifikasinya terhadap SHA256SUMS milik rilis itu, dan menyimpannya di cache di bawah ~/.libredb-studio/0.17.0/. Run berikutnya start langsung dari cache itu. Kalau GitHub CLI terpasang dan sudah masuk, ia juga memverifikasi build provenance bertanda tangan milik arsip itu; tanpa itu Anda mendapat peringatan, tetapi arsip yang provenance-nya secara aktif ditolak akan menghentikan launcher.

Se houver Node 24 ou mais novo na máquina, este é o caminho mais curto que existe. O launcher baixa o arquivo standalone da sua plataforma pelo GitHub Releases, confere contra o SHA256SUMS da release, e guarda em cache em ~/.libredb-studio/0.17.0/. As execuções seguintes começam direto desse cache. Se o GitHub CLI estiver instalado e autenticado, ele também verifica a proveniência de build assinada do arquivo; sem isso você recebe um aviso, mas um arquivo cuja proveniência é ativamente rejeitada para o launcher.

What you should see

Qué deberías ver

見えるはずのもの

Что вы должны увидеть

آپ کو کیا نظر آنا چاہیے

你应该看到什么

你應該看到什麼

Co powinieneś zobaczyć

Ce que vous devriez voir

Cosa dovresti vedere

Was du sehen solltest

Yang seharusnya Anda lihat

O que você deve ver

Downloading https://github.com/libredb/libredb-studio/releases/download/0.17.0/libredb-studio-standalone-0.17.0-darwin-arm64.tar.gz
Downloading .../SHA256SUMS
Checksum verified
Provenance verified for libredb-studio-standalone-0.17.0-darwin-arm64.tar.gz
Unpacking into ~/.libredb-studio/0.17.0/payload
Starting LibreDB Studio 0.17.0 on http://127.0.0.1:3888

The first run spends a minute downloading, then prints the address and seeds the two sample databases. It binds to 127.0.0.1, so it is yours alone until you set HOSTNAME=0.0.0.0. Open it, sign in, and the dashboard shows two healthy connections you did not have to configure. If you did not set ADMIN_PASSWORD the launcher generates one and prints it, exactly as the container does.

La primera ejecución pasa un minuto descargando, luego imprime la dirección y siembra las dos bases de datos de ejemplo. Se enlaza a 127.0.0.1, así que es solo tuya hasta que pongas HOSTNAME=0.0.0.0. Ábrela, entra, y el panel muestra dos conexiones sanas que no tuviste que configurar. Si no pusiste ADMIN_PASSWORD, el lanzador genera una y la imprime, igual que hace el contenedor.

最初の実行はダウンロードに一分ほどかけ、そのあとアドレスを表示してサンプルのデータベースを二つ用意します。待ち受けは 127.0.0.1 なので、HOSTNAME=0.0.0.0 を指定するまでは自分だけのものです。開いてサインインすると、設定しなくても健全な接続が二つダッシュボードに並びます。ADMIN_PASSWORD を設定していなければ、ランチャーが生成して表示します。コンテナと同じです。

Первый запуск минуту качает, потом печатает адрес и создаёт две демонстрационные базы. Слушает он 127.0.0.1, так что до тех пор, пока вы не зададите HOSTNAME=0.0.0.0, он только ваш. Откройте, войдите, и на панели будут два исправных подключения, которые вам не пришлось настраивать. Если ADMIN_PASSWORD вы не задали, лаунчер сгенерирует пароль и напечатает его, ровно как контейнер.

پہلی بار چلنے میں ایک منٹ ڈاؤن لوڈ میں جاتا ہے، پھر یہ پتہ چھاپتا ہے اور دو نمونہ ڈیٹابیس بنا دیتا ہے۔ یہ 127.0.0.1 پر سنتا ہے، سو جب تک آپ HOSTNAME=0.0.0.0 مقرر نہ کریں، یہ صرف آپ کا ہے۔ کھولیں، داخل ہوں، اور ڈیش بورڈ پر دو صحت مند کنکشن نظر آئیں گے جو آپ کو ترتیب نہیں دینے پڑے۔ اگر ADMIN_PASSWORD مقرر نہیں کیا تھا تو لانچر خود ایک بنا کر چھاپ دیتا ہے، بالکل کنٹینر کی طرح۔

第一次运行会花一分钟下载，然后打印地址并建好两个示例数据库。它绑定在 127.0.0.1 上，所以在你设 HOSTNAME=0.0.0.0 之前，它只属于你。打开、登录，仪表盘上就有两条你没配置过的健康连接。如果你没设 ADMIN_PASSWORD，启动器会生成一个并打印出来，和容器一样。

第一次執行會花一分鐘下載，然後印出位址並建好兩個範例資料庫。它綁定在 127.0.0.1 上，所以在你設 HOSTNAME=0.0.0.0 之前，它只屬於你。打開、登入，儀表板上就有兩條你沒設定過的健康連線。如果你沒設 ADMIN_PASSWORD，啟動器會產生一個並印出來，和容器一樣。

Pierwsze uruchomienie schodzi na minutę pobierania, potem wypisuje adres i zasiewa dwie przykładowe bazy danych. Nasłuchuje na 127.0.0.1, więc jest tylko twoje, dopóki nie ustawisz HOSTNAME=0.0.0.0. Otwórz je, zaloguj się, a panel pokaże dwa zdrowe połączenia, których nie musiałeś konfigurować. Jeśli nie ustawiłeś ADMIN_PASSWORD, launcher generuje je i wypisuje, dokładnie tak jak kontener.

Le premier lancement passe une minute à télécharger, puis affiche l'adresse et installe les deux bases de données d'exemple. Il écoute sur 127.0.0.1, il est donc à vous seul jusqu'à ce que vous définissiez HOSTNAME=0.0.0.0. Ouvrez-le, connectez-vous, et le tableau de bord montre deux connexions en bonne santé que vous n'avez pas eu à configurer. Si vous n'avez pas défini ADMIN_PASSWORD, le lanceur en génère un et l'affiche, exactement comme le fait le container.

La prima esecuzione passa un minuto a scaricare, poi stampa l'indirizzo e crea i due database di esempio. Si lega a 127.0.0.1, quindi è solo tuo finché non imposti HOSTNAME=0.0.0.0. Aprilo, accedi, e la dashboard mostra due connessioni sane che non hai dovuto configurare. Se non hai impostato ADMIN_PASSWORD il launcher ne genera una e la stampa, esattamente come fa il container.

Der erste Lauf verbringt eine Minute mit Herunterladen, gibt dann die Adresse aus und legt die zwei Beispieldatenbanken an. Er bindet auf 127.0.0.1, gehört also dir allein, bis du HOSTNAME=0.0.0.0 setzt. Öffne ihn, melde dich an, und das Dashboard zeigt zwei gesunde Verbindungen, die du nicht einrichten musstest. Hast du ADMIN_PASSWORD nicht gesetzt, erzeugt der Launcher eines und gibt es aus, genau wie der Container.

Run pertama menghabiskan waktu satu menit untuk mengunduh, lalu mencetak alamatnya dan menanam dua database contoh. Ia mengikat ke 127.0.0.1, jadi ia milik Anda sendiri sampai Anda men-set HOSTNAME=0.0.0.0. Buka, masuk, dan dashboard menampilkan dua koneksi sehat yang tidak perlu Anda konfigurasi. Kalau Anda tidak men-set ADMIN_PASSWORD, launcher membuatkan satu dan mencetaknya, persis seperti yang dilakukan container.

A primeira execução gasta um minuto baixando, depois imprime o endereço e semeia os dois bancos de exemplo. Ela escuta em 127.0.0.1, então é só sua até você definir HOSTNAME=0.0.0.0. Abra, entre, e o dashboard mostra duas conexões saudáveis que você não teve que configurar. Se você não definiu ADMIN_PASSWORD, o launcher gera uma e imprime, exatamente como o container faz.

A package manager instead

Un gestor de paquetes en su lugar

パッケージマネージャーで入れる

Через пакетный менеджер

اس کے بجائے پیکیج مینیجر

改用包管理器

改用套件管理器

Albo menedżer pakietów

Un gestionnaire de paquets à la place

Oppure un gestore di pacchetti

Lieber ein Paketmanager

Atau lewat package manager

Um gerenciador de pacotes no lugar

# macOS and Linux
brew install libredb/tap/libredb-studio

# Windows
winget install LibreDB.Studio
choco install libredb-studio

# Linux
sudo snap install libredb-studio

The channel you pick decides the version you get: npm, the Homebrew tap and the Snap Store's stable channel carry 0.17.0, while winget is on 0.16.0 and Chocolatey on 0.15.0. macOS and Linux have the Homebrew tap; Windows has winget and Chocolatey; Linux also has the Snap Store, the signed FlatPark remote, and .deb and .rpm packages attached to the release. Everything on the release can be checked. Eleven assets carry their own .sha256 beside them (the .deb and .rpm packages, the AppImages, both snaps and the CycloneDX bill of materials) and a SHA256SUMS file covers the five standalone archives, which are the only ones without a checksum of their own.

El canal que elijas decide la versión que recibes: npm, el tap de Homebrew y el canal stable de la Snap Store llevan 0.17.0, mientras que winget va por 0.16.0 y Chocolatey por 0.15.0. macOS y Linux tienen el tap de Homebrew; Windows tiene winget y Chocolatey; Linux tiene además la Snap Store, el remoto firmado de FlatPark, y paquetes .deb y .rpm adjuntos a la release. Todo lo que hay en la release se puede verificar. Once artefactos llevan su propio .sha256 al lado (los paquetes .deb y .rpm, las AppImage, los dos snaps y el inventario CycloneDX) y un fichero SHA256SUMS cubre los cinco archivos standalone, que son los únicos sin una suma propia.

選んだ経路が、手に入るバージョンを決めます。npm、Homebrew の tap、Snap Store の stable チャンネルは 0.17.0 を運び、winget は 0.16.0、Chocolatey は 0.15.0 です。macOS と Linux には Homebrew の tap、Windows には winget と Chocolatey、Linux にはさらに Snap Store、署名された FlatPark リモート、そしてリリースに添付された .deb と .rpm のパッケージがあります。リリースに載っているものは、すべて確かめられます。11 個の成果物が自分の .sha256 を隣に持っています。.deb と .rpm のパッケージ、AppImage、二つの snap、そして CycloneDX の部品表です。SHA256SUMS ファイルは standalone のアーカイブ五つを網羅し、自分のチェックサムを持たないのはその五つだけです。

Выбранный канал определяет версию, которую вы получите: npm, tap в Homebrew и канал stable в Snap Store несут 0.17.0, winget несёт 0.16.0, а Chocolatey несёт 0.15.0. Для macOS и Linux есть tap в Homebrew, для Windows есть winget и Chocolatey, у Linux дополнительно Snap Store, подписанный репозиторий FlatPark и пакеты .deb и .rpm, приложенные к релизу. Проверить можно всё, что выложено в релизе. У одиннадцати файлов рядом лежит свой .sha256: у пакетов .deb и .rpm, у образов AppImage, у обоих snap-пакетов и у перечня компонентов CycloneDX. Файл SHA256SUMS покрывает пять standalone-архивов, только у них своей суммы нет.

آپ جو راستہ چنتے ہیں وہی طے کرتا ہے کہ کون سا ورژن ملے گا: npm، Homebrew کا tap اور Snap Store کا stable چینل 0.17.0 لاتے ہیں، جبکہ winget 0.16.0 پر ہے اور Chocolatey 0.15.0 پر۔ macOS اور Linux کے لیے Homebrew کا tap ہے؛ Windows کے لیے winget اور Chocolatey؛ Linux کے لیے مزید Snap Store، دستخط شدہ FlatPark ریموٹ، اور ریلیز کے ساتھ لگے .deb اور .rpm پیکیج۔ ریلیز پر جو کچھ ہے، سب جانچا جا سکتا ہے۔ گیارہ فائلوں کے پہلو میں اپنی .sha256 موجود ہے: .deb اور .rpm پیکیج، AppImage، دونوں snap اور CycloneDX کی فہرستِ اجزا۔ SHA256SUMS فائل پانچ standalone آرکائیوز کا احاطہ کرتی ہے، اور اپنی چیک سم نہ رکھنے والے صرف یہی پانچ ہیں۔

你挑哪条渠道，就决定了拿到哪个版本：npm、Homebrew tap 和 Snap Store 的 stable 通道带的是 0.17.0，而 winget 在 0.16.0，Chocolatey 在 0.15.0。macOS 和 Linux 有 Homebrew tap；Windows 有 winget 和 Chocolatey；Linux 还有 Snap Store、带签名的 FlatPark 远程仓库，以及随发布附上的 .deb 和 .rpm 包。发布上的每样东西都能校验。11 个文件各自在旁边带着自己的 .sha256：.deb 和 .rpm 包、AppImage、两个 snap，以及 CycloneDX 物料清单。SHA256SUMS 文件覆盖那五个 standalone 归档，没有自己校验和的也就只有这五个。

你挑哪條通道，就決定了拿到哪個版本：npm、Homebrew tap 和 Snap Store 的 stable 通道帶的是 0.17.0，而 winget 在 0.16.0，Chocolatey 在 0.15.0。macOS 和 Linux 有 Homebrew tap；Windows 有 winget 和 Chocolatey；Linux 還有 Snap Store、帶簽章的 FlatPark 遠端儲存庫，以及隨發布附上的 .deb 和 .rpm 套件。發布上的每樣東西都能校驗。11 個檔案各自在旁邊帶著自己的 .sha256：.deb 和 .rpm 套件、AppImage、兩個 snap，以及 CycloneDX 物料清單。SHA256SUMS 檔案涵蓋那五個 standalone 封存，沒有自己校驗和的也就只有這五個。

Kanał, który wybierzesz, decyduje o wersji, jaką dostaniesz: npm, tap Homebrew i stabilny kanał Snap Store niosą 0.17.0, winget jest na 0.16.0, a Chocolatey na 0.15.0. macOS i Linux mają tap Homebrew; Windows ma winget i Chocolatey; Linux ma dodatkowo Snap Store, podpisane zdalne repozytorium FlatPark oraz pakiety .deb i .rpm dołączone do wydania. Wszystko, co wisi przy wydaniu, da się sprawdzić. Własny .sha256 leży obok jedenastu plików: pakietów .deb i .rpm, obrazów AppImage, obu snapów i zestawienia komponentów CycloneDX. Plik SHA256SUMS obejmuje pięć samodzielnych archiwów i tylko one nie mają własnej sumy kontrolnej.

Le canal que vous choisissez décide de la version que vous obtenez : npm, le tap Homebrew et le canal stable du Snap Store portent la 0.17.0, tandis que winget est en 0.16.0 et Chocolatey en 0.15.0. macOS et Linux ont le tap Homebrew ; Windows a winget et Chocolatey ; Linux a aussi le Snap Store, le dépôt signé FlatPark, et des paquets .deb et .rpm attachés à la release. Tout ce qui se trouve sur la release peut être vérifié. Onze fichiers portent leur propre .sha256 à côté d'eux : les paquets .deb et .rpm, les AppImage, les deux snaps et la nomenclature CycloneDX ; et un fichier SHA256SUMS couvre les cinq archives standalone, les seules à ne pas avoir de somme à elles.

Il canale che scegli decide la versione che ti arriva: npm, il tap Homebrew e il canale stable dello Snap Store portano la 0.17.0, mentre winget è sulla 0.16.0 e Chocolatey sulla 0.15.0. macOS e Linux hanno il tap Homebrew; Windows ha winget e Chocolatey; Linux ha anche lo Snap Store, il remote firmato FlatPark, e i pacchetti .deb e .rpm allegati alla release. Tutto quello che sta nella release si può verificare. Undici artefatti portano accanto il proprio .sha256 (i pacchetti .deb e .rpm, le AppImage, entrambi gli snap e la distinta base CycloneDX) e un file SHA256SUMS copre i cinque archivi standalone, che sono gli unici senza un checksum proprio.

Der Kanal, den du wählst, entscheidet über die Version, die du bekommst: npm, der Homebrew-Tap und der Stable-Kanal im Snap Store führen 0.17.0, winget steht auf 0.16.0 und Chocolatey auf 0.15.0. macOS und Linux haben den Homebrew-Tap; Windows hat winget und Chocolatey; Linux hat außerdem den Snap Store, das signierte FlatPark-Remote und .deb- und .rpm-Pakete am Release. Alles am Release lässt sich prüfen. Elf Artefakte tragen ihre eigene .sha256 daneben: die .deb- und .rpm-Pakete, die AppImages, beide Snaps und die CycloneDX-Stückliste, und eine Datei SHA256SUMS deckt die fünf Standalone-Archive ab, die als Einzige keine eigene Prüfsumme haben.

Kanal yang Anda pilih menentukan versi yang Anda dapat: npm, tap Homebrew dan kanal stable di Snap Store membawa 0.17.0, sementara winget ada di 0.16.0 dan Chocolatey di 0.15.0. macOS dan Linux punya tap Homebrew; Windows punya winget dan Chocolatey; Linux juga punya Snap Store, remote FlatPark bertanda tangan, serta paket .deb dan .rpm yang dilampirkan ke rilis. Semua yang ada di rilis itu bisa diperiksa. Sebelas artefak membawa .sha256 sendiri di sebelahnya (paket .deb dan .rpm, AppImage, kedua snap dan bill of materials CycloneDX), dan satu file SHA256SUMS mencakup lima arsip standalone, satu-satunya yang tidak punya checksum sendiri.

O canal que você escolher decide a versão que você recebe: npm, o tap do Homebrew e o canal stable da Snap Store carregam a 0.17.0, enquanto o winget está na 0.16.0 e o Chocolatey na 0.15.0. macOS e Linux têm o tap do Homebrew; Windows tem winget e Chocolatey; Linux tem ainda a Snap Store, o remote assinado do FlatPark, e pacotes .deb e .rpm anexados à release. Tudo que está na release dá para conferir. Onze artefatos carregam o próprio .sha256 ao lado: os pacotes .deb e .rpm, as AppImages, os dois snaps e o bill of materials em CycloneDX; e um arquivo SHA256SUMS cobre os cinco arquivos standalone, que são os únicos sem checksum próprio.

The desktop application

La aplicación de escritorio

デスクトップアプリ

Настольное приложение

ڈیسک ٹاپ ایپلی کیشن

桌面应用

桌面應用

Aplikacja desktopowa

L'application de bureau

L'applicazione desktop

Die Desktop-Anwendung

Aplikasi desktop

A aplicação desktop

There is a packaged desktop build as well, shipped as an AppImage and a GUI .deb for x64 and arm64. Read the platform list before you plan around it: the desktop build is Linux only today. On macOS and Windows the package channels above install the server and you reach it in a browser, which is what the Runs on Linux · macOS · Windows line on the sign-in screen is actually telling you.

También hay una versión de escritorio empaquetada, distribuida como AppImage y como .deb con interfaz gráfica para x64 y arm64. Lee la lista de plataformas antes de contar con ella: hoy la versión de escritorio es solo para Linux. En macOS y Windows los canales de paquetes de arriba instalan el servidor y llegas a él desde un navegador, que es lo que en realidad te está diciendo la línea Runs on Linux · macOS · Windows de la pantalla de inicio de sesión.

パッケージ化されたデスクトップ版もあり、x64 と arm64 向けに AppImage と GUI 付き .deb として配布されています。これを前提に計画を立てる前に対応プラットフォームを確認してください。現時点でデスクトップ版は Linux のみです。macOS と Windows では、上のパッケージ経路がサーバーを入れ、ブラウザーから使う形になります。サインイン画面の Runs on Linux · macOS · Windows という行が実際に伝えているのはこのことです。

Есть и упакованная настольная сборка: как AppImage и как GUI-.deb для x64 и arm64. Прежде чем строить на ней планы, прочтите список платформ: сегодня настольная сборка существует только под Linux. На macOS и Windows пакетные каналы выше ставят сервер, и вы открываете его в браузере, именно это на самом деле и сообщает строка Runs on Linux · macOS · Windows на экране входа.

ایک پیک شدہ ڈیسک ٹاپ بلڈ بھی ہے، جو x64 اور arm64 کے لیے AppImage اور GUI والے .deb کی صورت آتا ہے۔ اس کے بھروسے منصوبہ بنانے سے پہلے پلیٹ فارم کی فہرست پڑھ لیں: آج ڈیسک ٹاپ بلڈ صرف Linux کے لیے ہے۔ macOS اور Windows پر اوپر والے پیکیج راستے سرور نصب کرتے ہیں اور آپ اس تک براؤزر سے پہنچتے ہیں، اور سائن اِن اسکرین کی Runs on Linux · macOS · Windows والی سطر دراصل یہی بتا رہی ہے۔

还有一个打包好的桌面版，以 AppImage 和带图形界面的 .deb 形式提供 x64 与 arm64。在照着它做计划之前，先看一眼平台列表：今天的桌面版只有 Linux。在 macOS 和 Windows 上，上面那些包管理渠道装的是服务端，你通过浏览器访问它。登录界面上 Runs on Linux · macOS · Windows 那行话，真正的意思就是这个。

還有一個打包好的桌面版，以 AppImage 和帶圖形介面的 .deb 形式提供 x64 與 arm64。在照著它做計畫之前，先看一眼平台列表：今天的桌面版只有 Linux。在 macOS 和 Windows 上，上面那些套件管理通道裝的是伺服器端，你透過瀏覽器存取它。登入介面上 Runs on Linux · macOS · Windows 那行話，真正的意思就是這個。

Jest też pakowany build desktopowy, wydawany jako AppImage i graficzny .deb dla x64 i arm64. Przeczytaj listę platform, zanim coś na nim oprzesz: build desktopowy jest dziś tylko dla Linuksa. Na macOS i Windows kanały pakietowe wymienione wyżej instalują serwer, a ty sięgasz do niego przeglądarką, i to właśnie mówi ci linia Runs on Linux · macOS · Windows na ekranie logowania.

Il y a aussi un build de bureau empaqueté, livré sous forme d'AppImage et de .deb graphique pour x64 et arm64. Lisez la liste des plateformes avant de bâtir dessus : le build de bureau est uniquement Linux aujourd'hui. Sur macOS et Windows, les canaux de paquets ci-dessus installent le serveur et vous l'atteignez dans un navigateur, ce qui est ce que la ligne Runs on Linux · macOS · Windows de l'écran de connexion vous dit en réalité.

C'è anche una build desktop impacchettata, distribuita come AppImage e come .deb con interfaccia grafica per x64 e arm64. Leggi l'elenco delle piattaforme prima di farci dei piani sopra: oggi la build desktop è solo Linux. Su macOS e Windows i canali di pacchetti qui sopra installano il server e lo raggiungi in un browser, che è quello che la riga Runs on Linux · macOS · Windows nella schermata di accesso ti sta dicendo davvero.

Es gibt auch einen gepackten Desktop-Build, ausgeliefert als AppImage und als GUI-.deb für x64 und arm64. Lies die Plattformliste, bevor du darum herum planst: der Desktop-Build ist heute nur für Linux. Auf macOS und Windows installieren die Paketkanäle oben den Server, und du erreichst ihn im Browser. Genau das sagt dir die Zeile Runs on Linux · macOS · Windows auf dem Anmeldebildschirm in Wahrheit.

Ada juga build desktop yang dipaket, dikirim sebagai AppImage dan .deb GUI untuk x64 dan arm64. Baca daftar platformnya sebelum Anda menyusun rencana di sekitarnya: build desktop hari ini hanya Linux. Di macOS dan Windows, kanal paket di atas memasang server dan Anda menjangkaunya lewat browser, dan itulah yang sebenarnya dikatakan baris Runs on Linux · macOS · Windows di layar masuk.

Existe também um build desktop empacotado, entregue como AppImage e como um .deb com interface gráfica para x64 e arm64. Leia a lista de plataformas antes de planejar em cima dele: hoje o build desktop é só para Linux. No macOS e no Windows os canais de pacote acima instalam o servidor e você acessa pelo navegador, que é o que a linha Runs on Linux · macOS · Windows da tela de login está de fato dizendo.