> The long-term security of Linux containers has not been well explored yet. There have been exploits against the Kernel found, and there are likely to be more.

Good answer, but I counter with this:

https://blog.sandstorm.io/news/2014-08-13-sandbox-security.h...

> Plus, how much effort has gone into hardening the Cap'n'Protocol bridge? Do you have a security expert reviewing the code and looking for vulnerabilities?

Among our advisors are Mark Miller and Jas Nagra, both members of the Google security team (though advising us in their free time, not on behalf of Google). Cap'n Proto is based heavily on Mark Miller's previous work in capability-based security.

Also among our advisors is Andy Lutomirski, a kernel developer who specializes in security and sandboxing. He has been cranking out CVEs against the kernel lately. Most of them haven't affected Sandstorm, due largely to our seccomp filter which Andy himself wrote and continues to work on (see link above).

My own background is diverse but includes a few years working on security at Google.

That said, we have not yet commissioned a thorough security review of Cap'n Proto's own implementation. That is something we plan to do before any 1.0 release (of Cap'n Proto or Sandstorm).

> But not their in-memory caches. Code and shared make up a fraction of their presence in memory.

Depends. If the app is written in C++ or Rust, then the code is mmap'd in (with that memory being shared across instances). The runtime memory overhead tends to be very low if the app is single-user.

For apps written in dynamic languages that parse their code at startup, yes, memory usage is a lot larger -- as a rule of thumb, many apps use around 100MB. One idea we have to fixing this is to checkpoint an app at the point when it first tries to read its per-instance data and restore from that checkpoint on future runs. This checkpoint could theoretically be shared between all instances and mmap'd copy-on-write.

That said, we don't feel this trick is immediately needed. For our upcoming managed hosting service, we've run the numbers and are confident that the vast majority of users will not come anywhere near hitting the resource limits we've set even for the "standard" service level, and we aren't losing money if they do.

> And if we're running potentially dozens of PostgreSQL instances on a single machine

For the scale of a Sandstorm app, it makes tons of sense to switch to sqlite, which mostly solves this problem. :)