Podman vs Docker di VPS: Apa Bedanya?

Perbedaan sebenarnya antara Podman dan Docker

Podman dan Docker menjalankan image OCI (open container initiative) yang sama pada VPS, jadi pilihannya bukan tentang software mana yang dapat Anda jalankan. Perbedaannya terletak pada model proses. Docker menjalankan daemon root yang mengelola setiap container, sedangkan perintah docker adalah client kecil yang meminta daemon tersebut menjalankan tugas. Podman tidak memiliki daemon: podman run menjalankan container sebagai proses anak dari proses yang memanggilnya, menggunakan user Anda sendiri yang tidak memiliki hak istimewa.

Hal lain mengikuti fakta tersebut. Auto-start menjadi tugas systemd, bukan daemon. Kepemilikan volume diteruskan melalui user namespace, sehingga owner yang Anda lihat dengan ls -l pada host bukanlah owner yang dilihat container. Port di bawah 1024 menolak bind hingga Anda mengubah pengaturan kernel. CLI (command line interface) docker tetap berfungsi melalui wrapper, sampai ada komponen yang memerlukan Docker socket.

Tidak ada daemon: proses yang sebenarnya berjalan saat Anda memulai container

Pada host Docker, pstree -a menampilkan dockerd sebagai root, containerd di sebelahnya, dan satu containerd-shim-runc-v2 untuk setiap container yang sedang berjalan. Aplikasi Anda merupakan child dari shim tersebut, sedangkan shim merupakan child dari PID 1. Tidak ada proses yang menghubungkan container dengan shell yang memulainya. Hentikan daemon, dan Anda kehilangan control plane untuk semua container pada host tersebut. Jika pengaturan default live-restore dinonaktifkan, systemctl restart docker juga me-restart container Anda.

Podman tidak memiliki proses yang setara. Jalankan sebuah container, dan Anda mendapatkan satu proses conmon (monitor container) yang menampung proses utama container. Proses ini dimiliki oleh user yang menjalankan perintah.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps seharusnya menampilkan conmon yang berjalan sebagai user login Anda, bukan sebagai root, dan curl seharusnya mencetak 200. Karena tidak ada service terpusat yang memiliki container tersebut, sudo apt upgrade podman tidak menghentikan apa pun yang sudah berjalan. Jika monitor salah satu container mengalami crash, container lain tidak ikut berhenti.

Tidak adanya daemon juga menimbulkan konsekuensi. Tidak ada yang memulai container Anda setelah reboot. --restart=always milik Docker merupakan janji yang dipenuhi daemon saat boot. Podman menggantinya dengan systemd. Itulah fungsi bagian quadlet di bawah ini.

Socket merupakan bagian lain dari mekanisme ini. /var/run/docker.sock adalah endpoint API (application programming interface) yang dimiliki root. Setiap proses yang dapat menulis ke socket tersebut dapat memulai container dengan hak istimewa yang memasang filesystem host. Menambahkan user ke grup docker memberikan akses root kepada user tersebut melalui jalur yang lebih tidak langsung. Hal ini perlu dibaca bersama memberikan setiap akun service hanya akses yang dibutuhkannya. Podman tidak menyediakan socket kecuali Anda memintanya, dan socket yang diperoleh dimiliki oleh satu user pada /run/user/<uid>/podman/podman.sock.

Instal Podman di Ubuntu 24.04 dan pastikan mode rootless benar-benar aktif

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

Paket uidmap menyediakan newuidmap dan newgidmap. Keduanya adalah helper setuid yang memungkinkan pengguna biasa menggunakan rentang ID subordinat. Tanpa helper tersebut, container rootless tidak dapat berjalan. podman info harus menampilkan rootless: true.

Ubuntu 24.04 menyediakan Podman 4.9, sedangkan Debian 13 menyediakan Podman 5.x, berdasarkan pemeriksaan pada Agustus 2026. Perbedaan ini penting karena file quadlet memerlukan versi 4.4 atau yang lebih baru, sedangkan file quadlet .pod memerlukan versi 5.0. Jalankan podman --version sebelum menyalin contoh dari dokumentasi upstream.

Setiap pengguna rootless memerlukan rentang ID subordinat:

grep "$USER" /etc/subuid /etc/subgid

Pengguna yang dibuat dengan adduser di Ubuntu otomatis mendapatkan rentang tersebut. Pengguna yang dibuat dengan useradd -M atau dengan alat konfigurasi sering kali tidak mendapatkannya, dan kegagalannya akan menunjukkan hal tersebut:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Tetapkan rentang, lalu reset storage pengguna tersebut agar pemetaan baru digunakan:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

Ada satu kejutan lain saat pertama kali digunakan: Podman tidak mengasumsikan Docker Hub. Nama image singkat akan dicari pada unqualified-search-registries di /etc/containers/registries.conf. Dalam skrip tanpa terminal terhubung, proses pull gagal dengan short-name resolution enforced but cannot prompt without a TTY. Selalu tulis nama lengkap. Gunakan docker.io/library/nginx:1.27, bukan nginx.

Manfaat nyata container rootless pada server sewaan

Container rootless berjalan di dalam namespace pengguna, yaitu fitur kernel yang memberi suatu proses peta ID pengguna privat. Di dalam namespace tersebut, superuser container adalah UID (user ID) 0. Di luarnya, pada VPS Anda, proses yang sama adalah user login biasa Anda. root di dalam container bukan root pada host.

Itulah skala manfaat yang sebenarnya. Image yang mengharuskan proses berjalan sebagai root, aplikasi web dengan bug remote code execution, atau escape yang bergantung pada UID 0 di luar container, semuanya hanya akan memiliki permission user Anda yang tidak memiliki hak istimewa, bukan permission seluruh mesin. Rootless tidak melindungi Anda dari bug kernel. Rootless juga tidak melindungi file Anda sendiri, karena proses yang berhasil keluar dari container berjalan sebagai Anda dan dapat membaca semua hal yang dapat Anda baca.

Docker juga dapat berjalan secara rootless. dockerd-rootless-setuptool.sh install menyiapkan daemon per user dan berfungsi dengan baik. Perbedaannya adalah arah default masing-masing. Dengan Podman, Anda langsung mendapatkan rootless tanpa konfigurasi tambahan. Karena itu, kegagalan pertama yang Anda temui adalah container yang tidak dapat melakukan bind ke port 80, bukan service yang diam-diam berjalan sebagai root selama dua tahun.

Mengapa file volume saya dimiliki oleh UID 100999?

Penyebabnya adalah user namespace yang sama. UID 0 di dalam container dipetakan ke UID Anda di host. UID 1 di dalam container dipetakan ke ID pertama dalam rentang subuid Anda, lalu nilainya bertambah secara berurutan. Jika rentang dimulai dari 100000, UID 1000 di dalam container dipetakan menjadi 100999 di host.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container menampilkan 1000. Daftar di host menampilkan pemilik 100999, karena 100000 ditambah 1000 dikurangi 1 sama dengan 100999. Tidak ada yang rusak. Perintah chown biasa juga tidak akan memperbaikinya, karena user tanpa hak istimewa tidak dapat mengubah kepemilikan file di luar namespace sama sekali.

Ada empat cara untuk mengatasinya:

• podman unshare chown 1000:1000 "$PWD/data" menjalankan chown di dalam user namespace yang sama, sehingga angka tersebut memiliki arti yang sesuai bagi container.
• -v "$PWD/data:/data:U" meminta Podman memperbaiki kepemilikan direktori sumber untuk Anda. Gunakan pada direktori baru, bukan pada data yang penting.
• --userns=keep-id memetakan UID host Anda ke UID yang sama di dalam container, sehingga file baru dimiliki oleh Anda.
• Named volume seperti -v appdata:/data menghindari masalah ini, karena Podman membuatnya di dalam storage Anda sendiri dengan kepemilikan yang sudah benar.

Jika Anda pernah mengalami masalah ini di Docker, masalahnya sama, tetapi terjadi satu lapisan lebih tinggi. Variabel PUID dan PGID yang disediakan banyak image menetapkan UID yang digunakan proses di dalam container. Pada rootless Podman, UID tersebut kemudian dipetakan sekali lagi. PUID=1000 di dalam container rootless tetap menulis file di host dengan kepemilikan 100999. Tentukan angkanya dengan memperhitungkan pemetaan kedua tersebut, atau pindahkan data ke named volume dan tidak perlu memikirkannya lagi.

Ada dua hal lain tentang mount. Flag :z dan :Z yang terlihat pada contoh Fedora dan RHEL adalah opsi relabel SELinux. Ubuntu menggunakan AppArmor, sehingga flag tersebut tidak melakukan apa-apa di sana. Rootless Podman juga tidak dapat me-mount direktori host yang tidak dapat dibaca oleh user Anda. Pembatasan ini memang diperlukan, bukan merupakan kerusakan.

Mengapa rootless Podman menolak memublikasikan port 80?

Karena pengikatan port di bawah 1024 memerlukan hak istimewa yang tidak dimiliki user Anda. Pesan error menyebutkan perbaikannya:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

Ada dua solusi yang dapat digunakan. Turunkan ambang batas untuk seluruh host:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Perintah terakhir harus menampilkan 80. Pahami dampak pengaturan tersebut: setiap user di mesin kini dapat mengikat port 80 dan 443, bukan hanya user yang menjalankan container. Pada VPS dengan satu administrator, kompromi ini dapat diterima. Pada mesin yang digunakan oleh akun milik orang lain, pengaturan ini tidak tepat. Solusi lainnya adalah memublikasikan layanan pada port 8080 lalu menempatkan reverse proxy di depannya. Di situlah Anda memang ingin sertifikat diterbitkan dan diperbarui oleh certbot pada nginx.

Publikasi rootless juga mengubah informasi yang dilihat aplikasi Anda. Podman 4.x secara default menggunakan slirp4netns dengan handler port rootlesskit. Koneksi yang diteruskan tiba dengan alamat sumber yang telah diubah, sehingga access log mencatat setiap pengunjung sebagai 10.0.2.100. Podman 5.0 mengubah default menjadi pasta. Pengaturan ini mempertahankan alamat client yang sebenarnya. Pada 4.x, --network slirp4netns:port_handler=slirp4netns mengembalikan alamat sumber yang sebenarnya, tetapi dapat mengurangi throughput.

Ada satu hal yang menguntungkan. Port yang dipublikasikan secara rootless adalah listening socket biasa yang dimiliki proses normal. Karena itu, aturan input pada firewall Anda berlaku untuk port tersebut. Docker memublikasikan port dengan menulis aturan NAT (network address translation) dan aturan accept forwarding miliknya sendiri. Inilah alasan port Docker yang dipublikasikan mengabaikan aturan ufw yang Anda kira memblokirnya. Podman rootful menggunakan mekanisme serupa dan memiliki masalah yang sama. Rootless tidak.

Apakah file Docker Compose saya tetap berfungsi di Podman?

Umumnya, melalui dua cara. Cara pertama adalah podman-compose, implementasi terpisah yang membaca file yang sama dan menjalankan Podman CLI:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

Cara kedua adalah Docker Compose yang sebenarnya, yang berkomunikasi dengan API Docker-compatible milik Podman melalui socket per pengguna:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps dan podman ps seharusnya menampilkan container yang sama karena hanya ada satu kumpulan container. Resolusi nama juga berfungsi. Backend jaringan default Podman, yaitu netavark, menjalankan aardvark-dns sehingga container pada jaringan yang ditentukan pengguna dapat menemukan satu sama lain berdasarkan nama.

Keterbatasannya nyata. Apa pun yang me-mount /var/run/docker.sock harus diarahkan ke socket Podman atau dihapus. network_mode: host berperilaku berbeda dalam user namespace. Dukungan depends_on dengan condition: service_healthy tidak konsisten di berbagai versi podman-compose. restart: always tidak bertahan setelah reboot secara otomatis. Bagian berikutnya memperbaikinya. Compose tetap merupakan cara yang baik untuk menjelaskan stack multi-container dalam satu file, dan di Podman, Compose berfungsi sebagai lapisan translasi. Untuk stack yang akan dipertahankan selama bertahun-tahun, konversikan ke quadlet dan kelola satu abstraksi, bukan dua.

Pod: konsep yang tidak dapat dijawab oleh Docker

Pod adalah sekelompok container yang berbagi satu namespace jaringan. Podman menjalankan container kecil infra untuk mempertahankan namespace tersebut, lalu semua anggotanya dapat saling terhubung melalui 127.0.0.1 tanpa jaringan yang ditentukan pengguna dan tanpa mekanisme service discovery.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps akan menampilkan pod Running dengan tiga container, termasuk container infra. Container web sekarang terhubung ke Redis melalui 127.0.0.1:6379, bukan app-cache:6379. Ada dua aturan yang berlaku untuk namespace bersama: publikasikan port pada pod, bukan pada anggotanya, dan tidak boleh ada dua anggota yang mendengarkan pada port yang sama.

Ini adalah model Kubernetes, dan Podman mengadopsinya secara langsung. podman kube generate app > app.yaml menulis manifest Kubernetes dari kondisi yang sedang berjalan (pada paket lama, perintah ini ditulis sebagai podman generate kube), sedangkan podman kube play app.yaml membuatnya kembali pada host lain. Quadlet memiliki tipe unit .kube yang menjalankan file tersebut sebagai service systemd. Ini adalah cara yang benar-benar berbeda untuk mengelompokkan service, dan merupakan alasan terkuat untuk memilih Podman jika Kubernetes termasuk dalam rencana Anda.

Mulai otomatis tanpa daemon: unit quadlet

Quadlet adalah generator systemd. Quadlet mengubah file singkat yang menjelaskan sebuah container menjadi service systemd nyata saat boot. Letakkan file di ~/.config/containers/systemd/ untuk pengguna rootless, atau di /etc/containers/systemd/ untuk root.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume dapat hampir kosong karena header bagian tersebut yang membuat volume:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Nama service berasal dari nama file: caddy.container menjadi caddy.service. Jangan jalankan systemctl --user enable caddy. Unit yang dihasilkan tidak dapat diaktifkan, dan systemd menjawab Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. Bagian [Install] yang memulai container saat boot, sedangkan daemon-reload membuat ulang unit setelah Anda mengedit file.

Sekarang, pengaturan yang sering terlewat:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Perkirakan Linger=yes. Tanpa linger, systemd membongkar seluruh sesi pengguna ketika koneksi SSH terakhir Anda ditutup. Akibatnya, semua container rootless ikut berhenti dan tidak ada yang kembali berjalan saat boot. Container yang menghilang saat Anda logout selalu disebabkan oleh hal ini.

Karena container merupakan proses utama dari unit service biasa, kontrol systemd sendiri berlaku secara langsung. MemoryMax= dan CPUQuota= di bagian [Service] berfungsi sama persis seperti pada service lain yang Anda batasi dengan systemd. Fitur ini memerlukan cgroup v2 (control group version 2), yang telah digunakan Ubuntu secara default sejak 22.04. Konfirmasikan dengan podman info | grep -i cgroup.

Pembaruan memiliki mekanisme yang sesuai. AutoUpdate=registry bersama systemctl --user enable --now podman-auto-update.timer memeriksa registry untuk mencari image yang lebih baru dengan tag yang sama, me-restart unit, lalu melakukan rollback ke image sebelumnya jika container baru gagal start. Jalankan podman auto-update --dry-run terlebih dahulu untuk melihat perubahan yang akan diterapkan. Perintah podman generate systemd yang lebih lama masih tersedia dan sudah deprecated, jadi gunakan quadlet untuk semua konfigurasi baru.

Di mana alias docker berlaku dan di mana alias tersebut tidak berlaku

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker memasang wrapper /usr/bin/docker yang memanggil Podman. Tanpa file nodocker, setiap pemanggilan terlebih dahulu menampilkan Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. Wrapper tersebut mencakup perintah yang Anda gunakan setiap hari: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Hal yang tidak dapat dialihkan jumlahnya lebih sedikit, tetapi dampaknya lebih besar. Swarm mode tidak memiliki padanan, sehingga stack Swarm tidak memiliki tempat untuk dijalankan. Tool yang berkomunikasi dengan Docker socket memerlukan Podman socket untuk diekspor, dan beberapa tool tetap dapat mendeteksi perbedaannya; Docker provider milik Traefik berfungsi jika diarahkan ke /run/user/<uid>/podman/podman.sock, sedangkan Watchtower sama sekali tidak memiliki peran karena podman auto-update yang menangani tugas tersebut. Penyimpanannya terpisah, sehingga Podman tidak dapat melihat image yang sebelumnya Anda pull dengan Docker, dan podman images pada host Docker yang sibuk awalnya kosong.

Migrasi stack yang sedang berjalan, langkah demi langkah

1. Buat atau pilih user tanpa hak istimewa yang akan memiliki container, lalu pastikan user tersebut memiliki rentang pada /etc/subuid.
2. Pull ulang semua image yang berasal dari registry menggunakan nama yang sepenuhnya memenuhi syarat. Podman memiliki penyimpanan image sendiri dan tidak akan membaca penyimpanan Docker.
3. Pindahkan image yang dibuat secara lokal menggunakan docker save app:1.4 | podman load.
4. Hentikan container Docker, salin isi setiap volume dari /var/lib/docker/volumes/<name>/_data, lalu perbaiki kepemilikannya dengan podman unshare chown -R 1000:1000 <path>.
5. Tentukan konfigurasi port: publikasikan port di atas 1024 di belakang reverse proxy, atau atur net.ipv4.ip_unprivileged_port_start.
6. Tulis satu file quadlet untuk setiap container, jalankan systemctl --user daemon-reload, lalu start setiap service.
7. Jalankan sudo loginctl enable-linger <user>, reboot VPS, login kembali, lalu periksa bahwa podman ps kembali mencantumkan setiap service.

Kedua engine tidak berbagi apa pun: penyimpanan image dan network terpisah. Karena itu, keduanya dapat dijalankan selama proses migrasi. Satu-satunya hal yang dapat diperebutkan adalah nomor port pada host. Pindahkan satu service, monitor selama satu hari, lalu pindahkan service berikutnya.

Podman vs Docker: mana yang sebaiknya digunakan di VPS Anda?

Tetap gunakan Docker jika stack Anda berada dalam file compose yang juga dikelola oleh orang lain, atau jika Anda bergantung pada tooling yang berkomunikasi dengan Docker socket. Kompatibilitas dengan konfigurasi yang digunakan orang lain merupakan fitur penting, dan Docker memiliki kompatibilitas yang lebih luas. Tim yang seluruh laptopnya menjalankan Docker juga memperoleh manfaat nyata dengan menjalankan engine yang sama di production.

Beralih ke Podman jika VPS menjalankan beberapa service yang Anda kendalikan sepenuhnya, atau jika Anda ingin setiap aplikasi berjalan di bawah user tanpa hak istimewa masing-masing, tanpa docker group sama sekali pada sistem. Kesesuaian dengan distribusi juga penting: RHEL dan turunannya merilis Podman sebagai engine yang didukung, sehingga pada sistem tersebut Podman merupakan pilihan dengan lebih sedikit kejutan. Jika Anda sudah mengelola semua komponen lain dengan unit systemd, quadlet akan terasa seperti bagian yang sebelumnya hilang, bukan tool baru yang harus dipelajari.

Ada satu opsi di tengah yang perlu disebutkan. Podman rootful berperilaku seperti Docker, mempertahankan command docker melalui wrapper, dan tetap menghilangkan daemon yang selalu berjalan. Opsi ini juga menghilangkan bagian rootless, yaitu aspek yang mengubah posisi keamanan Anda, sehingga perlakukan ini sebagai tahap peralihan.

Jika Anda masih membangun host container pertama, panduan setup dan hardening Docker pada VPS baru merupakan jalur yang lebih singkat, dan tidak ada pengetahuan dari proses tersebut yang terbuang. Image dan volume merupakan objek yang sama pada kedua engine, sehingga perpindahan nantinya hanya mengubah cara service Anda dikelola dan hampir tidak mengubah hal lainnya.

FAQ

Apakah Podman merupakan pengganti Docker yang dapat langsung digunakan?

Untuk perintah yang Anda ketik, hampir demikian. Menginstal podman-docker menyediakan wrapper /usr/bin/docker, dan run, ps, build, logs, serta exec berperilaku sama. Podman bukan pengganti daemon. Swarm tidak memiliki padanan, sehingga alat yang terhubung ke /var/run/docker.sock harus diarahkan ke socket Podman per pengguna. Image yang ditarik oleh Docker tetap tidak terlihat oleh Podman karena keduanya menggunakan penyimpanan terpisah.

Mengapa container Podman rootless saya berhenti saat saya keluar dari SSH?

Karena systemd menghentikan sesi pengguna, termasuk semua service pengguna, saat login terakhir Anda ditutup. Jalankan sudo loginctl enable-linger <user>, lalu pastikan loginctl show-user <user> --property=Linger menampilkan Linger=yes. Linger mempertahankan instance systemd pengguna tersebut tetap berjalan tanpa sesi aktif. Hal ini juga membuat container berjalan kembali setelah reboot.

Mengapa file dalam volume saya dimiliki oleh UID 100999?

Podman rootless memetakan UID container 0 ke pengguna host Anda, kemudian memetakan UID container 1 dan seterusnya ke rentang subuid Anda. Dengan rentang yang dimulai dari 100000, UID container 1000 menjadi 100999 pada host. Perbaiki kepemilikannya dari dalam namespace dengan podman unshare chown 1000:1000 /path/to/data, gunakan flag :U saat melakukan mount pada proses pertama, atau gunakan --userns=keep-id agar UID container sama dengan UID Anda.

Apakah saya dapat tetap menggunakan docker-compose.yml dengan Podman?

Ya, dengan dua cara. podman-compose membaca file tersebut dan mengendalikan Podman CLI secara langsung. Anda juga dapat mengaktifkan socket kompatibilitas dengan systemctl --user enable --now podman.socket, menetapkan DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, lalu menjalankan docker compose yang sebenarnya terhadap socket tersebut. Masalah kompatibilitas dapat terjadi pada network_mode: host, pada service yang melakukan mount terhadap Docker socket, serta pada restart: always, yang memerlukan unit quadlet dan linger agar tetap berjalan setelah reboot.

Apakah rootless benar-benar membuat container lebih aman?

Rootless menghilangkan satu risiko tertentu: proses yang keluar dari container rootless hanya memiliki izin pengguna nonprivileged Anda, bukan izin root. Hal ini penting. Karena itu, grup docker yang setara dengan root tidak memiliki padanan pada Podman rootless. Rootless tidak mencegah kerentanan kernel dan tidak melindungi file yang dapat dibaca oleh pengguna Anda sendiri. Jadi, tetap terapkan hardening lain yang akan Anda gunakan pada server mana pun.