Cara Self-host Open Connector untuk Ejen AI

Fungsi Open Connector untuk ejen AI

Self-hosting Open Connector meletakkan satu gerbang pengesahan antara ejen AI anda dengan setiap API software as a service (SaaS) yang dipanggil, supaya ejen tersebut tidak perlu menyimpan token pembekal. Ia merupakan gerbang sumber terbuka daripada OOMOL Lab, dilesenkan di bawah Apache 2.0. Ia berjalan sebagai satu kontena, menyimpan statusnya dalam satu fail SQLite, dan mendedahkan tindakan pembekal melalui HTTP serta MCP (model context protocol).

Masalah bermula pada integrasi kedua. Setiap pembekal mempunyai aliran OAuth (open authorization) sendiri, jangka hayat refresh token sendiri, dan nama skop sendiri. Menyambungkan lima pembekal ke dalam ejen secara manual bermakna anda perlu mengurus lima pengendali redirect, lima stor kelayakan, dan lima gelung refresh yang perlu berjalan sebelum token tamat tempoh. Hampir tiada sesiapa yang menulis kod tersebut. Mereka biasanya menjana satu personal access token jangka hayat panjang bagi setiap servis dan menampalnya ke dalam konfigurasi ejen, fail persekitaran, atau prompt itu sendiri. Token tersebut kemudiannya boleh dibaca oleh setiap alat yang dijalankan oleh ejen, dan ia akan tersimpan dalam transkrip, yang merupakan kegagalan yang diterangkan dalam menjaga rahsia daripada ejen AI.

Gerbang pengesahan memisahkan kelayakan kepada dua bahagian. Gerbang menyimpan kelayakan pembekal dan menjalankan aliran OAuth. Ejen menerima token masa jalan (runtime token) yang hanya sah untuk gerbang tersebut. Apabila ejen memanggil sesuatu tindakan, gerbang akan memuatkan kelayakan yang disimpan, menyuntiknya ke dalam permintaan keluar di bahagian pelayan, dan hanya mengembalikan badan respons. Ejen tidak pernah menerima token akses pembekal, jadi jika transkrip ejen bocor, ia hanya menjejaskan satu token masa jalan yang boleh dibatalkan, bukannya akaun GitHub anda.

Katalog tersebut mengiklankan lebih daripada 1,000 pembekal dan 10,000 tindakan pra-bina, yang merupakan angka daripada projek itu sendiri dan bukan sesuatu yang boleh anda sahkan dari luar. Apa yang boleh anda sahkan ialah bentuknya: satu endpoint HTTP bagi setiap tindakan, satu sambungan tersimpan bagi setiap pembekal, dan satu token bagi setiap ejen.

Mengapa perlu self-host Open Connector berbanding menggunakan perkhidmatan penyambung (connector) terhos

Perkhidmatan penyambung terhos melakukan kerja yang sama, dan ia menyimpan refresh token bagi setiap penyedia yang anda sambungkan kepadanya. Refresh token untuk Google atau GitHub merupakan kunci jangka hayat panjang bagi e-mel dan repositori anda, dan ia biasanya kekal aktif walaupun selepas anda menukar kata laluan. Kebocoran data mereka akan menjadi kebocoran data anda. Self-hosting memindahkan rekod tersebut ke dalam SQLite pada mesin yang anda sewa dan tadbir, yang dimeterai dengan kunci yang tidak pernah keluar dari pelayan anda.

Sebutkan kosnya dengan jelas sebelum anda bermula. VPS ini akan menjadi pelayan paling berharga yang anda kendalikan. Ia menyimpan kelayakan kerja untuk sedozen perkhidmatan dalam satu fail, jadi ia wajar menerima layanan yang sama seperti hos pengurus kata laluan: firewall yang hanya mendedahkan port 443, tiada log masuk dikongsi, sandaran yang pernah anda uji pulih sekurang-kurangnya sekali, dan sistem amaran apabila ia berhenti memberi respons. Jika anda tidak akan meletakkan peti simpanan kata laluan anda pada mesin ini, jangan letakkan penyambung tersebut di situ juga.

Tetapkan versi sebelum anda memasang apa-apa

Open Connector masih baharu. Repositori ini mula muncul pada 29 Jun 2026, dan setakat 1 Ogos 2026, keluaran bertanda yang terbaharu ialah v1.3.3, yang diterbitkan pada 30 Julai 2026 dan turut membawa tag latest. Pendaftaran (registry) juga menerbitkan tag tip, yang dibina daripada komit terbaharu pada main.

Bagi projek yang baharu sebegini, tag yang berubah-ubah sering bergerak. docker compose pull yang melangkau dua keluaran boleh mengubah titik akhir (endpoint) yang bergantung pada ejen anda, dan anda akan menghabiskan waktu malam untuk menyahpepijatnya sebagai masalah ejen. Tetapkan imej kepada tag keluaran, dan naik taraf apabila anda membuat keputusan untuk berbuat demikian, selepas membaca nota keluaran.

Melancarkan Open Connector di sebalik TLS pada VPS anda sendiri

Sebelum kontena bermula, anda perlukan:

• Docker dengan pemalam Compose, pada Ubuntu 24.04 atau sistem yang hampir sama
• nama hos yang rekod A-nya menghala ke VPS ini, contohnya connect.example.com
• reverse proxy yang sudah menamatkan TLS (transport layer security) untuk nama hos tersebut
• dua rahsia rawak, dijana di bawah

Panduan Traefik reverse proxy untuk pelbagai aplikasi Docker Compose merangkumi bahagian proksi. Pemasangan sijil yang sama, dari mula hingga akhir untuk satu aplikasi, terdapat dalam panduan n8n pada VPS dengan Docker dan HTTPS.

Jana rahsia tersebut terlebih dahulu. Kunci penyulitan (encryption key) mengunci kelayakan yang disimpan. Token pentadbir (admin token) melindungi konsol web dan keseluruhan permukaan /api. Tiada satu pun yang mempunyai nilai lalai, dan runtime akan bermula tanpa masalah walaupun tanpanya.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Salin kedua-dua nilai ke dalam pengurus kata laluan anda sekarang, sebelum permulaan pertama. Kunci penyulitan tidak mempunyai laluan pemulihan, dan sebabnya ada dalam senarai kegagalan di bawah.

Sekarang compose.yaml. Ia berbeza daripada contoh upstream di dua tempat, dan kedua-duanya penting.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

Perubahan pertama ialah tag yang ditetapkan (pinned tag) dan bukannya latest. Perubahan kedua ialah port. Fail upstream menerbitkan 3000:3000, yang mengikat setiap antara muka pada hos. Docker menulis port yang diterbitkan ke dalam jadual NAT (network address translation) sebelum rantaian penapis ufw melihat paket tersebut, jadi ufw deny 3000 tidak menutup port itu, perangkap yang diterangkan dalam mengapa port Docker memintas ufw. Menulis 127.0.0.1:3000:3000 menerbitkan pada antara muka loopback sahaja, dan reverse proxy anda bersambung dari hos yang sama.

:? menandakan setiap pemboleh ubah sebagai wajib, jadi stack enggan bermula apabila .env tiada, bukannya bermula dengan kelayakan yang tidak disulitkan. Menyimpan nilai dalam .env dan bukannya dalam fail compose adalah corak daripada fail env Docker Compose dan rahsia.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health menjawab { "ok": true } sebaik sahaja runtime aktif. ss mesti mencetak 127.0.0.1:3000. Baris yang membaca 0.0.0.0:3000 bermakna pemetaan port masih lagi yang asal (upstream), dan gateway menjawab keseluruhan internet secara terus. Connection refused pada pemeriksaan kesihatan bermakna kontena belum lagi mendengar, jadi baca log sebelum anda menyentuh proksi.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

Mengapa OAuth mewajibkan anda mempunyai hostname sebenar

OOMOL_CONNECT_ORIGIN ialah tetapan yang sering dilangkau oleh pengguna, dan tindakan melangkaunya akan menyebabkan OAuth gagal dengan cara yang kelihatan seperti pepijat pada pihak pembekal. Runtime membina URI ubah hala (redirect URI) daripada origin tersebut, dalam bentuk <origin>/oauth/callback. Jika dibiarkan tanpa tetapan, origin akan ditetapkan secara lalai kepada http://localhost:3000, jadi runtime menghantar URI ubah hala http://localhost:3000/oauth/callback kepada pembekal, sedangkan aplikasi OAuth anda telah mendaftarkan https://connect.example.com/oauth/callback. Kedua-dua rentetan ini berbeza, maka GitHub memberikan respons berikut:

The redirect_uri MUST match the registered callback URL for this application.

Pembekal OAuth mengubah hala pelayar kembali ke URI tersebut, yang bermaksud ia mestilah alamat yang boleh dicapai oleh dunia luar, dan pembekal akan menolak http:// biasa untuk sebarang tujuan selain localhost. Itulah sebab utama mengapa deployment ini memerlukan hostname dan sijil. Tetapkan origin sebelum permulaan pertama, kerana nilai tersebut dibaca semasa startup: selepas menyunting .env atau compose.yaml, jalankan docker compose up -d sekali lagi untuk mengaplikasikannya.

Sambungkan pembekal pertama anda melalui OAuth

Cipta aplikasi OAuth di pihak pembekal terlebih dahulu. Di GitHub, laluannya ialah Settings, kemudian Developer settings, kemudian OAuth Apps, dan seterusnya New OAuth App. Tetapkan URL panggil balik kebenaran (authorization callback URL) kepada https://connect.example.com/oauth/callback. Simpan client ID dan client secret tersebut.

Setiap panggilan /api membawa token admin, jadi eksport token tersebut sekali sahaja untuk sesi shell berkenaan.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Penyenaraian tersebut menunjukkan URI ubah hala (redirect URI) yang dijangkakan oleh runtime untuk setiap pembekal, menjadikannya cara terpantas untuk menyemak sama ada asal (origin) anda telah berkuat kuasa. Jika ia masih memaparkan localhost, kontena tersebut sedang berjalan dengan nilai lama dan aliran OAuth akan gagal pada langkah terakhir.

Simpan kelayakan pelanggan (client credentials), kemudian mulakan kebenaran.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

Panggilan kedua mengembalikan authorizationUrl. Buka pautan tersebut dalam pelayar, luluskan skop (scopes), dan pembekal akan menghantar pelayar kembali ke /oauth/callback, di mana runtime menukarkan kod tersebut dan menyimpan kelayakan. Konsol web di asal anda melakukan langkah yang sama melalui borang, di sebalik token admin yang sama. Pembekal yang menggunakan kunci API biasa tidak perlu melalui semua ini: PUT /api/connections/<service> dengan {"authType":"api_key","values":{"apiKey":"..."}} menyimpan kunci tersebut secara terus.

Berikan setiap ejen token masa jalan, jangan sekali-kali memberikan kelayakan

Ejen mengesahkan diri kepada get laluan (gateway) menggunakan token masa jalan, yang dijana oleh API pentadbir.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Respons tersebut membawa token yang bermula dengan oct_. Keluarkan satu token bagi setiap ejen dan namakannya mengikut ejen tersebut, kerana membatalkan token yang tidak dapat dikenal pasti bermakna membatalkan kesemuanya. Ejen kemudian memanggil tindakan melalui HTTP biasa.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Jawapan yang sihat ialah sampul yang medan success-nya ialah true, dengan muatan pembekal di bawah data. Token GitHub tidak terdapat di mana-mana dalam respons tersebut. Bagi klien MCP, halakan ia ke https://connect.example.com/mcp dengan pengepala bearer yang sama, dan get laluan akan menawarkan alat penemuan seperti search_actions dan execute_action dan bukannya satu alat bagi setiap API, yang memastikan senarai alat ejen kekal kecil. Menjalankan pelayan MCP pada VPS merangkumi bahagian klien bagi pendawaian tersebut.

Jalankan satu lagi semakan sebelum anda menganggap ini selesai. Ulangi panggilan tindakan dengan pengepala authorization dipadamkan. Panduan permulaan pantas projek itu sendiri memanggil /v1 tanpa sebarang bearer, jadi pemasangan tanpa pengesahan masa jalan yang dikonfigurasikan akan melaksanakan tindakan bagi sesiapa sahaja yang boleh mencapai port tersebut. Jika panggilan tanpa pengesahan anda berjaya, anda mempunyai dua jalan keluar: konfigurasikan token masa jalan dan sahkan bahawa panggilan tanpa nama kini gagal, atau sekat /api, /v1 dan /mcp di reverse proxy kepada alamat asal ejen anda. Hanya /oauth/callback yang perlu kekal terbuka kepada dunia, kerana itu adalah satu-satunya laluan yang diperlukan oleh ubah hala pelayar pembekal.

Hadkan senarai tindakan kepada keperluan ejen

Gerbang yang mempunyai ribuan penyedia di belakangnya merupakan permukaan serangan yang luas untuk diberikan kepada model bahasa. Permukaan ini menjadi lebih luas apabila model tersebut mula membaca teks yang tidak ditulisnya sendiri, kerana halaman yang dikembalikan oleh instans SearXNG anda sendiri yang menjawab carian web ejen boleh membawa arahan yang disasarkan kepada mana-mana tindakan yang dimiliki oleh ejen tersebut. Kekangan yang sama yang menjadikan ejen pengekodan mengambil perubahan terkecil yang berkesan perlu digunakan pada kebenarannya: berikan hanya beberapa tindakan yang benar-benar diperlukan oleh tugasan tersebut, dan tiada yang lain. Dua kawalan mengehadkan perkara ini.

OOMOL_CONNECT_ALLOWED_ACTIONS mengambil senarai benarkan (allowlist) yang dipisahkan dengan koma dan memahami service.* serta *. OOMOL_CONNECT_BLOCKED_ACTIONS ialah senarai sekat (denylist), dan senarai sekat akan diutamakan. Menetapkan senarai benarkan kepada github.get_current_user,github.list_issues bermakna setiap tindakan lain akan ditolak tidak kira apa yang diminta oleh ejen, yang merupakan perbezaan antara kesilapan dan insiden. Token masa jalan (runtime tokens) membawa peraturan tindakan mereka sendiri di samping peraturan global, dan senarai allowedProxies mereka bermula dalam keadaan kosong, jadi POST /v1/proxy/:service akan ditolak sehingga anda memberikannya. Titik akhir proksi tersebut memajukan permintaan mentah kepada penyedia dengan kelayakan anda dilampirkan, jadi biarkan ia kosong kecuali satu ejen khusus memerlukannya.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK ditetapkan secara lalai kepada false, yang menghalang sambungan penyedia yang dihoskan sendiri daripada menghala ke alamat peribadi seperti perkhidmatan metadata awan pada 169.254.169.254, atau pangkalan data anda pada rangkaian yang sama. Biarkan ia dimatikan. Hidupkan hanya untuk penyedia yang anda hoskan sendiri.

Sandarkan pelayan yang menyimpan setiap token

Dua perkara adalah penting, dan setiap satunya tidak berguna tanpa yang lain. Pangkalan data pada /app/data/connect.sqlite di dalam volum connector-data menyimpan kelayakan yang dimeterai. Kunci penyulitan dalam .env pula menyahmeterai kelayakan tersebut. Sandaran volum tanpa kunci tidak akan memulihkan apa-apa, dan kunci tanpa volum juga tidak akan memulihkan apa-apa, jadi simpan kunci tersebut dalam pengurus kata laluan anda dan masukkan volum ke dalam kitaran sandaran biasa anda.

Hentikan kontena semasa anda menyalin fail SQLite, kerana salinan yang diambil semasa proses penulisan boleh menyebabkan pangkalan data yang dipulihkan menjadi rosak.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Nama volum adalah direktori projek anda ditambah dengan _connector-data, itulah sebabnya arahan pertama diletakkan di situ: tampal nama sebenar ke dalam arahan ketiga. Hantar arkib keluar dari VPS dengan sandaran restic daripada VPS, yang menyulitkan arkib tersebut sebelum ia dihantar keluar, kerana arkib itu merupakan stor kelayakan.

Runtime menyimpan rekod tindakan terkini sebagai rekod audit, secara lalai sebanyak 5,000 rekod, supaya konsol boleh memberitahu anda ejen mana yang menjalankan apa dan bila. Log tersebut adalah perkara pertama yang perlu dibaca apabila ejen berkelakuan pelik. Halakan halaman status Uptime Kuma ke https://connect.example.com/health juga. Apabila get laluan (gateway) berhenti memberi respons, ejen akan gagal dengan cara yang mengelirukan, dan mengetahui bahawa get laluan tidak berfungsi dapat menjimatkan masa selama satu jam daripada membaca output ejen.

Perkara yang rosak, dan mesej yang akan anda lihat

redirect_uri_mismatch di pihak pembekal. Origin dan URL panggil balik (callback URL) yang didaftarkan adalah berbeza. Bandingkan rentetan tepat daripada /api/oauth/configs dengan tetapan aplikasi pembekal, termasuk https berbanding http dan sebarang garis miring (trailing slash) di hujungnya.

Setiap panggilan /api mengembalikan 401. Pengepala (header) token admin tiada atau tersalah eja. Pengepalanya ialah Authorization: Bearer <token>, dan konsol web meminta token yang sama.

Kontena berjalan, dan kelayakan (credentials) disimpan dalam teks biasa. Ini berlaku apabila OOMOL_CONNECT_ENCRYPTION_KEY tidak pernah sampai ke kontena, kerana runtime menyimpan rekod kelayakan tanpa disulitkan dan bukannya enggan bermula. Buktikan pada pemasangan anda sendiri: sambungkan pembekal dengan kunci API yang anda kenali, kemudian cari kunci tersebut di dalam pangkalan data.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

Kiraan melebihi 0 bermakna kunci tidak berkuat kuasa, jadi pastikan .env berada dalam direktori yang sama dengan compose.yaml dan docker compose config memaparkan nilainya. Dengan kunci ditetapkan, carian yang sama akan mengembalikan 0, kerana rekod tersebut dimeterai dengan AES-256-GCM (standard penyulitan termaju, kunci 256-bit, mod Galois/counter).

Tiada apa-apa yang dapat dinyahsulit selepas pemulihan (restore). Kunci penyulitan telah berubah atau hilang. Mengikut reka bentuk, kunci tidak pernah ditulis bersebelahan dengan data, jadi tiada laluan pemulihan dan tiada tiket sokongan yang dapat membantu. Sambungkan semula setiap pembekal. Putaran kunci disokong melalui pemboleh ubah kunci yang berasingan dan arahan data dalam runtime, jadi baca nota keluaran semasa sebelum anda memutar apa-apa.

Ejen mendapat ralat yang menamakan tindakan yang boleh dilihat dalam katalog. Penemuan (discovery) dan pelaksanaan adalah berasingan. Sesuatu tindakan boleh muncul dalam search_actions namun masih ditolak oleh OOMOL_CONNECT_ALLOWED_ACTIONS, oleh senarai hitam (denylist), atau oleh peraturan token runtime itu sendiri.

Peningkatan (upgrades). Sandarkan volum, edit tag imej kepada keluaran baharu, kemudian docker compose pull && docker compose up -d. Perhatikan docker compose logs -n 50 connector untuk baris migrasi, dan jalankan semula pemeriksaan kesihatan serta satu tindakan sebenar sebelum anda mempercayainya semula. Melakukan rollback bermakna meletakkan semula tag lama, yang hanya berfungsi kerana anda telah menetapkannya (pinned).

FAQ

Adakah saya memerlukan domain awam untuk mengehos sendiri Open Connector?

Bagi penyedia yang menggunakan API key, tidak perlu: gateway pada 127.0.0.1 sudah memadai. Bagi OAuth, secara praktikalnya ya. Penyedia akan mengubah hala pelayar ke URL panggil balik (callback URL) anda, jadi URL tersebut perlu boleh diselesaikan daripada internet awam, dan penyedia menolak http:// biasa selain localhost. Tetapkan OOMOL_CONNECT_ORIGIN kepada hostname https:// anda sebelum permulaan pertama, dan daftarkan <origin>/oauth/callback dalam aplikasi OAuth penyedia tersebut.

Apakah yang berlaku jika saya kehilangan kunci penyulitan Open Connector?

Kredensial yang disimpan tidak boleh dinyahsulit, dan tiada cara pemulihan. Kunci tersebut sengaja tidak disimpan bersama data, supaya sesiapa yang memegang pangkalan data tidak boleh membacanya, termasuk anda sendiri. Satu-satunya pilihan anda ialah menetapkan kunci baharu dan menyambung semula setiap penyedia. Simpan kunci tersebut dalam pengurus kata laluan dan pangkalan data dalam kitaran sandaran anda, kerana pemulihan memerlukan kedua-duanya.

Bolehkah ejen AI saya melihat token akses penyedia?

Tidak apabila ia memanggil melalui gateway. Ejen mengesahkan diri dengan token runtime yang bermula dengan oct_, dan gateway menyuntik kredensial penyedia ke dalam permintaan keluar pada pelayan, serta hanya memulangkan respons. Dua perkara melanggar sifat tersebut: endpoint /v1/proxy/:service, yang memajukan permintaan mentah dengan kredensial anda dilampirkan dan yang geran (grants) permulaannya kosong atas sebab tertentu, serta menampal API key ke dalam ejen sendiri, yang melangkau gateway sepenuhnya.

Patutkah gateway boleh dicapai daripada internet awam?

Hanya /oauth/callback yang perlu. Terbitkan port kontena pada 127.0.0.1 supaya peraturan NAT Docker tidak boleh mendedahkannya melepasi firewall anda, dan letakkan reverse proxy di hadapan. Kemudian, uji satu panggilan tindakan tanpa header authorization. Jika berjaya, hadkan /api, /v1 dan /mcp pada proksi kepada alamat yang digunakan oleh ejen anda sehingga hanya panggilan yang disahkan sahaja yang berfungsi.

Adakah Open Connector sedia untuk kegunaan pengeluaran (production)?

Ia dilesenkan di bawah Apache 2.0 dan berkembang pesat: repositori muncul pada 29 Jun 2026 dan v1.3.3 dikeluarkan pada 30 Julai 2026, jadi anggap setiap nombor versi dalam panduan ini sebagai gambaran pada 1 Ogos 2026. Jalankannya dengan versi yang ditetapkan pada release tag, jangan sekali-kali pada latest atau tip, baca nota keluaran sebelum setiap naik taraf, dan simpan sandaran volum yang pernah anda pulihkan sekali. Reka bentuknya kukuh untuk pelayan yang anda miliki, dan risikonya terletak pada perubahan versi yang kerap, bukan pada seni bina.