{"id":189,"date":"2020-09-26T13:16:37","date_gmt":"2020-09-26T13:16:37","guid":{"rendered":"https:\/\/dft.wiki\/?p=189"},"modified":"2026-06-09T15:01:36","modified_gmt":"2026-06-09T19:01:36","slug":"snap-vs-docker-vs-multipass","status":"publish","type":"post","link":"https:\/\/dft.wiki\/?p=189","title":{"rendered":"Snap vs Docker vs Multipass"},"content":{"rendered":"

The difference between Snap, Docker, and Multipass can be easily understood through one example:<\/p>\n

Let’s suppose you need a LAMP stack to run code and possibly share content on the Internet. There are four ways to do it:<\/p>\n

1st – The conventional way<\/strong> (reference) involves manually installing Apache, PHP, and MySQL on<\/strong> the host OS. The services use all the libraries, kernel, and resources from the host OS. The software merges into your system, sharing files, permissions, etc. If one service crashes, the whole host OS can become inoperative, and if one service has a vulnerability, all data becomes vulnerable.<\/p>\n

2nd – The Snap way<\/strong> downloads and installs a self-contained package called a ‘snap’ on<\/strong> the OS. With minimal effort, Snap downloads and installs one capsule (an isolated app) containing all the needed services (Apache + PHP + MySQL), along with all dependencies and libraries (which is why it runs on multiple platforms). Snap starts and stops all services at once, as a single ‘block’ application running on the OS. It carries the same crash risk as The conventional way<\/strong> (1st).<\/p>\n

3rd – The Docker way<\/strong> pulls (downloads) an image. This image shares the host OS kernel but creates a fully independent environment with its own users, permissions, file system, etc. This environment is called a Container and does not require a boot, so starting and stopping processes is very fast. It feels like a lightweight VM, but it is not. There is a shell to access the container, and if a service crashes inside, it will most likely not affect the host OS. The same applies to vulnerabilities: they are kept inside the container.<\/p>\n

4th – The Multipass way<\/strong> launches (downloads and runs) a pre-installed Ubuntu image. This creates a brand new Virtual Machine that shares nothing with the host OS, with no shared vulnerabilities or crash risk. Multipass is not a hypervisor; it is a tool to quickly and easily spin up a fresh VM in just one command using the native hypervisor, useful when you frequently need disposable VMs for testing. Inside the VM, you still need to follow The conventional way<\/strong> (1st) to install all software and services.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Conventional<\/strong><\/td>\nSnap<\/strong><\/td>\nDocker<\/strong><\/td>\nMultipass<\/strong><\/td>\n<\/tr>\n
Real Machine<\/strong> (Host).<\/td>\nSelf-Contained<\/strong> Software.<\/td>\nContainer<\/strong>.<\/td>\nVirtual Machine.<\/strong><\/td>\n<\/tr>\n
Any<\/strong> Host OS.<\/td>\nCross Linux<\/strong> Distributions.<\/td>\nCross Linux<\/strong> Distributions.<\/td>\nLinux, Windows, or Mac.<\/strong><\/td>\n<\/tr>\n
Single<\/strong> Environment.<\/td>\nRuns on the Host Single<\/strong> Environment.<\/td>\nMultiple<\/strong> Environments.<\/td>\nMultiple<\/strong> (Ubuntu Only) Environments.<\/td>\n<\/tr>\n
Software<\/strong> is installed on the host OS.<\/strong><\/td>\nSoftware<\/strong> is installed in a snap.<\/strong><\/td>\nThe image<\/strong> is run in containers.<\/strong><\/td>\nThe chosen Ubuntu<\/strong> version is installed in a VM.<\/strong><\/td>\n<\/tr>\n
Usually<\/strong>, a new version replaces the old<\/strong> one.<\/td>\nIt can keep different versions<\/strong> side by side.<\/td>\nMultiple containers can run different versions<\/strong>.<\/td>\nDifferent images can be different versions<\/strong>.<\/td>\n<\/tr>\n
Start\/Stop real services<\/strong>.<\/td>\nStart\/Stop like services<\/strong>.<\/td>\nStart\/Stop like services<\/strong>.<\/td>\nBoot the whole VM.<\/strong><\/td>\n<\/tr>\n
Software<\/strong> size.<\/td>\nSoftware<\/strong> size + libraries<\/strong> size.<\/td>\nSoftware<\/strong> size + image<\/strong> size (from 64 to 104MB).<\/td>\nSoftware<\/strong> size + full OS<\/strong> (from 55 to 1002MB).<\/td>\n<\/tr>\n
Host file system<\/strong>.<\/td>\n.snap (Squashfs<\/strong>).<\/td>\nN\/A (OverlayFS<\/strong>).<\/td>\n.img (on KVM Hypervisor<\/strong>).<\/td>\n<\/tr>\n
Uses all<\/strong> hardware.<\/td>\nUses all<\/strong> hardware.<\/td>\nUses all<\/strong> hardware.<\/td>\nUses what was allocated<\/strong>: RAM, CPU, Disk, etc.<\/td>\n<\/tr>\n
Manual deletion, possible leftovers<\/strong>.<\/td>\nClean deletion, no leftovers<\/strong>.<\/td>\nClean deletion, no leftovers<\/strong>.<\/td>\nClean deletion, no leftovers<\/strong>.<\/td>\n<\/tr>\n
N\/A<\/td>\nVery lightweight.<\/strong><\/td>\nLightweight.<\/strong><\/td>\nHeavyweight.<\/strong><\/td>\n<\/tr>\n
N\/A<\/td>\nLoads in approx. 2 seconds.<\/strong><\/td>\nLoads in approx. 2 seconds.<\/strong><\/td>\nLoads in approx. 10 seconds.<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
\"\"<\/figure>\n

My opinions on which applications fit best with each approach:<\/p>\n

\n\n\n\n\n\n
Conventional<\/strong><\/td>\nSnap<\/strong><\/td>\nDocker<\/strong><\/td>\nMultipass<\/strong><\/td>\n<\/tr>\n
If you have a physical machine dedicated to a single purpose<\/strong>, this is the best option. It has full hardware access and best performance<\/strong> with no overhead.<\/td>\nEasy and clean installation<\/strong> of full software packages. It can deploy complex systems with all supporting services, such as database servers, and everything comes pre-configured and ready to use.<\/strong><\/td>\nExcellent for keeping all services isolated<\/strong> and protecting the whole system and data, without running many VMs in parallel<\/strong>, which would cause significant overhead.<\/td>\nFor production servers, this is the most powerful and reliable<\/strong> way to keep services isolated, reducing vulnerabilities and protecting data and the system. It requires capable hardware<\/strong> with sufficient CPU, RAM, disk, etc.<\/td>\n<\/tr>\n
<\/td>\nHow to Use<\/td>\nHow to Use<\/a><\/td>\nHow to Use<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

REFLECTION NOTES<\/strong><\/p>\n

The use case will define which method best fits the need, but a few key decision points are worth mentioning:<\/p>\n