◜PFC◞Pain Free Containers

An agnostic container engine toolset — successor to DOCK
runs on:
works with:

Docker, Podman, FreeBSD jails, hypervisors & cloud APIs.

PFC-specific terms

Images, containers & PFC-instances difference

Those who had used Docker are, of course aware that an image, generally speaking, is an entity FROM which multiple containers can be created. A container itself is like a very light-weight virtual machine, an operating system within an operating system, isolated and with its own software installed.

A PFC-instance is simply a container that's PFC-comptabible. It doesn't take much to be that but a container must have something in it, so that PFC can successfully work with it. It's explained below in more detail.


This is the machine from which you start your container. It is usually the same as Docker-host, or Podman-host, or FreeBSD-jails, etc. It is usually (but not always) your top-level operating system.

Unsurprisingly, this a PFC-guest is simply a running container of whichever kind, which runs on the PFC-host.
This term is equivalent to the term container, except for the fact that it's a shorthand for PFC-compatible container
◜PFC◞ works as thin layer between you and your container-engine, or VM, or cloud-API of choice. So then, the term PFC-backend be used to call one of those of those things — whichever one you happen to be using via ◜PFC◞ at the moment.
PFC-compatible images or containers
This may vary depending on the version of PFC being used and may change a little bit in the future, albeit always attempting to remain backwards-compatible. First thing a PFC-compatible container would need is an sshd-daemon running and an ssh public-key imported from the host (it generates a new pair). There are a few other tweaks, which you'll be able to easily see when you browse the PFC-compatibility recipes repository. No secrets there.

This is a very special thing for ◜PFC◞: these are little scripts, we call recipes very much like database migrations, except applied to containers or instances. In fact, it's the very same tool ◜PFC◞ would make use of on any container you point it to, in order to make it PFC-compatible. Then, you may write your own recipes in any language of your choice and make PFC apply them for your, consecutively and with care.

Please read more about recipes feature in the relevant section of our the recipes feature in the relevant section of our FEATURES page.

Container-related terms

Container engines

This is a specialized type of software such as Docker, Podman, or FreeBSD-jails, which acts as a light-weight virtual machine. ◜PFC◞ can handle any of those using the same interface for the end user.

Some containers-engines have so called images — a term we already described above, while others lack such a concept. Specifically, FreeBSD-jails doesn't have them, but ◜PFC◞ makes up for it providing this functionality to it for free.

Versions and Tags

Various engines may have different terminology. ◜PFC◞ unifies that terminology under the following convention (which is very similar to Docker, but differs from it in some very few important ways. Here's what a PFC-image may be named: local/node/0.1.2.

It's very similar, but yet under the hood the meaning is different here: [NAMESPACE]/[NAME]/[VERSION]. In ◜PFC◞ you can also assign tags and those can be arbitrary and serve be assigned to various images.

This, however, actually makes things very simple when creating an image. A simple combination of namespace+tag may invoke just the image you desire to use: pfc local:node

Alternatively, you can use not a namespace, but a name such that pfc node14.1:latest — in both cases, the combination MUST BE unique in order to work, but it does simplify things greatly — it's very unlikely you'd be so unwise as to have conflicting names & tags all mixed up (if you are — you won't get in trouble, but simply be offered a choice).

Virtual machines terms

Virtual Machine

This term represents an equivalent of a container, except it's a heavier and more isolated "container". Typically, containers can only run the same operating system that they're hosted on. Docker, for instance, was only able to run on Linux for a long time before they were able to figure out how to make it work on Windows and Mac (actually, Windows somewhat figured it out for them).

On the other hand, a Virtual Machine represents a heavier container running any OS under any other OS. Provided that our "host" operating system has a hypervisor (next term in this glossary).


It's a piece of software that is capable of running virtual machines. Some are better than others under various circumstances. Some are native and can only run on certain OS acting as their hosts (but run any OS as a guest, of course): KVM/QEMU, bhyve. Others are very much cross-platform, such as VirtualBox.

For its own purposes or when needed or requested by user themselves, ◜PFC◞ will automatically run a container with an operating system inside in one of the hypervisors available on the user's host system. No manual handling or configuration will be necessary whatsoever.

Technologies & jargon


Bash is a command processor that typically runs in a text window where the user types commands that cause actions. Bash can also read and execute commands from a file, called a shell script. (source: Wikipedia).

The advantage of Bash is that it is available on almost any OS3, including Windows (without any need to install it first) and, this, is an ideal language to write something that's by design isn't overly complex, yet also not too simple.

Some people claim various disadvantages of Bash that it's not possible to test Bash programs(wrong4) or that it's hard to write something relatively large in it (also wrong5).


Perl is a highly capable, feature-rich programming language with over 30 years of development. (source: perl.org). This language is NOT installed by default on all of the system, although the ratio would be somewhere between 60% to 40% on a clean OS. A lot of other software make use of it, so chances are, your OS already has Perl installed. It is much more feature rich than Bash, which makes it perfect for slightly more complex structures that might be necessary in ◜PFC◞. However, as of this moment, we have no plans to make Perl the only language to be used in ◜PFC◞ — in fact, it will most likely constitute up to 30% of the code.


Xorg is a so called display server. It's kind of like a web-server & the browser, but for your Desktop applications. Why mention it here? Precisely because it has this server-client architecture, ◜PFC◞ can successfully employ it to run applications inside its containers, but make them appear as if native on the host OS — this feature specifically concerns GUI applications, such as browsers, various word-processors, video-editors etc. More importantly, Xorg can even run over network, which, theoretically means, that if you're doing some heavy GPU processing and editing a movie, you can rent a GPU-server for a month and run your video editor there, while actually seeing it on your machine's screen.

To be clear, this is very different from VNC, which streams the whole screen of another OS, which makes it very slow over network connections.

This term simply refers to the fact that a certain piece of software or a programming language can be run on various operating systems and/or CPU-architectures without any additional hassle. ◜PFC◞, much like many of the technologies it's set to employ, may (and should) be called portable.
Long-term ZERO-maintenance principle

People like to write software without much thought of what's going to happen to it in 2 or 3 years. This doesn't concern just commercial: look at how many free & open-source software had been abandoned over the years. And why is that? There may be many reasons, but, in our humble opinion it comes down to a combination of changing environment the software is running in and funding necessary to maintain its operational capacity under these changing circumstance — funding, that's very often lacking

There are good examples too, though. Take Perl language we mentioned before. It barely changed over the past 20 years, yet it still works on all operating systems and if you could write a program in Perl 20 years ago you would have no problem writing or changing one today (apart from your own memory issues, perhaps, but we can't fix brains yet: somebody, please, fund Elon Musk to do that for those of you who are unable to handle it).


To be precise, MacOSX be default only has Bash v3.2 (although other versions can installed rather easily). FreeBSD doesn't have Bash installed at all, but, again, Bash is extremely easy to install on FreeBSD with a single command pkg install bash.


To claim that a Bash program is impossible or difficult to test is wrong, plain and simple. Type "bash unit testing" into Google or, for example, check out this library for Bash unit testing.


The predecessor of this toolset called dock.orion3.space had been written entirely in Bash. There are even web-servers out there written in Bash — all you have to do is Google a little bit and prove the statement wrong.