Cloudron vs CasaOS vs Coolify sa VPS: Alin ang Tama?

Ang ginagawa mo

Mas higit pa sa pag-install ng tool ang pinipili mo rito. May tatlong panel na nangangakong gawing point-and-click app host ang isang bare VPS: Cloudron, CasaOS, at Coolify. Sa gabay na ito, ilalagay ang bawat isa sa parehong bagong Ubuntu 24.04 server, mag-i-install ng unang app, at susuriing mabuti ang mga bahaging kadalasang hindi ipinapakita sa screenshot: TLS, backups, updates, memory cost, at kung gaano kahirap lumipat sa ibang solusyon. Sa dulo, malalaman mo kung alin ang angkop sa iyo, o kung ang tapat na sagot ay "wala sa kanila; Docker Compose na lang ang gamitin."

Wala sa mga ito ang magic solution. Sa ilalim ng tatlo ay ang parehong Docker Engine na maaari mong patakbuhin nang manual. Ang ibinibigay sa iyo ng panel kapalit ng pera, RAM, o lock-in ay ang awtomatikong pag-asikaso sa apat na gawain: one-click app installs, automatic TLS certificates, scheduled backups, at user management. Kung mahalaga sa iyo ang apat na ito at sulit ang dagdag na overhead, kapaki-pakinabang ang panel. Kung isa o dalawang service lang ang pinapatakbo mo at gusto mong alam nang eksakto kung ano ang nasa server mo, basahin muna ang seksyong "Laktawan ang lahat ng tatlo" at iwasan ang dagdag na trabaho.

Mga shared prerequisite at mahahalagang limitasyon

Ipinapalagay ng lahat ng tatlo ang isang KVM VPS, hindi container virtualisation. Kailangan ng Docker ang totoong kernel, at tahasang hindi tinatanggap ng Cloudron ang OpenVZ at LXC. Suriin ito gamit ang systemd-detect-virt: ayos ang kvm o qemu, ngunit hindi ang openvz o lxc. Sa KVM plan, inililimbag ng command ang kvm, at sa bare metal naman ay none; nangangahulugan ang alinman sa mga ito na maaari ka nang magpatuloy.

Bukod dito, magkakaiba ang mga requirement, at ito ang unang dapat maggiya sa iyong pagpili.

• RAM. Maayos na tumatakbo ang CasaOS sa 1GB; ginawa ito para sa Raspberry Pi hardware at nananatiling magaan. Kailangan ng Coolify ng hindi bababa sa 2GB at dalawang CPU core, at humigit-kumulang 600 MB dito ang ginagamit mismo ng Coolify. Kailangan ng Cloudron ng minimum na 2GB at mas maayos itong tumatakbo sa 4GB, dahil nagpapatakbo ito ng mail server at database bago ka pa mag-install ng isang app.
• Domain at DNS na kontrolado mo. Parehong nangangailangan ang Cloudron at Coolify ng totoong domain na gumagana ang DNS. Mas mainam para sa Cloudron ang API access sa iyong DNS provider upang makagawa ito ng mga record at wildcard certificate nang mag-isa. Tatakbo ang CasaOS gamit ang bare IP, ngunit wala kang makukuhang TLS.
• Mga port. Kailangang bukas ang 80 at 443 para sa HTTP at HTTPS. Bukod dito, inihahain ng Coolify ang dashboard nito sa 8000, at ginagamit nito ang 6001 para sa realtime channel at 6002 para sa in-browser terminal. Panatilihing bukas ang port 22 para sa SSH sa lahat ng ito.

I-configure ang DNS upang tumuro sa server bago ka magsimula. Ang panel na hindi ma-resolve ang sarili nitong hostname ay hindi makakahiling ng certificate, at gugugulin mo ang unang oras sa pag-debug nito sa halip na sa software. Magturo ng A record sa server IP, at para sa Coolify, magdagdag ng wildcard record (*.apps.example.com) upang magkaroon ng sariling subdomain ang bawat deployed app.

Cloudron: ang pinong at may takdang paninindigang appliance

Kung ano ito. Ang Cloudron ay isang commercial platform na ginagawang managed appliance ang buong server. May sarili itong reverse proxy, database, at mail stack, pati curated App Store ng mga naka-package na app (Nextcloud, WordPress, Gitea, Mattermost, at iba pa). Para ito sa mga taong gustong managed ang kanilang mga app, na may automatic updates, automatic certificates, at automatic backups, at handang magbayad para rito.

Pag-install. Nangangailangan ito ng malinis na server at ganap nitong inaako ang pamamahala rito. Patakbuhin ito sa bagong Ubuntu 24.04 (Noble) server at wala nang iba:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Ini-install ng script ang Docker, nginx, database, at mail stack, pagkatapos ay nagre-reboot. Kapag bumalik na online ang server, buksan ang https://<your-ip>, tanggapin ang pansamantalang self-signed certificate, at tapusin ang setup sa browser: ituro ito sa iyong domain, piliin ang iyong DNS provider, at ise-set up nito ang sarili nitong dashboard sa my.example.com.

Pagdaragdag ng unang app. Sa dashboard, buksan ang App Store, i-click ang Nextcloud, halimbawa, piliin ang subdomain na files.example.com, at pindutin ang Install. Awtomatikong ginagawa ng Cloudron ang DNS record, humihingi ng Let's Encrypt certificate, nagse-set up ng database, nagko-configure ng single sign-on, at nag-iiskedyul ng backup. Hindi mo kailangang mag-edit ng config file. Ito ang pangunahing halaga ng Cloudron, at naihahatid nito iyon.

TLS at backups. Ito ang pinakamalakas sa tatlo. Awtomatikong binibigyan ng Let's Encrypt certificate ang bawat app subdomain at awtomatiko rin itong nire-renew. Naka-built in at naka-schedule ang backups. Maaari itong gumamit ng local directory, S3, o iba pang remote storage. May per-app restore at one-click cloning din ng app papunta sa bagong subdomain.

Gastos at licensing; basahin ito bago magpasya. Ang Cloudron ay isang paid product na may limitadong free tier: pinapayagan ng free plan ang dalawang app. Kapag nag-install ka ng ikatlong app, makakakita ka ng paywall. Kailangan mo ng paid subscription (Pro o Max, na sinisingil buwanan o taun-taon; parehong unlimited ang apps) para ma-unlock ang higit pang feature. Ito ang pinakamahalagang bagay na dapat malaman tungkol sa Cloudron. Pinong-polido ito dahil isa itong negosyo, at mas kahawig ng pinalawig na trial ang free tier kaysa sa isang platform para sa stack na patuloy na lalaki.

Failure mode, ang tuntunin ng malinis na server. Kapag sinubukan mong i-install ang Cloudron sa server na may tumatakbo nang iba, hihinto ang setup bago ito gumawa ng anumang pagbabago:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

Hindi simpleng pagiging mahigpit ang dahilan nito. Nagfi-fix ang Cloudron ng mga partikular na version ng nginx, Docker, at Node at malalim ang integration nito sa mga iyon. Dahil dito, hindi ito maaaring kasabay ng sarili mong mga kopya. Ang solusyon ay bagong Ubuntu 24.04 image at wala nang iba: walang web server, walang Docker, at kahit firewall na ikaw mismo ang nag-configure. Kung maling image ang na-boot mo, tatanggi rin ang setup sa anumang system na hindi suportadong Ubuntu LTS (22.04 o 24.04) sa x86-64. Hindi talaga suportado ang ARM, LXC, at OpenVZ.

Ikalawang failure mode, nangangailangan ng DNS API ang wildcard certificates. Kung pipiliin mo ang "Manual" DNS option sa setup sa halip na magbigay ng API token sa Cloudron, hindi ito makakagawa ng DNS records o wildcard certificate para sa iyo. Sa bawat bagong app, kailangan mong manu-manong magdagdag ng DNS record bago ma-issue ang certificate, at mananatiling naghihintay ang dashboard sa record na iyon. Bigyan ang Cloudron ng API access sa isang suportadong DNS provider (Cloudflare, Route 53, DigitalOcean, at iba pa), at magiging one-click ang buong proseso.

CasaOS: ang libreng dashboard para sa home lab

Kung ano ito. Ang CasaOS, mula sa IceWhale, ay isang libre at open-source na dashboard na tumatakbo sa ibabaw ng Docker at nagbibigay ng home screen, app store, at file manager. Nagmula ito sa mundo ng home server, kaya nakatuon ito sa home lab: mabilis i-set up, madaling gamitin ang UI, at kaunti ang kinakailangang configuration. Para ito sa mga tinkerer na gustong magkaroon ng mas maayos na interface para sa Docker nang walang kailangang bayaran.

Pag-install. Isang command lang, at hindi nito hinihinging malinis ang server:

curl -fsSL https://get.casaos.io | sudo bash

Nagtatambahkan ang installer ng ilang systemd service (casaos, casaos-gateway, casaos-app-management, at iba pa). Tiyaking gumagana na ang gateway bago magbukas ng browser:

systemctl status casaos-gateway

Kapag tumatakbo na ito, makikita ang dashboard sa http://<your-ip> (plain HTTP, port 80). Gumawa ng local account para makapasok.

Pagdaragdag ng unang app. Buksan ang App Store, pumili ng app, at i-click ang Install. Sa background, gumagawa ang CasaOS ng Docker Compose project at inilalantad ang app sa isang host port, gaya ng http://<your-ip>:8080. Karaniwang mga home-server app ang nasa store nito, kaya ilang click lang ang kailangan para magpatakbo ng Jellyfin media server sa isang VPS o self-hosted na Immich photo library. Kung hindi ka pa nakapipili ng photo server, basahin muna ang RAM requirement at phone app na naghihiwalay sa PhotoPrism at Immich, dahil sa isang 1GB CasaOS box, nakabatay sa pagpiling ito kung tatakbo ang app. Maaari ka ring mag-import ng kahit anong docker-compose.yaml, at dito makikita ang pangunahing bentahe nito: ordinary containers ang mga app, hindi proprietary format.

TLS at backups, ang mahinang bahagi. Dito makikita ang mga limitasyon ng pagiging “free.” Plain HTTP ang default na protocol ng CasaOS para sa lahat ng serbisyo, kabilang ang sarili nitong dashboard. Walang built-in na Let's Encrypt at walang built-in na scheduled backup. Nasa Docker volumes sa ilalim ng /DATA ang data mo, at ikaw ang kailangang mag-back up nito (isang cron'd restic o tar).

Failure mode, walang TLS, at walang malinaw na error. Walang nagfa-fail na command o lumalabas na error. Nag-i-install ka ng app, binubuksan ang http://<your-ip>:8080, at gumagana ito sa unencrypted connection na minamarkahan ng browser bilang "Not Secure." Dumadaan sa network nang cleartext ang mga password at session cookie. Mas malala rito, nagkaroon ang CasaOS ng aktuwal na remote-code-execution vulnerability sa dashboard nito (CVE-2023-37265 at CVE-2023-37266, isang authentication bypass na nauwi sa ganap na pagkompromiso ng host), kaya tunay na panganib ang direktang paglalantad ng HTTP port nito sa internet, hindi lang usapin ng estilo. Ang solusyon ay huwag direktang ilantad ang CasaOS. Maglagay ng reverse proxy sa unahan nito na nagte-terminate ng TLS, gaya ng nginx na may Let's Encrypt certificate mula sa Certbot, Caddy, o Cloudflare Tunnel, at i-forward ang traffic sa CasaOS sa local network lamang. Tandaan na gumagamit na ang CasaOS ng port 80, kaya mag-aagawan dito ang proxy at CasaOS maliban kung ililipat mo muna ang CasaOS sa ibang port.

Gastos. Tunay na libre ito nang walang takdang panahon at walang app limit. Ang kapalit ay operations: ikaw ang responsable sa TLS, backups, at hardening.

Coolify: ang self-hosted PaaS

Kung ano ito. Ang Coolify ay isang open-source, self-hosted platform-as-a-service, na kahawig ng Heroku o Vercel na tumatakbo sa sarili mong server. Ang native unit nito ay hindi “i-install ang packaged app na ito” kundi “i-deploy ang Git repository na ito”: ikonekta ang repo, at bubuuin ito ng Coolify gamit ang Nixpacks o sarili mong Dockerfile, saka ito ide-deploy at awtomatikong ire-redeploy sa bawat push. May one-click databases at services din ito. Target nito ang mga developer na nagde-deploy ng sarili nilang code at gusto ng push-to-deploy nang hindi umuupa ng PaaS.

Pag-install.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Ini-install ng script ang Docker at sinisimulan ang sariling stack ng Coolify na binubuo ng mga container. Tiyaking healthy ang mga ito bago magpatuloy:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Dapat makita mong lahat ng coolify, coolify-db, coolify-redis, coolify-realtime, at coolify-proxy ay nag-uulat ng Up. Nasa http://<your-ip>:8000 ang dashboard. Gawin agad ang admin account, dahil bukas ang registration page hanggang sa magawa ang unang account, at ang unang makakagamit nito ang magkakaroon ng kontrol sa server. Pagkatapos, itakda ang domain ng instance at ituro ang isang wildcard DNS record (*.example.com o *.apps.example.com) sa server upang mabigyan ng Coolify ng sariling subdomain ang bawat deployed app.

Pagdaragdag ng unang app. Ikonekta ang isang Git source (GitHub, GitLab, o plain repo URL), pumili ng branch, itakda ang domain, at mag-deploy. Ang built-in na Traefik proxy ng Coolify ang nagro-route ng subdomain at humihingi ng certificate. Para sa off-the-shelf software, kayang i-deploy ng Services catalogue ang mga ito sa ilang click lamang: isang entry ang parehong n8n workflow-automation stack na maaari mo sanang i-wire up nang mano-mano, at gayundin ang Uptime Kuma para sa status-page monitoring.

TLS at backups. Awtomatikong binibigyan ng Let's Encrypt certificate ang bawat app sa pamamagitan ng bundled Traefik, kaya may certificate ang bawat deployed subdomain. Database-first ang backups: maaari mong i-schedule ang Postgres at MySQL dumps papunta sa S3-compatible storage. Mas mano-mano ang whole-instance backup (ang mismong Coolify configuration, na nasa ilalim ng /data/coolify), kaya ikaw ang mag-export at mag-store nito.

Gastos at licensing. Ang self-hosted edition ay ganap na open-source at libre, at walang limit sa bilang ng app. May optional na Coolify Cloud (may bayad), na nagho-host ng control plane para sa iyo habang tumatakbo pa rin ang mga app sa sarili mong servers. Maginhawa ito pero hindi kinakailangan.

Failure mode: nade-deploy ang app pero hindi naglo-load ang domain nito. Maayos na gumagana ang dashboard sa http://<ip>:8000, successful ang build, pero connection error o Traefik 404 page not found ang ibinabalik ng sariling URL ng app. Ipinapahiwatig nito na nasa proxy o DNS ang problema, hindi sa app. Dalawa ang karaniwang sanhi. Una, ginagamit na ang port 80 o 443 nang subukang magsimula ang proxy, kaya namatay ang container nito na may Docker error:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Ikalawa, nawawala ang wildcard DNS record, kaya hindi nakakatanggap ang Traefik ng request para sa hostname na iyon. Kung sa halip ay "Server is not reachable" ang nakalagay sa buong server card sa Coolify, ibang problema iyon: hindi talaga makakonekta ang Coolify sa Docker socket ng server, karaniwang dahil nakahinto ang Docker daemon o may sira ang SSH key. Basahin muna ang aktuwal na dahilan sa logs bago maghula:

docker logs coolify-proxy --tail 100

Ayusin ito mula sa Proxy page: pindutin ang Restart Proxy, o i-reset sa default ang proxy configuration at simulan itong muli, pagkatapos ay maghintay nang humigit-kumulang dalawang minuto para maging stable ito. Panatilihing reachable ang port 8000 mula lamang sa sarili mong IP (o pansamantalang buksan muli kapag may problema ang proxy) sa halip na iwan itong bukas sa lahat, dahil inihahatid nito ang dashboard gamit ang plain HTTP. Ayon din sa sariling documentation ng Coolify, maaaring isara ang ports 8000, 6001, at 6002 kapag naihahatid na ang dashboard sa sarili nitong domain.

Overhead sa resource sa parehong VPS

Sinukat ito habang idle sa parehong 4GB box, bago mag-deploy ng anumang aktuwal na workload. Suriin ang sarili mong server gamit ang free -m at docker stats --no-stream sa halip na umasa sa iisang numero, dahil nagbabago ang kabuuang paggamit batay sa mga app na pinapatakbo mo.

• CasaOS ang pinakamagaan. Maliit na set ng Go services ang panel; asahan ang humigit-kumulang 150 hanggang 300 MB na overhead bukod sa paggamit ng mga container na pinapatakbo mo.
• Coolify ay nagpapatakbo ng ilang support container nito mismo (ang app, isang Postgres, isang Redis, isang realtime service, at Traefik), kaya nasa humigit-kumulang 600 MB hanggang 1 GB ito habang idle bago ka mag-deploy ng anuman.
• Cloudron ang may pinakamalaking resource usage habang idle, dahil sarili nitong nginx, database, mail stack, at monitoring ang pinapatakbo nito ginagamit mo man ang mga ito o hindi; maglaan ng 1 hanggang 1.5 GB habang idle. Kaya nangangailangan ito ng minimum na 2GB at mas maayos itong tumatakbo sa 4GB.

Sa maliit na 2GB VPS, CasaOS ang nag-iiwan ng pinakamaraming puwang para sa mga aktuwal na app, habang Cloudron ang nag-iiwan ng pinakamaliit. Kung 2GB ang plano mo at gusto mong patakbuhin ang Cloudron kasama ang mail server nito, magplano kang mag-upgrade ng box.

Mga update, backup, at lock-in kumpara

Mga update. Ina-update ng Cloudron ang platform at bawat app para sa iyo ayon sa iskedyul na nasubukan na nito: pinakamaliit ang kailangang gawin at pinakamarami ang gabay. Ina-update ng Coolify ang sarili nito mula sa dashboard nito gamit ang isang button. Ina-update ng CasaOS ang panel sa pamamagitan ng install script nito o apt, pero ikaw ang kailangang kumuha ng mga update at mag-restart ng mga app na na-install mo.

Lock-in, ang problemang lumilitaw pagsapit ng ikalawang taon. Pinakamaliit ang lock-in sa CasaOS: ordinaryong Compose project ang mga app nito, kaya maaari mong kopyahin ang docker-compose.yaml at ang mga volume sa ilalim ng /DATA papunta sa ibang host at ipagpatuloy ang paggamit. Nasa gitna ang Coolify: sarili mong Dockerfile at repository ang ginagamit ng mga deployment mo, pero nasa database ng Coolify ang configuration ng mga ito, kaya kailangang muling likhain ang mga project sa bagong host. Pinakamalaki ang lock-in sa Cloudron: Cloudron-packaged ang mga app nito. Bagama't maayos na naililipat ang iyong data gamit ang mahusay nitong mga backup, hindi naililipat ang packaging, kaya kailangan mong muling i-deploy ang mga ito sa destination platform. Portable ang data, pero hindi portable ang plumbing.

Alin ang dapat mong piliin

Maikling sagot, kasunod ang alternatibo. Piliin ang Cloudron kung gusto mo ng server na nangangailangan ng pinakamaliit na hands-on na maintenance sa tatlo, magpapatakbo ka ng ilang packaged app, at handa kang magbayad ng taunang fee para sa managed TLS, backups, at updates. Piliin ang CasaOS kung home lab ito sa likod ng sarili mong network o reverse proxy, gusto mo ng mas madaling gamitin na interface para sa Docker, at ayaw mong magbayad. Piliin ang Coolify kung nagde-deploy ka ng sarili mong code mula sa Git at gusto mo ng push-to-deploy na may automatic TLS, nang hindi nagbabayad ng halaga ng hosted PaaS. Kung wala sa tatlong ito ang naglalarawan sa sitwasyon mo, ang susunod na seksyon ang tapat na sagot.

Laktawan ang tatlo kung...

Maging makatotohanan sa laki ng setup mo. Kung isa o dalawang app lang ang pinapatakbo mo, o gusto mong eksaktong malaman at kontrolin kung ano ang nasa server mo, laktawan ang mga panel. Hindi sulit para sa maliit at stable na stack ang overhead at vendor lock-in. Ang DIY na paraan ay isang reverse proxy sa harap ng sarili mong Compose files: sa Traefik na may automatic TLS sa harap ng ilang Docker Compose app, makukuha mo ang HTTPS na katumbas ng one-click setup nang walang bigat ng panel, at magba-backup ka gamit ang cron'd na restic job na nauunawaan mo talaga.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Para sa isang pangunahing app, mas malinaw pa ang dahilan: ang Nextcloud install sa Docker na may TLS at sariling backup routine ay isang Compose file at isang certificate. Kung magse-set up ka ng buong appliance para lang patakbuhin ito, gastos lang iyon at walang pakinabang. Kung nagpapasya ka pa rin kung ano ang patatakbuhin bago mo piliin kung paano, mas magandang panimulang punto ang gabay sa mga sulit i-self-host sa 2026.

FAQ

Kailangan ko ba talaga ng self-hosting panel?

Kailangan lamang kung mahalaga sa iyo ang apat na bagay na ina-automate ng panel para sa ilang app: one-click installs, automatic TLS, scheduled backups, at user management. Para sa isa o dalawang serbisyo, sapat na ang plain Docker Compose sa likod ng Traefik para sa parehong TLS function, ngunit mas kaunti ang overhead at walang lock-in. Sulit ang mga panel kapag marami kang pinapatakbong app at mas mahalaga ang oras mo kaysa sa RAM na ginagamit ng mga ito.

Aling panel ang pinakamainam para sa beginner?

Para sa home lab na walang inilalantad sa mapanganib na internet, pinakamadaling simulan ang CasaOS: isang command at may friendly na UI, nang walang kailangang bayaran. Ngunit kailangan mong maglagay muna ng TLS-terminating reverse proxy sa harap nito bago maglantad ng anuman, dahil plain HTTP ang ginagamit nito. Kung gusto mong ang managed TLS at backups ay asikasuhin para sa iyo at handa kang magbayad, ang Cloudron ang pinakamaraming gabay, sa loob ng limitasyong dalawang app sa libreng tier nito.

Libre ba ang Cloudron?

Bahagya lamang. Pinapayagan ng libreng tier ang dalawang app, na sapat para subukan ito o para sa napakaliit na setup. Higit dito, paid subscription ang Cloudron na sinisingil buwanan o taun-taon, at unlimited apps ang mga paid tier. Commercial product ito na may limitadong free plan, hindi free software, kaya isama ito sa budget kung lalaki ang stack mo.

Maaari ko bang patakbuhin ang mga panel na ito kasabay ng mga dati ko nang app?

Cloudron: hindi. Nangangailangan ito ng malinis na Ubuntu box at nag-a-abort kung naka-install na ang nginx, Docker, o Node, dahil pinamamahalaan nito ang buong machine. Mas compatible ang CasaOS at Coolify, dahil nag-i-install sila ng sarili nilang Docker stack at puwedeng magsalo sa isang box sa prinsipyo, ngunit kailangan ng dalawang ito ang ports 80 at 443, kaya nagkakaroon ng conflict sa anumang web server o proxy na pinapatakbo mo na. Kung may mga naka-host na sa box, kadalasang maling tool ang panel; gamitin na lang ang Traefik at Compose.

Paano ako aalis sa paggamit ng panel sa hinaharap?

Planuhin ang paglipat bago ito kailanganin. Mula sa CasaOS, kopyahin ang docker-compose.yaml ng app at ang mga /DATA volume nito sa bagong host, pagkatapos ay simulan muli ang mga ito. Mula sa Coolify, i-export ang configuration ng bawat project at ituro ito sa parehong repos sa destination. Mula sa Cloudron, i-restore ang data mula sa backups nito papunta sa mga bagong install na app sa bagong platform, dahil hindi naililipat ang Cloudron packaging; ang data lamang ang naililipat. Sa lahat ng sitwasyon, subukan muna ang restore sa isang throwaway box bago mo i-decommission ang lumang box.