◜PFC◞Pain Free Containers

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

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

◜PFC◞ is a very thin layer, between you and a container engine/VM/cloud-instance of your choice. It is one interface serving all of the variety of these tools. ◜PFC◞ isn't complex, neither in its usage, nor its architecture. You WILL NOT need to learn it.

Development on local machines

All the features you'd expect from Docker, but accessible for any OS or container engine. In addition, there some unique features are provided or some features are implemented in much simpler, and more intuitive way. Unlike Docker, the ◜PFC◞ toolset does not need Dockerfiles or difficult configuration. You cd into any directory on your PC, then simply type one short command: pfc — most of the time no additional arguments would be necessary. After that you're instantly connected to your container with the current directory mounted into it.

◜PFC◞ works the same way on MacOSX, Windows, Linux and FreeBSD. It also works on most other systems too: so long as they support a hypervisor of any kind, ◜PFC◞ would launch a VM first, then launch the intended container inside that VM — and do all that without breaking a sweat.

What is the PFC workflow?
  1. First, ◜PFC◞ would start the system of your choice via a hypervisor that's native and/or available on your OS: QEMU/KVM on Linux, bhyve on FreeBSD, xhyve on MacOSX and VirtualBox on most operating systems. It will do everything without you having to configure anything — the only thing that's needed is the hypervisor installed, and that's usually pretty to do trivial on any system.

    Sometimes it makes zero sense to have containers wrapped in a VM and ◜PFC◞ provides this option via its configuration. For instance, if you're only using Linux and Docker, it doesn't make much sense to start a VM (unless it does, of course). Either way, with ◜PFC◞ you'll always have that choice.
  2. The specially-prepared images of these various operating systems will already contain everything necessary to run containers inside them. You can even have multiple "heavy" VMs for these purposes: Linux for Docker or Podman, FreeBSD for jails, etc.

  3. But the "specially-prepared" images can also be prepared you. You won't be limited, for instance, to just Ubuntu or Debian or FreeBSD for the heavy VMs. You can very easily, with just one command, make any UNIX-like OS image ◜PFC◞-compatible. In fact, ◜PFC◞, after fetching the OS-image (or using a local one from your hard-drive) from an official website, will "specially-prepare" it using a simple script, so that you can easily see: nothing malicious is being installed or added onto that VM image.

  4. The previous step with a heavier VM may be completely bypassed, as it was mentioned in the NOTE above. Yet, the container image itself would also need to be ◜PFC◞-compatible, for which the very same functionality described above will be used. You can pull container from, say Dockerhub, or use your own — PFC will only make sure to apply the recipe to it.

  5. And then, finally, a container or a set of containers can be launched: either inside that heavier VM or on your host machine directly.

But all of this seeming complexity (which, in truth, isn't all that complex) would be hidden behind the ◜PFC◞ interface, be it cli- or gui- one. And, as mentioned above, in most instances, it'll be just a single command.

Development in "the cloud"

Everything ◜PFC◞ can do for developers on their local machines, equally applies to remote bare-metal or cloud too instances. We recognize there is a significant number of developers and companies alike, who prefer to put everything — in the cloud. For this reason, ◜PFC◞ is designed to easily provide this option — with identical CLI & GUI interfaces. What's best, you can combine both local and cloud modes and use them different (or same) containers when needed.

A remote machine is, in principle, no different from a local PC, so everything works almost exactly the same under the hood (and exactly the same on the surface). For cloud or VPS instances specifically, it makes little sense wrapping containers in heavier VMs, so as mentioned previously, there is an option to bypass the VM and go straight to whichever container engine you prefer.

This is what you'll be able to do when using ◜PFC◞ in the cloud-remote mode:

  • Connect your favorite text-editor or IDE to your remote container. You won't need to set-up complex port-forwarding and you will not experience any lags either. It's all taken care of.
  • Be sure you can re-create your container in mere seconds, locally or on another remote machine, in case your current cloud provider or remote server goes down. No changes will be lost. This achieved through the flexible and light-weight backup-system ◜PFC◞ provides out of the box.

    As we've learned understand, some teams' workflows are designed in such a way, that until you perform git commit, any changes made — they may vanish. This won't happen if you're using ◜PFC◞ remote mode.

Orchestration, deployment & testing

If you're not using containers for development for one reason or the other, you may use them for deployment and testing, as well orchestration a set of containers to be launched or stopped exactly they way you want it. To learn more about that feature, read up the set section & lots of details you might like are described there.

What's ◜PFC◞'s approach, in short?
  • Many developers aren't happy with Kubernetes or its alternatives. In our humble opinion there's a lot of complexity involved that shouldn't even exist, because it serves little purpose. ◜PFC◞ will offer a simple orchestration solution, which will, basically, allow you to write your deployment and orchestration using any language of choice — all the while ◜PFC◞ itself simply serving as a glue you can use with a few basic commands to do whatever it is you want to do with your containers.
  • In addition, the flexibility of the ◜PFC◞ will allow the deployment to either be done the way it's been traditionally done with Docker — by uploading an image or a container replica and launching it; or the old-school way (for those who don't need or don't believe in deterministic builds), which is when you have similar container on your your server, and your application code changes, apply container recipes if the environment changed and restart the container.

To gain more insight into this functionality, please refer to the orchestration and deployment, pages of this website, which describe each feature in details.

Usecases for non-developers

Most people aren't programmers. The idea of a terminal window to type commands into may not sound too promising to them. Yet git, for example, can be useful in multitude of cases for people who aren't developers at all, but rather graphic designers, writers, or composers & and it's been made useful for them indeed - but over years, and slowly - by the GUI-apps built on top of git.

By the same token, ◜PFC◞—although initially conceived as a tool for developers, may be extremely useful to pretty much anyone who uses a computer. Only, we decided, there's isn't any reason for them to wait for someone to build those GUI-apps and think-up usecases. We've already done it. And here's how it'll be useful. The festivus for the rest of us, if you may:

  • Running apps NOT available on your OS

    This is achieved through various ways. For Unix systems Xorg is a perfect tool, as its client-server architecture allows ◜PFC◞ to do exactly that. We'll also be adding other solutions, so that you can, say, easily, run Windows or Linux GUI applications on MacOSX, for instance. And with CLI-apps, it's a piece of cake already.

  • Isolating apps in a safe environment

    Every application you run on your system has access to at least part of it, if not all of the system — this includes filesytem, information about your other accounts, and hardware unique ids It's hard or impossible to know what it does with this information. There are isolation techniques that already work, but they do very little to achieve true privacy. Isolating an app withing a PFC-compatible container would achieve the highest level of privacy.

    Current solutions and why they don't work

    When you're using things like Flatpak or Snap (on Linux) or app stores on MacOSX and Windows, those apps may appear isolated, but they're still granted certain permissions. They may (and probably do) collect and covertly send information about your computer, which they can access — and since those apps do need some permissions to function properly, they are able to collect quite a lot: various device ids you connect to your PC, your CPU type, your Graphics Card type, your screen resolution... the list goes on.

    Apps have unrestricted access to your system

    It is very alarming that some apps run completely unrestricted, having full access to your filesystem. And those are the apps we usually tend to use most — the browsers. Almost every browser out there on any OS, collects and sends tons of information to its vendor (yes, Firefox too) — information such as the list of all browser extensions, list of all devices that were ever connected to your PC. Then, to render matters worse, they allow websites to perform fingerprinting by querying certain properties, which the websites are then able to fetch. VPNs won't save you from that and, sometimes, even disabling JavaScript isn't enough to deter a certain amount of fingerprinting either.

    Try browserleaks.com and see for yourself.

    But should you care?

    THE ANSWER IS: IT DEPENDS. Because it's quite a hassle to care; it's hard to avoid, especially without proper programming skills, but even if you are software engineer, it's pretty damn hard. But ◜PFC◞ it will be easy. Not just easy, it will simply work: you'd click your favorite app icon and it'll start. Only, unbeknownst to itself, it will running in complete isolation, with ever-changing variables, so that every time you visit a certain website with your browser or launch your music player or chat app & it will not be give the information that can identify you (excluding the cases where you would want it to).


Due to the fact that ◜PFC◞ is being written in Bash & Perl, its recipes feature, and its ability to employ different hypervisors when needed, enables it to work on multitudes of platforms and architectures without the need for platform-specific code. And without needing platform-compatible images.

To be more precise, Bash and Perl are used to implement the internals and the cli-interface. Both languages, despite their tendency to look unattractive and obscure, will not appear such in our code. In fact, the code is intended as highly readable and navigable by even entry-level software engineers, and DOCK as well as BashJazz codebases — both creations of our team-member, are the living proof of that promise for Bash. We'll do the same with Perl too.


The ◜PFC◞ toolset is a successor to DOCK. Its original author is part of this team and gave us the blessing to proceed with this new project. He knew well, to his credit, that having enough experience and enough time to pull off what ◜PFC◞ is set to accomplish wouldn't be possible for him alone. At the same time, by joining us, he would provide the necessary expertise he himself already has. The DOCK project is fully functional product already, but only it works with Docker. Which is good, but limits the scope tremendously and makes it a vendor-locked, albeit, still useful. And it currently has a few limitation which ◜PFC◞ aims to address too.

The important part is that we're not starting from zero. And we don't just have a prototype, but a working product (which DOCK certainly is), a team member with the experience that this projects requires — and both are living proofs that everything described here is entirely possible to accomplish.

Simple & unified: cli or gui
Both cli and gui are the same, regardless of the OS or container engine. There is no complex config (if at all) and just one cli-command, with very few arguments.
No vendor lock-in
PFC is designed to be 100% portable. It's works just the same for on any major OS, any major container engine, and it can accommodate cloud providers too: you are not forced to make any choices. Furthermore, you combine various ones.
CPU architecture doesn't matter
When using PFC, you don't need images for different CPU-architectures. PFC provides an elegant solution called recipes1 to avoid this problem.
No need for your team to buy in
It is designed to be used completely independently. Your team's not in the mood for another tool? Not to worry. PFC's priority is you. Lead by example, don't be selling.
Free, opensource, BSD-licensed
Written in Bash and Perl2 makes it highly portable and easy to understand and modify to your needs. Like many other Unix tools, it's built to last, with minimum maintenance, if at all. It's released under the BSD licence.
One-man-show & large-scale friendly
No BIG thing that lasts starts as such: PFC works just as well for sole developers, small teams, and, finally, large scale projects.