Cara Self-Host Planka dengan Docker Compose

Apa yang Anda dapatkan dengan melakukan self-hosting Planka

Self-hosting Planka memberi tim Anda papan Kanban dengan model kartu, daftar, dan label yang sudah dikenal dari Trello, tetapi berjalan pada VPS yang Anda kendalikan. Tidak ada batas jumlah pengguna dan tidak ada penagihan per pengguna, karena satu-satunya biaya adalah server. Panduan ini melakukan deployment dengan Docker Compose di belakang Traefik, menggunakan Postgres untuk data dan named volume untuk setiap file yang diunggah pengguna.

Panduan ini ditujukan untuk tim beranggotakan dua hingga lima orang yang akan keluar dari free tier Trello. Jika Anda masih menentukan board yang akan digunakan, baca perbandingan alternatif Trello yang dapat di-self-host terlebih dahulu. Panduan ini mengasumsikan bahwa pilihan tersebut sudah ditetapkan dan hanya membahas deployment.

Anda memerlukan VPS yang menjalankan Docker Engine dengan Compose plugin, serta DNS A record yang mengarah ke VPS tersebut. Anda juga memerlukan instance Traefik yang sudah melakukan TLS termination (transport layer security) pada server itu. Jika Traefik belum tersedia, siapkan reverse proxy Traefik di depan beberapa aplikasi Compose terlebih dahulu, dan baca dasar-dasar Docker Compose untuk VPS jika file di bawah ini belum familiar bagi Anda.

Berapa kapasitas VPS yang dibutuhkan Planka?

Proyek ini tidak menerbitkan spesifikasi minimum perangkat keras. Karena itu, anggap setiap angka yang Anda baca sebagai titik awal, bukan hasil pengukuran. Angka 2 vCPU dan 4 GB yang sering dicantumkan halaman hosting adalah konfigurasi default yang nyaman dari provider, bukan kebutuhan yang diukur oleh proyek. Untuk board yang digunakan lima orang, konfigurasi itu cukup longgar.

Komponen yang benar-benar berjalan berukuran kecil: satu proses Node.js yang melayani API dan frontend yang sudah di-build, serta satu proses Postgres yang menyimpan data. Satu proses proxy kecil juga berjalan di dalam container Planka untuk memfilter request keluar. Paket dengan 1 vCPU dan 2 GB dapat menangani board dengan dua hingga lima orang. Sebagian besar memori yang tersisa akan digunakan sebagai cache Postgres. Board hanya menggunakan sedikit resource. Jadi, jika VPS yang sama juga akan menyimpan dokumen tim Anda, tentukan kapasitas berdasarkan aplikasi tersebut terlebih dahulu: menjalankan AFFiNE sebagai workspace bergaya Notion memerlukan beberapa gigabyte untuk dirinya sendiri sebelum Planka membutuhkan resource apa pun.

Tentukan kapasitas disk sebelum kapasitas memori, karena attachment adalah bagian yang terus bertambah. Ukur instance Anda sendiri, bukan mengandalkan paragraf ini:

docker stats --no-stream
docker system df -v

Perintah pertama menampilkan penggunaan memori dan CPU setiap container secara langsung. Perintah kedua menunjukkan kapasitas yang digunakan setiap volume. Ambil kedua hasil tersebut setelah satu minggu kerja normal, bukan pada hari instalasi, karena board yang tidak digunakan tidak memberikan informasi tentang kebutuhan tim Anda.

Tulis file Compose

Buat direktori tersebut dan ubah kepemilikannya agar Anda tidak perlu mengedit file ini melalui sudo.

sudo mkdir -p /opt/planka
sudo chown "$USER":"$USER" /opt/planka
cd /opt/planka

Buat secret ke dalam file .env di samping file Compose. Compose membaca file tersebut secara otomatis dan mengganti nilainya.

umask 077
{
  printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 64)"
  printf 'POSTGRES_PASSWORD=%s\n' "$(openssl rand -hex 24)"
  printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 12)"
} > .env
chmod 600 .env

Penggunaan openssl rand -hex dilakukan dengan sengaja. String heksadesimal hanya berisi digit dan huruf a hingga f, sehingga tidak dapat merusak string koneksi DATABASE_URL tempat string tersebut ditempelkan. Password base64 yang berisi garis miring atau tanda at dapat menghasilkan error koneksi yang tampak seperti hostname yang salah, dan ini dapat menghabiskan waktu satu jam. Pola yang lebih luas dibahas dalam menyimpan secret di luar file Compose.

Sekarang docker-compose.yml. Ganti kanban.example.com dengan hostname Anda sendiri di kedua tempat kemunculannya.

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - planka-data:/app/data
    environment:
      - BASE_URL=https://kanban.example.com
      - DATABASE_URL=postgresql://planka:${POSTGRES_PASSWORD}@postgres/planka
      - SECRET_KEY=${SECRET_KEY}
      - TRUST_PROXY=true
      - DEFAULT_ADMIN_EMAIL=you@example.com
      - DEFAULT_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - DEFAULT_ADMIN_NAME=Your Name
      - DEFAULT_ADMIN_USERNAME=admin
    networks:
      - proxy
      - internal
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.planka.rule=Host(`kanban.example.com`)"
      - "traefik.http.routers.planka.entrypoints=websecure"
      - "traefik.http.routers.planka.tls.certresolver=default"
      - "traefik.http.services.planka.loadbalancer.server.port=1337"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_USER=planka
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  planka-data:
  db-data:

networks:
  proxy:
    external: true
  internal:

Empat keputusan dalam file tersebut perlu dijelaskan karena biasanya orang mengubahnya lalu menyesal.

• Tidak ada blok ports: pada service Planka. Traefik menjangkau container melalui jaringan proxy, sehingga port 1337 tidak pernah dipublikasikan pada host. Mempublikasikannya akan memberi siapa pun cara untuk melewati proxy dan sertifikat Anda.
• loadbalancer.server.port=1337 menentukan port di dalam container. Planka listen pada port 1337, sedangkan contoh upstream hanya dapat menjangkaunya melalui port 3000 karena port tersebut dipetakan ke host. Tidak ada pemetaan ke host di sini, jadi Traefik harus diberi tahu tentang port container.
• condition: service_healthy dipasangkan dengan healthcheck Postgres. Tanpa pengaturan ini, Planka start sebelum database menerima koneksi, gagal pada query pertamanya, lalu keluar. Kondisi tersebut tampak seperti crash loop. Mekanismenya dijelaskan dalam healthcheck Compose dan urutan startup.
• Service database diberi nama postgres dengan sengaja. Planka 2 merutekan request keluarnya sendiri melalui filter internal dengan daftar blokir default localhost,postgres. Jika Anda mengganti nama service tersebut, database Anda secara diam-diam dihapus dari daftar itu.

Periksa apakah Compose dapat melihat secret Anda sebelum menjalankan apa pun:

docker compose config | grep -E 'image:|BASE_URL|POSTGRES_USER'

Perintah tersebut menampilkan file dengan nilai .env yang sudah diganti. Nilai kosong berarti Compose tidak membaca file .env, biasanya karena Anda menjalankan perintah dari direktori yang berbeda.

Apa yang sebenarnya dilakukan variabel bootstrap admin

Sejak Planka 1.13, tidak ada administrator yang dibuat secara otomatis. Database baru karena itu tidak memiliki pengguna yang dapat login. Grup DEFAULT_ADMIN_* adalah salah satu dari dua cara untuk mengatasinya.

Saat memulai, Planka mencari pengguna yang cocok dengan DEFAULT_ADMIN_EMAIL. Jika pengguna tersebut tidak ada, Planka membuatnya menggunakan password, nama tampilan, dan username yang ditetapkan bersamanya. Proses ini terjadi pada boot pertama terhadap database kosong. Jadi, variabel ini digunakan untuk melakukan bootstrap akun, bukan untuk mengelolanya.

DEFAULT_ADMIN_EMAIL memiliki fungsi kedua yang sering menimbulkan masalah. Selama variabel ini masih ditetapkan, akun yang disebutkan tidak dapat diedit atau dihapus dari antarmuka oleh siapa pun. Ini adalah perlindungan terhadap terkuncinya akses. Karena itu, Anda juga tidak dapat mengganti nama akun atau mengubah alamat emailnya melalui UI. Hapus variabel tersebut lalu mulai ulang. Setelah itu, akun menjadi admin biasa yang dapat diedit seperti akun lain.

Baris password memerlukan perhatian khusus. Apa pun yang berada di bawah environment: dapat dibaca oleh siapa pun yang dapat menjalankan docker inspect pada container. Karena itu, DEFAULT_ADMIN_PASSWORD tidak boleh dibiarkan di sana secara permanen. Login, ubah password melalui antarmuka, hapus baris tersebut, lalu jalankan docker compose up -d lagi.

Cara yang lebih bersih tidak menggunakan variabel sama sekali. Beri komentar pada seluruh grup DEFAULT_ADMIN_*, lalu buat akun secara interaktif:

docker compose run --rm planka npm run db:create-admin-user

Perintah ini meminta email, password, nama tampilan, dan username opsional, lalu langsung menulis pengguna ke database. Password tidak pernah masuk ke file Compose atau environment container. Gunakan cara ini jika lebih dari satu orang memiliki akses shell ke VPS. Perintah tersebut memulai Postgres terlebih dahulu karena depends_on, sehingga dapat digunakan pada stack yang belum pernah dijalankan.

Kedua cara tersebut membuat Anda tetap harus mengelola password Planka secara manual. Jika ini merupakan kumpulan kredensial keempat yang harus dikelola tim Anda, Planka dapat mendelegasikan login ke penyedia OIDC seperti Authentik yang berjalan sebagai server single sign-on milik Anda sendiri, sementara admin bootstrap tetap digunakan sebagai akun break-glass jika penyedia tersebut tidak tersedia.

Mengapa BASE_URL menyebabkan login gagal jika tidak sesuai dengan hostname

BASE_URL adalah alamat lengkap yang diketik pengguna di browser, termasuk scheme dan tanpa garis miring di akhir. Untuk stack ini, nilainya adalah https://kanban.example.com. Planka membuat link dan koneksi WebSocket-nya sendiri berdasarkan nilai tersebut. Karena itu, BASE_URL yang salah tidak menghasilkan error yang jelas. Halaman tetap dimuat, tetapi proses pemuatan tidak pernah selesai.

Kasus yang umum terjadi: Anda menyalin contoh dari upstream, membiarkan BASE_URL=http://localhost:3000, lalu mengakses situs melalui HTTPS pada domain yang sebenarnya. Form login terkirim dan kredensial Anda diterima. Namun, board tidak pernah muncul. Buka konsol developer browser. Anda akan melihat request ke /socket.io/ gagal karena client diarahkan untuk membuka koneksi langsungnya ke localhost:3000, sedangkan alamat tersebut tidak ada di laptop Anda.

TRUST_PROXY=true adalah bagian lain dari masalah yang sama. Planka berjalan di belakang Traefik, sehingga setiap request diterima dari alamat proxy melalui HTTP biasa di dalam jaringan Docker. Tanpa TRUST_PROXY, aplikasi mengabaikan header X-Forwarded-Proto dan X-Forwarded-For yang ditetapkan Traefik. Akibatnya, aplikasi menganggap koneksi tidak aman dan memperlakukan semua client sebagai satu alamat IP yang sama. Jika opsi tersebut diaktifkan, aplikasi membaca header itu dan menggunakan scheme yang sama dengan browser.

Traefik memproksikan WebSocket tanpa konfigurasi tambahan. Ini adalah salah satu alasan untuk memilihnya dalam kasus ini. Pada nginx, socket.io memerlukan block location tersendiri yang memuat proxy_set_header Upgrade $http_upgrade dan proxy_set_header Connection "upgrade". Jika tidak, spinner akan tetap berputar karena penyebab yang berbeda.

Memindahkan board ke hostname baru nantinya berarti mengubah dua hal secara bersamaan: nilai BASE_URL dan rule Host() Traefik. Jika hanya salah satunya yang diubah, spinner akan muncul lagi. Menyajikan Planka dari subpath seperti https://example.com/planka didukung mulai versi 2.1.0, yang dirilis pada Maret 2026. Pada tag yang lebih lama, gunakan subdomain khusus untuk Planka.

Lokasi penyimpanan lampiran dan avatar oleh Planka

Planka 2 menyimpan semua file yang diunggah pengguna pada satu path di dalam container: /app/data. Lampiran, avatar pengguna, dan gambar latar belakang board semuanya berada di dalamnya. Versi 1 menggunakan tiga direktori terpisah. Karena itu, file Compose yang disalin dari panduan lama akan melakukan mount pada path yang sudah tidak ada, sementara direktori data yang sebenarnya tidak di-mount.

Mount tunggal tersebut menentukan apakah board tetap ada setelah upgrade atau justru menimbulkan masalah. Jika /app/data tidak berada pada volume, file yang diunggah akan masuk ke writable layer milik container. Layer tersebut dihapus saat container dibuat ulang. Container dibuat ulang setiap kali Anda mengubah image tag. Board akan kembali dengan tampilan normal, semua card masih ada, tetapi setiap link lampiran tidak lagi berfungsi karena row pada database masih menunjuk ke file yang sudah tidak ada.

Named volume pada file Compose di atas mencegah masalah ini. Bind mount juga dapat digunakan dan membuat file lebih mudah dicadangkan dengan tool biasa, tetapi memerlukan satu langkah tambahan. Proses Node di dalam container berjalan sebagai UID 1000. Karena itu, direktori pada host yang dimiliki root akan menghasilkan permission error saat upload pertama:

sudo chown -R 1000:1000 /opt/planka/data

Perbedaan antara kedua pilihan tersebut dibahas dalam bind mount dibandingkan named volume.

Jika jumlah lampiran melebihi kapasitas disk pada plan Anda, Planka juga dapat menulisnya ke storage yang kompatibel dengan S3 melalui S3_ENDPOINT, S3_BUCKET, dan variabel key yang sesuai. Storage tersebut dapat menunjuk ke bucket terkelola atau ke object store MinIO yang di-host sendiri pada server lain. Tentukan pilihan ini sebelum tim memenuhi board, karena pengaturan tersebut hanya berlaku untuk upload baru.

Mulai stack dan periksa apakah berhasil

docker compose pull
docker compose up -d
docker compose ps

docker compose ps seharusnya menampilkan postgres sebagai healthy dan planka sebagai running. Jika Planka terus melakukan restart dalam loop, hal pertama yang harus diperiksa adalah koneksi database, bukan aplikasi.

docker compose logs -f planka

Boot pertama yang sehat akan menjalankan migrasi database, lalu melaporkan bahwa server sedang listen pada port 1337. Pastikan schema benar-benar telah diterapkan dengan memeriksa Postgres secara langsung, bukan hanya mempercayai log:

docker compose exec postgres psql -U planka -d planka -c '\dt'

Daftar tabel yang mencakup board dan card berarti migrasi telah berjalan. Pesan "Did not find any relations" berarti Planka tidak pernah terhubung, jadi bandingkan DATABASE_URL dengan nilai POSTGRES_USER dan POSTGRES_PASSWORD dalam .env.

Selanjutnya, periksa route dari mesin Anda sendiri, bukan dari VPS:

curl -I https://kanban.example.com

HTTP/2 200 berarti Traefik memiliki sertifikat dan berhasil menjangkau container. Respons 404 yang diberikan oleh Traefik berarti label router tidak cocok, biasanya karena container tidak terhubung ke network proxy. Sekarang buka situs tersebut dan login menggunakan akun admin.

Ambil pg_dump sebelum setiap peningkatan versi

Dua penyimpanan terpisah menyimpan board Anda, sehingga backup harus mencakup keduanya: database Postgres dan volume planka-data. Buat dump database saat stack masih berjalan.

docker compose exec -T postgres pg_dump -U planka -d planka > "planka-db-$(date +%F).sql"

-T tidak bersifat opsional. Tanpanya, Compose mengalokasikan pseudo-terminal, lalu lapisan terminal mengubah akhiran baris dalam stream. Akibatnya, file dump gagal di tengah proses restore. Kegagalan ini baru terlihat beberapa minggu kemudian, pada waktu yang paling tidak tepat.

Berikutnya, backup upload. Cari nama volume yang sebenarnya terlebih dahulu karena Compose menambahkan awalan berupa nama direktori project.

docker volume ls | grep planka
docker run --rm -v planka_planka-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files-$(date +%F).tgz -C /data .

Project ini juga menyediakan docker-backup.sh dan docker-restore.sh di repository-nya, dan dokumentasi resminya menjadwalkan keduanya melalui cron nightly. Keduanya dapat digunakan. Namun, backup yang belum pernah Anda restore tidak dapat dianggap valid. Karena itu, restore backup tersebut ke VPS sementara satu kali dan pastikan Anda dapat login serta membuka attachment. Pasangan penyimpanan yang sama muncul pada setiap aplikasi Compose yang menerima upload. Jadi, jika nanti Anda menempatkan Chatwoot pada server yang sama dengan helpdesk Anda, prosedur yang dibuat di sini dapat diterapkan kembali dengan perubahan yang hampir hanya pada nama volume.

Jalankan dump tepat sebelum setiap perubahan versi. Backup dari tadi malam tidak sama dengan backup yang dibuat sebelum migration yang akan Anda jalankan.

Tetapkan tag dan baca catatan rilis

Kedua tag image dalam file tersebut sengaja ditetapkan secara tetap.

ghcr.io/plankanban/planka:2.1.1 adalah rilis tertentu yang berlaku per Agustus 2026. latest berubah setiap kali upstream menerbitkan rilis, sehingga docker compose pull rutin dapat menerapkan migrasi skema pada waktu yang tidak Anda pilih. Baca catatan rilis sebelum mengubah angka tersebut, karena perubahan yang tidak kompatibel dan perbaikan keamanan dijelaskan di sana. Version 2.0.3 diterbitkan sebagai rilis keamanan. Hal seperti inilah yang perlu Anda baca, bukan terapkan secara tidak sengaja. Penetapan tag secara tetap mudah dilakukan di sini karena upstream memang menerbitkan image. Jika suatu project tidak menerbitkan image, Anda tetap harus menerapkan disiplin yang sama dengan satu langkah tambahan, seperti pada openGym yang dibuat di mesin dari git tag yang telah di-checkout.

postgres:16-alpine ditetapkan ke major version karena alasan yang lebih penting. Postgres menulis direktori datanya dalam format yang terkait dengan major version, dan server menolak membuka direktori yang ditulis oleh versi berbeda. Tulis postgres:latest, biarkan tag berubah ke 17, dan container tidak akan berjalan:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.

Tidak ada data yang hilang, dan restart juga tidak memperbaiki masalah ini. Beralih ke major version Postgres yang baru berarti membuat dump dari versi lama, lalu melakukan restore ke direktori data baru pada versi yang baru. Ini adalah pekerjaan terencana yang dilakukan saat stack dihentikan, bukan efek samping dari pengambilan image.

Jika Anda memindahkan instalasi Planka 1.x yang sudah ada, bukan memulai dari awal, upgrade tersebut memiliki prosedur terdokumentasi tersendiri dalam dokumentasi project, dan tidak ada cara untuk kembali ke version 1 tanpa backup yang dibuat sebelumnya.

Mode kegagalan dan string yang akan Anda lihat

Planka terus dimulai ulang dalam loop, dan log menyebutkan database. Kredensial dalam DATABASE_URL tidak cocok dengan environment Postgres. Perhatikan bahwa POSTGRES_PASSWORD hanya diterapkan saat direktori data pertama kali diinisialisasi. Jadi, memperbaiki variabel tersebut setelah boot pertama yang gagal tidak mengubah apa pun. Anda harus menghapus volume db-data lalu memulai kembali.

Login berhasil, tetapi board tidak pernah dimuat. BASE_URL tidak cocok dengan alamat pada bilah browser, atau TRUST_PROXY tidak ada. Konsol browser menampilkan request yang gagal ke /socket.io/.

Upload gagal, sedangkan fungsi lainnya berjalan normal. Penyebabnya adalah bind mount yang dimiliki oleh root. Jalankan sudo chown -R 1000:1000 pada direktori host, lalu mulai ulang container.

Lampiran hilang setelah upgrade. /app/data tidak berada pada volume. Akibatnya, file tersimpan di container layer yang diganti oleh upgrade. Pulihkan file dari backup, lalu tambahkan volume sebelum mengubah image tag lagi.

Traefik mengembalikan 404. Container tidak berada pada network proxy, atau rule Host() tidak cocok dengan DNS record Anda. docker compose config menampilkan label setelah substitusi. Di situlah kesalahan pengetikan dapat terlihat.

Notifikasi atau webhook tidak pernah tiba. Planka 2 mengirim request HTTP keluar melalui filter internal, dan block list default mencakup localhost dan postgres. Webhook yang diarahkan ke container lain pada host yang sama dapat diblokir secara sengaja. Sesuaikan OUTGOING_ALLOWED_HOSTS, bukan menghapus filter tersebut.

Setelah berjalan, beban operasionalnya kecil. Pantau release notes dan dump database sebelum setiap upgrade. Reboot akan menjalankan kembali stack secara otomatis karena restart: unless-stopped, selama service Docker sendiri diaktifkan saat boot. Stack Compose yang kembali berjalan setelah reboot membahas kasus ketika service tersebut tidak aktif.

FAQ

Mengapa Planka terus memuat setelah saya login?

Kredensial diterima, tetapi koneksi live gagal. Planka membangun URL WebSocket dari BASE_URL. Jadi, jika variabel tersebut masih berisi http://localhost:3000 saat Anda mengakses situs melalui https://kanban.example.com, browser mencoba membuka socket ke alamat yang tidak ada di mesin Anda. Konsol developer menampilkan permintaan yang gagal ke /socket.io/. Atur BASE_URL ke alamat publik yang tepat tanpa garis miring di akhir. Tambahkan TRUST_PROXY=true agar aplikasi menggunakan header X-Forwarded-Proto dari reverse proxy, lalu jalankan docker compose up -d.

Bagaimana cara membuat pengguna admin Planka pertama?

Sejak versi 1.13, administrator tidak lagi dibuat secara otomatis. Anda dapat mengatur DEFAULT_ADMIN_EMAIL beserta variabel kata sandi, nama, dan username yang sesuai, lalu menjalankan stack. Alternatifnya, jalankan docker compose run --rm planka npm run db:create-admin-user dan jawab prompt yang ditampilkan. Perintah interaktif lebih aman pada server bersama karena kata sandi tidak pernah masuk ke environment container yang dapat dibaca oleh docker inspect. Jika DEFAULT_ADMIN_EMAIL tetap diatur setelahnya, akun tersebut tidak dapat diedit atau dihapus dari antarmuka.

Di mana Planka menyimpan lampiran dan avatar?

Semua file yang diunggah disimpan di /app/data dalam container pada Planka 2. Ini mencakup lampiran, avatar pengguna, dan latar belakang board. Mount path tersebut pada named volume. Jika path itu tidak di-mount, file berada di writable layer milik container dan akan dihapus saat container dibuat ulang. Hal ini terjadi setiap kali image diperbarui. Bind mount juga dapat digunakan, tetapi proses Node berjalan sebagai UID 1000. Karena itu, jalankan sudo chown -R 1000:1000 pada direktori host, atau proses upload akan gagal karena masalah izin.

Berapa banyak RAM yang diperlukan Planka yang di-host sendiri?

Proyek ini tidak menetapkan kebutuhan perangkat keras minimum. Angka 2 vCPU dan 4 GB yang sering dicantumkan pada halaman hosting merupakan konfigurasi default provider, bukan hasil pengukuran. Angka tersebut juga cukup besar untuk board kecil. Beban kerjanya hanya terdiri atas satu proses Node dan satu proses Postgres. Jadi, paket dengan 1 vCPU dan 2 GB dapat melayani tim beranggotakan dua hingga lima orang. Jalankan docker stats --no-stream setelah satu minggu penggunaan normal, lalu tentukan kapasitas berdasarkan data Anda sendiri. Pantau disk lebih cermat daripada memori karena lampiranlah yang terus bertambah.

Bagaimana cara memperbarui Planka tanpa kehilangan data?

Dump database dan arsipkan volume upload tepat sebelum pembaruan, bukan hanya mengandalkan jadwal pencadangan semalam. Gunakan docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql dan pertahankan -T agar pseudo-terminal tidak merusak output yang dialihkan. Baca catatan rilis untuk setiap versi yang Anda lewati. Ubah tag image ke rilis tertentu, bukan latest. Setelah itu, jalankan docker compose pull dan docker compose up -d, lalu monitor log untuk melihat proses migrasi. Pertahankan tag Postgres pada versi mayor yang sama karena server menolak membuka direktori data yang ditulis oleh versi mayor berbeda.