What the Community Edition is
The Community Edition is a self-hosted version of MemoryVault that you run on your own infrastructure. It contains the product itself: memories, loved ones, groups, Open When messages, the digital legacy checklist, and the delivery flow that hands content to the people you named.
It needs a Postgres database and somewhere to keep uploaded files, using S3-compatible storage. Both are things you provide and control, which is the entire point.
What it does not include is the marketing website and its page builder. That is not a restriction so much as a recognition that a public marketing site is of no use whatsoever to somebody running this for their own family, and carrying it would mean carrying a large amount of code that exists only to sell the hosted product.
No limits, no billing
There are no plan limits in the Community Edition. Memories, loved ones, Open When messages and storage are all unbounded, and there is no billing or subscription code in it at all.
This is worth stating clearly, because "community edition" often means a deliberately hobbled version with an upgrade prompt at every turn. That is not what is happening here. The modules that enforce limits are replaced with versions that simply return unlimited, and the checkout and subscription paths are removed from the codebase rather than hidden behind a flag.
The practical consequence is that what constrains you is your own disk and your own database. If you give it a terabyte, you have a terabyte. Nobody is going to email you about approaching a quota, because there is no code left that knows what a quota is.
“The point of self-hosting is not saving money. It is that nobody can change the terms on you later.”
What you take on
Everything the hosted version does quietly in the background becomes yours. It is worth being honest about the size of that list before you start.
Backups are the big one, and they matter more here than in almost any other kind of project. This is data specifically intended to outlive you. A server that dies with no backup does not merely lose some files; it defeats the entire purpose of having stored anything in the first place. Set up backups before you put real content in, test that you can restore from them, and then test again in six months.
You also take on updates and security patches, TLS certificate renewals, keeping the database reachable, and monitoring that the whole thing is still running. The last one is subtler than it sounds: a vault that has been quietly broken for eight months is indistinguishable from a working one until the day it is needed.
And you take on the encryption key. Lose it and the encrypted content is gone in a genuinely unrecoverable way. There is no support line, no reset link, and no clever recovery procedure. Back the key up somewhere separate from the database, because a backup that contains both is a single object whose loss takes everything.
The succession problem
This is the part most self-hosters do not think through, and it is the one that matters most for this particular application.
If the entire point of the system is delivery after your death, then somebody other than you has to be able to keep the server running, or at least reach the data. A vault that only you can administer is a vault that stops working at exactly the wrong moment. The failure is quiet and perfectly timed: the machine keeps running until a card expires or a disk fills, and by then the person who knew how to fix it is the person the system was waiting for.
So treat the infrastructure as part of the plan rather than as a detail beneath it. Write down where it runs, who pays for it and on which card, what the domain is and where it is registered, how somebody else would get in, and where the encryption key is kept. Put that somewhere a family member will actually find, which usually means paper, alongside the other documents people look for after a death.
It is also worth asking honestly whether anybody in your household could take over. Not whether they theoretically could learn, but whether they would, in the weeks after losing you, with everything else that involves. If the answer is no, that is important information about which option you should choose.
Who it is for
Self-hosting makes sense if you already run infrastructure and this is one more service on a machine you maintain anyway. It makes sense if you want to read the code before trusting it with something this personal. It makes sense if you simply prefer that this particular data never sit on somebody else's hardware, and you are willing to carry the cost of that preference.
It makes considerably less sense if nobody in your household could take over the server, or if setting it up would be your first experience of running anything in production. In that case the hosted version is not a compromise or a lesser choice; it is the option more likely to still be working on the day it matters, which is the only benchmark that counts here.
Both run the same core product. The choice is not about features. It is about who carries the operational burden and who holds the keys, and those are questions about your circumstances rather than about the software.
Read the code either way. It is there to be read, and reading it is useful even if you decide to let somebody else run it.
Not ready to start a vault yet?
Download our free Digital Legacy Checklist PDF instead. A short, practical starting point for organizing what matters. No account required.
