Simple chroot management
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Solene Rapenne afd9d6bc2d Mention NFS as a solution 5 months ago
LICENSE Initial commit 5 months ago Mention NFS as a solution 5 months ago


OpenBSD filesystem doesn't allow hard link with directories, this is essential for the thing to work. Until a solution is imagined, it can't be done as designed.

A solution would be to use a local NFS to share directories and mount them anywhere in the file hierarchy, but this would require a lot more work.


pocker is a tool to mimic docker on OpenBSD using chroot. Each step of the Pockerfile create a separate file hierarchy until the last instruction that will be used on the latest incremental version of the hierarchy. Using hard links on the filesystem, it will allow grafting a local directory into the chroot for persistency.


Create a Pockerfile with:

PKG nginx
RUN /etc/rc.d/nginx

Then run using local /var/pocker/volumes/www in the chroot at /var/www/htdocs/:

pocker create nginx
pocker -d /var/pocker/volumes/www/:/var/www/htdocs/ nginx

At the create step in /var/pocker/chroot/nginx/ multiples directories will be created: step1-${line1 checksum} then a rsync from step1-${line1 checksum} will be done into step2-${line2 checksum} and so fort until the last run command creating a last environment still using rsync, allowing to easily clean the pocker enviroment upon restart.

ls /var/pocker/chroot/nginx/
run -> run-0a5f640ed9c98aca444c675f34ef7ee57da0a07d0f20b3565595a42baf2664a4

Pockerfile syntax

  • PROOT: create a chroot using the current system as a model using proot command
  • PKG: will run pkg_add in the chroot
  • RUN: command run when the pocker is started


  • using hard links for each environment step for speed and disk usage efficiency
  • allow exporting / importing chroots
  • allow replacing proot with a list of OpenBSD base sets for a more reproducible environment

Use cases

This is a list of use case I have, and without heavy automation it's complicated to proceed using virtual machines.

  • running an email server in its own chroot with lmtp delivery over TCP, if the environment is compromised it shouldn't be able to escape
  • running a python app from pip that can't be considered fully trusted


Why the name pocker

Because it bluffs about the environment.

Why not docker

Because it's complicated and not easily reproducible on all operating systems.

Why pocker

Because it allows low cost sandboxing without any special requirement.