Self-host Planka gamit ang Docker Compose

Mga makukuha mo sa pag-self-host ng Planka

Ang pag-self-host ng Planka ay nagbibigay sa team mo ng Kanban board na gumagamit ng card, list, at label model na pamilyar na sa mga gumagamit ng Trello, at tumatakbo sa VPS na kontrolado mo. Walang limitasyon sa bilang ng seat at walang singil bawat user, dahil server lamang ang gastos. Idinedeploy ng gabay na ito ang Planka gamit ang Docker Compose sa likod ng Traefik, gamit ang Postgres para sa data at isang named volume para sa bawat file na ina-upload ng mga user.

Ang target na reader ng gabay na ito ay team na may dalawa hanggang lima katao at lumalampas na sa free tier ng Trello. Kung pinagpapasyahan mo pa kung aling board ang gagamitin, basahin muna ang paghahambing ng mga self-hosted na alternatibo sa Trello. Ipinapalagay ng gabay na ito na napili na ang board at ang 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 mag-terminate ng TLS (transport layer security) sa server na iyon. Kung wala pa ang Traefik, i-set up muna ang Traefik reverse proxy sa harap ng ilang Compose app, at basahin ang mga pangunahing konsepto ng Docker Compose para sa VPS kung hindi pamilyar sa iyo ang file sa ibaba.

Gaano karaming VPS ang kailangan ng Planka?

Hindi naglalabas ang proyekto ng minimum na hardware, kaya ituring ang anumang numerong mabasa mo bilang panimulang punto, hindi bilang aktuwal na sukat. Ang paulit-ulit na 2 vCPU at 4 GB na figure sa mga hosting page ay komportableng default ng provider, hindi requirement na sinukat ng proyekto. Maluwag na ito para sa board na ginagamit ng limang tao.

Maliit lang ang aktuwal na tumatakbo: isang Node.js process para maghatid ng API at built frontend, at isang Postgres process para maghawak ng data. May ikatlong maliit na proxy process sa loob ng Planka container para mag-filter ng mga outgoing request nito. Kayang patakbuhin ng 1 vCPU at 2 GB plan ang board para sa dalawa hanggang limang tao, at karamihan ng ekstrang memory ay napupunta sa Postgres cache. Magaang katabing workload ang board, kaya kung ang parehong VPS ay magho-host din ng mga dokumento ng team mo, unahin mong mag-size para sa app na iyon: kailangan ng pagpapatakbo ng AFFiNE bilang workspace na gaya ng Notion ng ilang gigabytes para sa sarili nito bago humingi ng resources ang Planka.

I-size muna ang disk bago ang memory, dahil ang attachments ang mabilis 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 para sa bawat container. Ipinapakita naman ng ikalawa kung gaano kalaking espasyo ang ginagamit ng bawat volume. Kunin ang dalawang reading matapos ang isang normal na linggo ng paggamit, hindi sa araw ng installation, dahil walang sinasabi tungkol sa team mo ang isang idle na board.

Isulat ang Compose file

Gawin ang directory at ilipat dito ang ownership, 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 sa tabi ng Compose file. Awtomatikong binabasa ng Compose ang file na iyon at pinapalitan nito 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

Sinadya 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, maaaring magkaroon ng connection error na mukhang maling hostname. Maaari kang mawalan ng isang oras sa pag-debug nito. Saklaw ng pag-iwas na ilagay ang 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. Iyan ang mga karaniwang binabago ng mga tao at pinagsisisihan nila kalaunan.

• Walang ports: block sa Planka service. Inaabot ng Traefik ang container sa pamamagitan ng proxy network, kaya hindi kailanman bina-publish sa host ang port 1337. Kapag ipinublish ito, magkakaroon ang sinuman ng paraan upang 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 tukuyin sa Traefik ang container port.
• Kaakibat ng Postgres healthcheck ang condition: service_healthy. Kung wala ito, magsisimula ang Planka bago tumanggap ng mga connection ang database, mabibigo ang unang query nito, at lalabas ito. Magmumukha itong crash loop. Nasa Compose healthchecks at startup ordering ang mga detalye ng mekanismo.
• Sinadyang postgres ang pangalan ng database service. Ipinapadaan ng Planka 2 ang sarili nitong mga outgoing request sa isang internal filter na ang default block list ay localhost,postgres. Kapag pinalitan mo ang pangalan ng service, tahimik mong inaalis ang database sa listahang iyon.

Tiyaking nakikita ng Compose ang mga secret bago ka magsimula:

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

Ipinapakita nito ang file na napalitan na ang .env values. Ang walang laman na value ay nangangahulugang hindi binabasa ng Compose ang .env file. Karaniwan itong nangyayari kapag pinapatakbo mo ang command mula sa ibang directory.

Ano talaga ang ginagawa ng admin bootstrap variables

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

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

May pangalawang gamit ang DEFAULT_ADMIN_EMAIL na madalas nakalilito. Habang nakatakda ang variable, hindi maaaring i-edit o i-delete ng sinuman ang account na tinutukoy nito mula sa interface. Ito ay lock-out guard, at ito rin ang dahilan kung bakit hindi mo maaaring palitan ang username o email address ng account na iyon sa UI. Alisin ang variable at mag-restart. Magiging ordinaryong admin ang account na maaari mong i-edit tulad ng iba.

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

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

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

Hihingi ito ng email, password, display name, at optional na username, at direktang isusulat ang user 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 password ng Planka. Kung ito na ang ikaapat na set ng credentials na kinokolekta ng team ninyo, maaaring ipaubaya ng Planka ang mga login sa isang OIDC provider gaya ng Authentik na tumatakbo bilang sarili ninyong single sign-on server, habang pinananatiling break-glass account ang bootstrap admin para sa araw na hindi available ang provider.

Bakit nakakasira ng mga login ang BASE_URL kapag hindi ito 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. Binubuo ng Planka ang sarili nitong mga link at WebSocket connection mula sa value na iyon. Ibig sabihin, kapag mali ang BASE_URL, hindi ito nagbibigay ng malinaw na error. Naglo-load ang page, pero hindi ito kailanman natatapos mag-load.

Karaniwang ganito ang nangyayari: kinokopya mo ang upstream example, iniiwan ang BASE_URL=http://localhost:3000, at ina-access ang site gamit ang HTTPS sa aktuwal mong domain. Naisusumite ang login form at tinatanggap ang iyong credentials. Hindi lumalabas ang board. Kapag binuksan mo ang browser developer console, makikita mong nagfa-fail ang mga request sa /socket.io/ dahil itinuro sa client na buksan ang live connection nito sa localhost:3000, at walang ganitong address sa laptop mo.

Ang TRUST_PROXY=true ang kabilang bahagi ng parehong problema. Nasa likod ng Traefik ang Planka, kaya dumarating ang bawat request mula sa address ng proxy gamit ang plain HTTP sa loob ng Docker network. Kung 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 itinuturing nitong iisang shared IP address ang lahat ng client. Kapag naka-set ito, binabasa ng app ang mga header na iyon at nagtutugma ang scheme na nakikita ng app at ng browser.

Pino-proxy ng Traefik ang WebSockets nang walang karagdagang configuration, kaya isa ito sa mga dahilan kung bakit mas mainam itong gamitin dito. Sa nginx, kailangan ng socket.io ng sarili nitong location block na naglalaman ng proxy_set_header Upgrade $http_upgrade at proxy_set_header Connection "upgrade". Kung wala ang mga ito, makukuha mo ang parehong spinner na hindi natatapos, pero ibang sanhi naman.

Kapag inilipat mo ang board sa bagong hostname, kailangan mong sabay na baguhin ang dalawang bagay: 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 mas lumang tags, bigyan ito ng sarili nitong subdomain.

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. Nasa path na ito ang mga attachment, avatar ng user, at background image ng board. Gumamit ang Version 1 ng tatlong magkakahiwalay na directory. Dahil dito, ang Compose file na kinopya mula sa mas lumang gabay ay nagmo-mount ng mga path na hindi na umiiral, kaya hindi naka-mount ang aktuwal na data directory.

Ang iisang mount na ito ang nagtatakda kung makakaligtas ang board sa upgrade o mauuwi sa abala. Kung wala sa volume ang /app/data, mapupunta ang mga upload sa writable layer ng container. Nabubura ang layer na ito kapag ni-recreate ang container. Nire-recreate ang container sa tuwing binabago mo ang image tag. Magbabalik na mukhang maayos ang board, naroon pa rin ang lahat ng card, ngunit hindi na gagana ang bawat attachment link dahil tumutukoy pa rin ang database row sa mga file na wala na.

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 tool, ngunit kailangan nito ng isang karagdagang hakbang. Tumatakbo ang Node process sa loob ng container bilang UID 1000. Kaya magbibigay ng permission error ang host directory na pagmamay-ari ng root sa unang upload:

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

Ipinaliwanag nang mas detalyado ang trade-off ng dalawang ito sa mga bind mount kumpara sa named volume.

Kung lumampas sa kapasidad ng disk sa plan mo ang mga attachment, maaaring isulat ng Planka ang mga ito sa S3-compatible storage sa halip, sa pamamagitan ng S3_ENDPOINT, S3_BUCKET, at mga katumbas na key variable. Maaari itong tumuro sa isang hosted bucket o sa self-hosted MinIO object store sa ibang server. Itakda ito bago mapuno ng team ang board dahil nalalapat ang setting sa mga bagong upload.

Simulan ang stack at tiyaking gumana 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, 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. Direktang tanungin ang Postgres para makumpirmang nailapat talaga ang schema, 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 kasama ang board at card ay tumakbo ang migrations. Ang mensaheng "Did not find any relations" ay nangangahulugang hindi nakakonekta ang Planka, kaya ihambing 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. Buksan na ang site at mag-log in gamit ang admin account.

Magpatakbo ng pg_dump bago ang bawat pagtaas ng bersyon

Dalawang magkahiwalay na store ang naglalaman ng iyong board, kaya dapat 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, magkakaroon ka ng dump file na mabibigo sa kalagitnaan ng restore. Maaaring lumitaw ang failure makalipas ang ilang linggo, na siyang pinakamasamang posibleng oras.

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 .

Ipinapamahagi rin ng project ang docker-backup.sh at docker-restore.sh sa repository nito, 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 mag-restore ng isa sa scratch VPS at isang beses, at tiyaking makakapag-log in ka at makakapagbukas ng attachment. Lumilitaw ang parehong pares ng store sa bawat Compose app na tumatanggap ng uploads. Kaya kung ilalagay mo sa hinaharap ang Chatwoot sa parehong box ng iyong support desk, magagamit mo ang routine na binuo mo rito nang kaunti lamang ang babaguhin bukod sa volume names.

Patakbuhin ang dump kaagad bago ang bawat pagbabago ng bersyon. Hindi pareho ang backup mula kagabi at ang backup na ginawa bago ang migration na patatakbuhin mo.

I-pin ang mga tag 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. Awtomatikong nagbabago ang latest tuwing may bagong publish ang upstream, kaya maaaring magpatupad 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 inilalarawan doon ang mga breaking change at security fix. Na-publish ang Version 2.0.3 bilang security release. Iyan mismo ang uri ng release na dapat mong basahin sa halip na aksidenteng ma-absorb. Madaling mag-pin dito dahil nagpa-publish ang upstream ng mga image. Kung walang image na inilalabas ang isang project, kailangan mo pa ring sundin ang parehong disiplina at magsagawa ng karagdagang hakbang, gaya ng openGym na bina-build sa server mula sa naka-checkout na git tag.

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 buksan ang directory na isinulat ng ibang major version. Isulat ang postgres:latest, hayaang umabot 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 wala ring maaayos sa pag-restart. Ang paglipat sa bagong Postgres major version ay nangangailangan ng dump mula sa lumang version at restore sa bagong data directory ng bagong version. Planadong trabaho ito habang naka-stop ang stack, hindi side effect ng pag-pull ng image.

Kung ililipat mo ang kasalukuyang Planka 1.x install sa halip na magsimula sa bago, may sarili itong documented procedure sa project documentation, 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 isang beses lang inilalapat ang POSTGRES_PASSWORD kapag unang ini-initialize ang data directory. Kaya walang mababago ang pag-aayos sa variable matapos ang unang boot na may mali. Kailangan mong alisin ang db-data volume at magsimula 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 nabigong request sa /socket.io/.

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 matapos ang 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 galawin ang image tag.

Nagbabalik ng 404 ang Traefik. Wala ang container sa proxy network, o hindi tumutugma ang Host() rule sa iyong DNS record. Ipinapakita ng docker compose config ang mga label matapos ang substitution. Dito makikita 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 kasama sa default block list ang localhost at postgres. Maaaring ma-block ayon sa disenyo ang webhook na nakatuon sa isa pang container sa parehong host. I-adjust ang OUTGOING_ALLOWED_HOSTS sa halip na alisin ang filter.

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

FAQ

Bakit walang tigil sa pag-load ang Planka pagkatapos kong mag-log in?

Tinanggap ang mga credential, pero hindi naitatag 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 ay patakbuhin ang docker compose up -d.

Paano ko gagawin ang unang Planka admin user?

Mula sa 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 mo ring patakbuhin ang 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 napupunta ang password sa container environment na maaaring mabasa ng docker inspect. Kapag nananatiling nakatakda ang DEFAULT_ADMIN_EMAIL, hindi na maaaring baguhin o burahin ang account na iyon mula sa interface.

Saan iniimbak ng Planka ang mga attachment at avatar?

Lahat ng uploaded file ay nasa /app/data sa loob ng container sa Planka 2. Kasama rito ang mga attachment, user avatar, at board background. 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 muling gawin 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 upload 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 madalas makita sa mga hosting page ay default ng provider, hindi resulta ng measurement. Sobra na rin ito para sa maliit na board. Isang Node process at isang Postgres process lamang 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 pagkatapos ng karaniwang linggo, at gamitin ang sarili mong resulta sa pagtakda ng laki ng server. Mas bantayan ang disk kaysa memory dahil mga attachment ang patuloy na lumalaki.

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. Huwag itong iasa sa schedule mula kagabi. 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 ng bawat bersyong nilalaktawan 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 tumatanggi ang server na buksan ang data directory na isinulat ng ibang major version.