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.
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.
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.
O anúncio não cobra nada pelo software em si. O Azure continua cobrando a VM, o disco gerenciado e a banda de saída, mais o IP público e qualquer outra coisa que o template criar no resource group, e é por isso que a página do anúncio mostra um preço que varia em vez de um zero fixo. Uma coisa para checar antes de depender disso: o template fixa o container por digest e não por tag, e o digest do pacote que está no ar hoje leva à 0.16.0, a mesma release que o DigitalOcean entrega e duas atrás da 0.17.0 que estas páginas descrevem. Um digest não escorrega, então o que for implantado no mês que vem é o que é implantado agora; o painel de versão na instância rodando é onde você confirma isso.
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.
O template já vem com AUTH_COOKIE_SECURE=false, porque uma instalação na LAN é servida em HTTP puro. Se depois você puser o app atrás de um proxy reverso com HTTPS, mude para true. Deixar em false num host virado para a internet manda o seu cookie de sessão em texto puro.
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.
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.
Tour
@@ -4788,7 +4788,7 @@Settings
@@ -11531,7 +11531,7 @@