Hi Joel,
Docker and Sandstorm both use the same underlying Linux kernel features for containerization, but things get pretty different above that.
Docker aims to let you put a standard Linux distribution like Ubuntu or Debian into a container. When you run the container, the entire filesystem is mutable, e.g. you can install new packages. You can shell into the container and use it exactly like you would a Linux VM. The container might have multiple users, daemons that run full-time, cron jobs, etc.
Sandstorm aims to create an environment where the only way you ever interact with an app is through your web browser. The intent is that a non-tech-savvy end user should be able to operate their Sandstorm server intuitively. Moreover, Sandstorm is designed to allow much finer-grained containers. When running Etherpad on Sandstorm, each document actually lives in an isolated container.
This leads to several very different design choices:
- Containers only run while you have them open in your browser. Once you close the browser, the container is shut down, and then restarted the next time you return. (This implies that containers have to start up very fast.)
- Most of the container's filesystem is read-only, so that all containers can share common files (such as the application binary). Only /var is writable, and that's where it stores data specific to the particular document.
- Containers do not usually run any background daemons. Just a web server for the app itself.
- Containers do not use OS-level user accounts.
- HTTP requests going into the container must pass through the Sandstorm front-end, which handles authentication and access control so that the application doesn't have to. Thus apps are easier to write and many kinds of possible security bugs in apps are avoided.
You're right that I should cover this on the web site or readme somewhere. I'll put that on my todo list.
-Kenton