Paano i-self-host ang Planka gamit ang Docker Compose

Ano ang makukuha mo sa pag-self-host ng Planka

Sa pag-self-host ng Planka, magkakaroon ang team mo ng Kanban board na gumagamit ng card, list, at label model na pamilyar na sa mga gumagamit ng Trello, at tatakbo ito sa isang VPS na kontrolado mo. Walang limitasyon sa bilang ng seat at walang per-user billing, dahil server lamang ang tanging gastos. Ide-deploy ng guide na ito ang Planka gamit ang Docker Compose sa likod ng Traefik, gamit ang Postgres para sa data at named volume para sa bawat file na ina-upload ng mga user.

Ang target na reader ay isang team na may dalawa hanggang lima katao at umaalis sa free tier ng Trello. Kung nagpapasya ka pa kung aling board ang gagamitin, basahin muna ang paghahambing ng mga self-hosted na alternatibo sa Trello. Ipinapalagay ng guide na ito na napili na ang board at deployment lamang ang saklaw nito.

Kailangan mo ng VPS na nagpapatakbo ng Docker Engine na may Compose plugin, at DNS A record na nakaturo rito. Kailangan mo rin ng Traefik instance na naka-configure na para sa TLS (transport layer security) termination sa server na iyon. Kung wala pa ang Traefik, i-set up muna ang Traefik reverse proxy sa harap ng maraming Compose app, at basahin ang mga pangunahing konsepto ng Docker Compose para sa VPS kung hindi pamilyar sa iyo ang file sa ibaba.

Gaano kalaking VPS ang kailangan ng Planka?

Hindi naglalathala ang project ng minimum na hardware, kaya ituring ang anumang numerong mababasa mo bilang panimulang gabay, hindi bilang aktuwal na sukat. Ang 2 vCPU at 4 GB na figure na inuulit ng mga hosting page ay komportableng default ng provider, hindi requirement na sinukat ng project. Maluwag na ito para sa board na ginagamit ng limang tao.

Maliit lang ang aktuwal na tumatakbo: isang Node.js process para sa API at built frontend, at isang Postgres process para sa data. May ikatlo ring maliit na proxy process sa loob ng Planka container para i-filter ang mga outgoing request nito. Kayang patakbuhin ng 1 vCPU at 2 GB na plan ang board na ginagamit ng dalawa hanggang limang tao, at kadalasang napupunta sa Postgres cache ang karamihan ng ekstrang memory.

Unahin ang pag-size ng disk bago ang memory, dahil attachments ang pinakamabilis lumaki. Sukatin ang sarili mong instance sa halip na umasa sa talatang ito:

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

Ipinapakita ng una ang kasalukuyang memory at CPU usage ng bawat container. Ipinapakita naman ng ikalawa kung gaano kalaking space ang ginagamit ng bawat volume. Kunin ang dalawang reading matapos ang isang normal na linggo ng trabaho, hindi sa araw ng installation, dahil walang masasabi tungkol sa team mo ang idle na board.

Isulat ang Compose file

Gawin ang directory at kunin ang ownership nito para hindi mo kailangang i-edit ang mga file na ito sa pamamagitan ng sudo.

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

I-generate ang mga secret sa isang .env file na katabi ng Compose file. Awtomatikong binabasa ng Compose ang file na iyon at pinapalitan ang mga value.

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

Sinasadya ang openssl rand -hex. Mga digit at letrang a hanggang f lamang ang laman ng hex string, kaya hindi nito masisira ang DATABASE_URL connection string kung saan ito ipinapasok. Kapag may slash o at sign ang base64 password, maaari itong magdulot ng connection error na mukhang maling hostname. Maaari kang mawalan ng isang oras sa pag-troubleshoot nito. Saklaw ng pag-iwas sa mga secret sa Compose file ang mas malawak na pattern.

Ngayon, docker-compose.yml. Palitan ang kanban.example.com ng sarili mong hostname sa dalawang lugar kung saan ito lumilitaw.

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:

Mahalagang ipaliwanag ang apat na desisyon sa file na iyon dahil ang mga ito ang karaniwang binabago at pinagsisisihan pagkatapos.

• Walang ports: block sa Planka service. Inaabot ng Traefik ang container sa pamamagitan ng proxy network, kaya hindi kailanman pini-publish sa host ang port 1337. Kapag ipinublish ito, magkakaroon ang sinuman ng paraan para lampasan ang proxy at ang certificate.
• Tinutukoy ng loadbalancer.server.port=1337 ang port sa loob ng container. Nakikinig ang Planka sa 1337, at naaabot lamang ito ng upstream example sa 3000 dahil mina-map nito ang port sa host. Walang host mapping dito, kaya kailangang sabihin sa Traefik ang port ng container.
• Kaakibat ng Postgres healthcheck ang condition: service_healthy. Kung wala ito, magsisimula ang Planka bago tumanggap ng connections ang database, mabibigo sa unang query nito, at mag-e-exit. Magmumukha itong crash loop. Nasa Compose healthchecks at startup ordering ang mga detalye ng mekanismo.
• Sadyang postgres ang pangalan ng database service. Sa Planka 2, ipinapadaan ng internal filter ang sarili nitong outgoing requests. Ang default block list nito ay localhost,postgres. Kapag pinalitan ang pangalan ng service, tahimik na maaalis ang database mo sa listahang iyon.

Suriin na nakikita ng Compose ang mga secret mo bago ka magsimula:

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

Ipi-print nito ang file na napalitan na ang .env values. Ibig sabihin na hindi binabasa ng Compose ang .env file kapag walang laman ang value. Karaniwan itong nangyayari kapag mula sa ibang directory mo pinapatakbo ang command.

Ano talaga ang ginagawa ng admin bootstrap variables

Mula sa Planka 1.13, walang administrator na awtomatikong ginagawa para sa iyo, kaya walang makaka-log in sa bagong database. Ang DEFAULT_ADMIN_* group ang isa sa dalawang paraan para ayusin ito.

Sa pagsisimula, hinahanap ng Planka ang user na tumutugma sa DEFAULT_ADMIN_EMAIL. Kung wala ito, gumagawa ang Planka ng user gamit ang password, display name, at username na itinakda kasama nito. Nangyayari ito sa unang boot gamit ang empty database, kaya nagbu-bootstrap ng account ang mga variable na ito sa halip na mag-manage nito.

May pangalawang ginagawa ang DEFAULT_ADMIN_EMAIL na kadalasang nakalilito. Habang nakatakda ang variable, hindi maaaring i-edit o i-delete ng sinuman ang account na tinutukoy nito mula sa interface. Lock-out guard ito. Ito rin ang dahilan kung bakit hindi mo maaaring palitan ang pangalan ng account o baguhin ang email address nito sa UI. Alisin ang variable at mag-restart. Magiging ordinary admin ang account na maaari mong i-edit tulad ng iba.

Ang password line ang kailangang pag-ingatan. Anumang nasa ilalim ng environment: ay mababasa ng sinumang maaaring magpatakbo ng docker inspect sa container, kaya hindi dapat manatili roon nang permanente ang DEFAULT_ADMIN_PASSWORD. Mag-log in, palitan ang password sa interface, i-delete ang line na iyon, at patakbuhin muli ang docker compose up -d.

Mas malinis na paraan ang tuluyang hindi paggamit ng mga variable. I-comment out ang buong DEFAULT_ADMIN_* group, pagkatapos ay gawin ang account nang interactive:

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

Hihingi ito ng email, password, display name, at optional na username. Isusulat nito ang user nang direkta sa database. Hindi kailanman mapupunta ang password sa Compose file o sa container environment. Gamitin ang paraang ito kung higit sa isang tao ang may shell access sa VPS. Inuuna ng command na simulan ang Postgres dahil sa depends_on, kaya gumagana ito sa stack na hindi pa kailanman na-start.

Sa alinmang paraan, ikaw pa rin ang manu-manong mamamahala sa mga Planka password. Kung ito na ang ikaapat na set ng credentials na kinokolekta ng team ninyo, maaaring sa halip ay ipaubaya ng Planka ang mga login sa isang OIDC provider gaya ng Authentik na tumatakbo bilang sarili mong single sign-on server, habang pinananatiling break-glass account ang bootstrap admin para sa araw na hindi available ang provider.

Bakit nakakasira ng login ang BASE_URL kapag hindi tugma sa hostname

Ang BASE_URL ay ang eksaktong address na tina-type ng mga user sa browser, kasama ang scheme at walang trailing slash. Para sa stack na ito, ito ay https://kanban.example.com. Ginagamit ng Planka ang value na iyon para buuin ang sarili nitong links at WebSocket connection. Ibig sabihin, ang maling BASE_URL ay hindi nagbabalik ng malinaw na error. Naglo-load ang page, pero hindi ito natatapos mag-load.

Ang karaniwang sitwasyon: kinopya mo ang upstream example, iniwan ang BASE_URL=http://localhost:3000, at binuksan ang site gamit ang HTTPS sa aktuwal mong domain. Naisusumite ang login form at tinatanggap ang credentials mo. Pero hindi lumalabas ang board. Buksan ang browser developer console at makikita mong nagfa-fail ang mga request papunta sa /socket.io/, dahil inutusan ang client na buksan ang live connection nito sa localhost:3000, at walang ganoong address sa laptop mo.

Ang TRUST_PROXY=true ang kabilang bahagi ng parehong problema. Nasa likod ng Traefik ang Planka, kaya bawat request ay dumarating dito mula sa address ng proxy gamit ang plain HTTP sa loob ng Docker network. Kapag wala ang TRUST_PROXY, binabalewala ng app ang mga header na X-Forwarded-Proto at X-Forwarded-For na itinatakda ng Traefik. Dahil dito, naniniwala ang app na insecure ang connection at tinatrato nito ang lahat ng client bilang iisang shared IP address. Kapag nakatakda ito, binabasa ng app ang mga header na iyon at nagtutugma ang scheme na nakikita nito sa scheme na ginagamit ng browser.

Walang kailangang dagdag na configuration ang Traefik para mag-proxy ng WebSockets. Isa ito sa mga dahilan kung bakit mas mainam itong gamitin dito. Sa nginx, kailangan ng socket.io ng sarili nitong location block na may proxy_set_header Upgrade $http_upgrade at proxy_set_header Connection "upgrade". Kung wala ang mga ito, makikita mo rin ang parehong spinner na hindi natatapos, pero iba ang sanhi.

Kung ililipat mo ang board sa bagong hostname, dalawang bagay ang kailangang baguhin nang sabay: ang value ng BASE_URL at ang Traefik Host() rule. Kapag isa lang ang binago mo, babalik ang spinner. Gumagana ang pag-serve ng Planka mula sa subpath gaya ng https://example.com/planka simula version 2.1.0, na inilabas noong March 2026. Sa mga mas lumang tag, gumamit ng sariling subdomain para rito.

Kung saan iniimbak ng Planka ang mga attachment at avatar

Iniimbak ng Planka 2 ang lahat ng ina-upload ng user sa iisang path sa loob ng container: /app/data. Nandoon ang mga attachment, user avatar, at background image ng board. Gumamit ang Version 1 ng tatlong magkahiwalay na directory, kaya ang Compose file na kinopya mula sa mas lumang gabay ay nagmo-mount ng mga path na hindi na umiiral, habang hindi naka-mount ang aktuwal na data directory.

Ang single mount na iyon ang nagdidikta kung makakaligtas ang board sa isang upgrade o haharap ka sa malaking abala. Kung wala sa volume ang /app/data, mapupunta ang mga upload sa writable layer ng container. Nabubura ang layer na iyon kapag nire-recreate ang container, at nire-recreate ang container sa tuwing binabago mo ang image tag. Maayos pa ring bumabalik ang board, naroon pa rin ang lahat ng card, pero patay na ang bawat attachment link dahil tumutukoy pa rin ang mga database row sa mga file na hindi na umiiral.

Pinipigilan ito ng named volume sa Compose file sa itaas. Gumagana rin ang bind mount at mas madaling i-back up ang mga file gamit ang karaniwang tools, pero kailangan nito ng isang karagdagang hakbang. Tumatakbo ang Node process sa loob ng container bilang UID 1000, kaya magdudulot ng permission error ang host directory na pagmamay-ari ng root sa unang upload:

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

Tinalakay sa bind mounts kumpara sa named volumes ang trade-off ng dalawang ito.

Kung lumampas na ang laki ng mga attachment sa disk space ng plan mo, maaaring isulat ng Planka ang mga ito sa S3-compatible storage sa halip, gamit ang S3_ENDPOINT, S3_BUCKET, at ang katugmang key variables. Maaari itong tumuro sa isang hosted bucket o sa self-hosted MinIO object store sa ibang machine. Pagpasiyahan ito bago mapuno ng team ang board, dahil nalalapat ang setting sa mga bagong upload.

Simulan ang stack at tiyaking gumagana ito

docker compose pull
docker compose up -d
docker compose ps

Dapat ipakita ng docker compose ps ang postgres bilang healthy at ang planka bilang running. Kung paulit-ulit na nagre-restart ang Planka, ang database connection ang unang dapat suriin, hindi ang app.

docker compose logs -f planka

Sa maayos na unang boot, pinapatakbo ang database migrations at pagkatapos ay iniuulat na nakikinig ang server sa port 1337. Kumpirmahing na-apply talaga ang schema sa pamamagitan ng direktang pagtatanong sa Postgres, sa halip na umasa sa log:

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

Ibig sabihin ng listahan ng mga table na may kasamang board at card ay tumakbo ang migrations. Ang mensaheng "Did not find any relations" ay nangangahulugang hindi kailanman nakakonekta ang Planka, kaya ikumpara ang DATABASE_URL sa mga value na POSTGRES_USER at POSTGRES_PASSWORD sa iyong .env.

Pagkatapos, suriin ang route mula sa sarili mong machine, hindi mula sa VPS:

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

Ibig sabihin ng HTTP/2 200 ay may certificate ang Traefik at naaabot nito ang container. Ang 404 na ibinibigay ng Traefik ay nangangahulugang hindi nagtugma ang router labels, kadalasan dahil hindi nakakonekta ang container sa proxy network. Ngayon, buksan ang site at mag-log in gamit ang admin account.

Magsagawa ng pg_dump bago ang bawat pagtaas ng bersyon

Dalawang magkahiwalay na store ang naglalaman ng board mo, kaya kailangang saklaw ng backup ang dalawa: ang Postgres database at ang planka-data volume. I-dump ang database habang tumatakbo ang stack.

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

Hindi optional ang -T. Kung wala ito, naglalaan ang Compose ng pseudo-terminal, at nire-rewrite ng terminal layer ang line endings sa stream. Dahil dito, nagkakaroon ka ng dump file na pumapalya sa kalagitnaan ng restore. Lumilitaw ang failure makalipas ang ilang linggo, kung kailan ito ang pinakamasamang mangyari.

Sunod, ang uploads. Hanapin muna ang aktuwal na volume name, dahil nilalagyan ito ng Compose ng prefix na pangalan ng project directory.

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 .

Kasama rin sa repository ng project ang docker-backup.sh at docker-restore.sh, at inilalagay ng official documentation ang mga ito sa nightly cron job. Ayos ang alinmang approach. Ang hindi ayos ay backup na hindi mo pa kailanman na-restore. Kaya i-restore ang isa sa isang scratch VPS at tiyaking makakapag-log in ka at makakapagbukas ng attachment.

Patakbuhin ang dump kaagad bago ang bawat pagbabago ng bersyon. Hindi kapareho ang backup mula kagabi ng backup na ginawa bago ang migration na isasagawa mo.

I-pin ang tags at basahin ang release notes

Sadyang naka-pin ang dalawang image tag sa file na iyon.

Ang ghcr.io/plankanban/planka:2.1.1 ay isang partikular na release na kasalukuyan noong August 2026. Nagbabago ang latest tuwing may bagong publish ang upstream, kaya maaaring magdala ang regular na docker compose pull ng schema migration sa oras na hindi mo pinili. Basahin ang release notes bago baguhin ang numerong iyon, dahil doon inilalarawan ang breaking changes at security fixes. Na-publish ang Version 2.0.3 bilang security release. Ito mismo ang uri ng release na dapat mong basahin muna sa halip na aksidenteng maisama sa deployment.

Naka-pin ang postgres:16-alpine sa isang major version para sa mas mahalagang dahilan. Isinusulat ng Postgres ang data directory nito sa format na nakatali sa major version, at tumatanggi ang server na magbukas ng directory na isinulat ng ibang bersyon. Isulat ang postgres:latest, hayaang umusad ang tag sa 17, at hindi magsisimula ang container:

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.

Walang mawawala, at walang maaayos sa simpleng pag-restart. Ang paglipat sa bagong Postgres major ay nangangailangan ng dump mula sa lumang bersyon at restore sa bagong data directory. Planadong gawain ito habang naka-stop ang stack, hindi side effect ng pag-pull ng image.

Kung inililipat mo ang kasalukuyang Planka 1.x install sa halip na magsimula sa bago, may sarili itong dokumentadong procedure sa dokumentasyon ng proyekto, at walang paraan para bumalik sa version 1 kung walang backup na ginawa bago ang upgrade.

Mga failure mode at mga string na makikita mo

Paulit-ulit na nagre-restart ang Planka at binabanggit ng log ang database. Hindi tugma ang credentials sa DATABASE_URL sa Postgres environment. Tandaan na inilalapat lamang ang POSTGRES_PASSWORD kapag unang ini-initialize ang data directory, kaya walang mababago kung aayusin ang variable pagkatapos ng unang maling boot. Kailangan mong alisin ang db-data volume at magsimulang muli.

Matagumpay ang login pero hindi kailanman naglo-load ang board. Hindi tugma ang BASE_URL sa address sa browser bar, o nawawala ang TRUST_PROXY. Ipinapakita ng browser console ang mga request sa /socket.io/ na nabigo.

Nabibigo ang uploads pero gumagana ang lahat ng iba pa. May bind mount na pagmamay-ari ng root. Patakbuhin ang sudo chown -R 1000:1000 sa host directory at i-restart ang container.

Nawala ang attachments pagkatapos ng upgrade. Wala sa volume ang /app/data, kaya nasa container layer ang mga file at napalitan ito ng upgrade. I-restore ang mga file mula sa backup, pagkatapos ay idagdag ang volume bago muling baguhin ang image tag.

Nagbabalik ang Traefik ng 404. Wala ang container sa proxy network, o hindi tumutugma ang Host() rule sa DNS record mo. Ipinapakita ng docker compose config ang mga label pagkatapos ng substitution; dito nakikita ang mga typo.

Hindi kailanman dumarating ang mga notification o webhook. Ipinapadaan ng Planka 2 ang mga outgoing HTTP request nito sa isang internal filter, at saklaw ng default block list ang localhost at postgres. Maaaring ma-block ayon sa disenyo ang webhook na nakatutok sa ibang container sa parehong host. I-adjust ang OUTGOING_ALLOWED_HOSTS sa halip na alisin ang filter.

Kapag tumatakbo na ito, maliit na lamang ang operational load. Subaybayan ang release notes at mag-dump ng database bago ang bawat upgrade. Awtomatikong bumabalik ang stack pagkatapos ng reboot dahil sa restart: unless-stopped, basta naka-enable sa boot ang Docker service mismo. Sinasaklaw ng Compose stacks na awtomatikong bumabalik pagkatapos ng reboot ang mga sitwasyong hindi ito nangyayari.

FAQ

Bakit tuloy-tuloy ang pag-load ng Planka matapos kong mag-log in?

Tinanggap ang credentials, pero hindi ang live connection. Binubuo ng Planka ang WebSocket URL mula sa BASE_URL. Kaya kung nakalagay pa rin sa variable na iyon ang http://localhost:3000 habang ina-access mo ang site sa https://kanban.example.com, susubukan ng browser na magbukas ng socket sa address na wala sa machine mo. Makikita sa developer console ang mga nabigong request sa /socket.io/. Itakda ang BASE_URL sa eksaktong public address na walang trailing slash. Idagdag ang TRUST_PROXY=true upang gamitin ng app ang X-Forwarded-Proto header mula sa reverse proxy mo. Pagkatapos, patakbuhin ang docker compose up -d.

Paano ko gagawin ang unang Planka admin user?

Simula version 1.13, walang administrator na awtomatikong ginagawa. Itakda ang DEFAULT_ADMIN_EMAIL kasama ang katugmang password, name, at username variables, at pagkatapos ay simulan ang stack. Maaari ka ring magpatakbo ng docker compose run --rm planka npm run db:create-admin-user at sagutin ang mga prompt. Mas ligtas ang interactive command sa shared server dahil hindi pumapasok ang password sa container environment na mababasa ng docker inspect. Kapag nanatiling nakatakda ang DEFAULT_ADMIN_EMAIL, mapipigilan ang pag-edit at pag-delete sa account na iyon mula sa interface.

Saan iniimbak ng Planka ang attachments at avatars?

Lahat ng uploaded file ay nasa /app/data sa loob ng container sa Planka 2. Kasama rito ang attachments, user avatars, at board backgrounds. I-mount ang path na iyon sa isang named volume. Kapag hindi ito naka-mount, mananatili ang mga file sa writable layer ng container at mabubura sa susunod na ma-recreate ang container. Nangyayari ito sa bawat image upgrade. Maaari ring gumamit ng bind mount, pero tumatakbo ang Node process bilang UID 1000. Kaya patakbuhin ang sudo chown -R 1000:1000 sa host directory. Kung hindi, mabibigo ang uploads dahil sa permission error.

Gaano karaming RAM ang kailangan ng self-hosted Planka?

Walang inilalabas ang project na minimum hardware requirement. Ang 2 vCPU at 4 GB na paulit-ulit na nakikita sa mga hosting page ay default ng provider, hindi resulta ng measurement, at maluwag ito para sa maliit na board. Isang Node process at isang Postgres process lang ang buong workload. Kaya kayang suportahan ng 1 vCPU at 2 GB plan ang team na may dalawa hanggang lima. Patakbuhin ang docker stats --no-stream matapos ang karaniwang isang linggo, at gamitin ang sarili mong data sa pagtantya ng laki ng server. Mas bantayan ang disk kaysa memory dahil attachments ang mabilis lumaki.

Paano ko ia-upgrade ang Planka nang hindi nawawala ang data?

I-dump ang database at i-archive ang uploads volume kaagad bago ang upgrade, hindi batay sa schedule noong nakaraang gabi. Gamitin ang docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql, at panatilihin ang -T upang hindi masira ng pseudo-terminal ang redirected output. Basahin ang release notes para sa bawat version na lalaktawan mo. Palitan ang image tag ng partikular na release sa halip na latest. Pagkatapos, patakbuhin ang docker compose pull at docker compose up -d, at i-monitor ang log para sa migration. Panatilihing naka-pin ang Postgres tag sa major version nito dahil tumatangging buksan ng server ang data directory na isinulat ng ibang major version.