Wat de Community Edition is
De Community Edition is een zelf-gehoste versie van MemoryVault die je op je eigen infrastructuur draait. Het bevat het product zelf: herinneringen, dierbaren, groepen, Open When-berichten, de checklist voor digitale nalatenschap, en de bezorgstroom die inhoud overhandigt aan de mensen die je hebt aangewezen.
Het heeft een Postgres-database nodig en een plek voor geüploade bestanden, via S3-compatibele opslag. Beide lever en beheer je zelf, en dat is precies de bedoeling.
Wat er niet in zit, is de marketingwebsite en de bijbehorende paginabouwer. Dat is minder een beperking dan een erkenning dat een publieke marketingsite volstrekt nutteloos is voor iemand die dit voor zijn eigen familie draait, en dat meenemen ervan zou betekenen dat je een hoop code meesleept die alleen bestaat om het gehoste product te verkopen.
Geen limieten, geen facturatie
Er zitten geen abonnementslimieten in de Community Edition. Herinneringen, dierbaren, Open When-berichten en opslag zijn allemaal onbegrensd, en er zit geen enkele facturatie- of abonnementscode in.
Dat is het waard om helder te stellen, want "community edition" betekent vaak een bewust uitgeklede versie met bij elke stap een upgradeknop. Dat is hier niet het geval. De modules die limieten afdwingen zijn vervangen door versies die simpelweg onbeperkt teruggeven, en de afreken- en abonnementspaden zijn uit de codebase verwijderd in plaats van achter een vlaggetje verstopt.
Het praktische gevolg is dat je eigen schijf en je eigen database je enige beperking zijn. Geef je het een terabyte, dan heb je een terabyte. Niemand mailt je dat je een quotum nadert, want er is geen code meer over die weet wat een quotum is.
“Zelf hosten gaat niet om geld besparen. Het gaat erom dat niemand later de voorwaarden voor je kan veranderen.”
Wat je op je neemt
Alles wat de gehoste versie stilletjes op de achtergrond doet, wordt van jou. Het loont om eerlijk te zijn over de omvang van die lijst voordat je begint.
Back-ups zijn de belangrijkste, en ze wegen hier zwaarder dan bij vrijwel elk ander soort project. Dit zijn gegevens die jou expliciet moeten overleven. Een server die sterft zonder back-up verliest niet zomaar wat bestanden; die ondergraaft het hele doel van het opslaan ervan. Regel back-ups voordat je er echte inhoud in zet, test dat je ze kunt terugzetten, en test over een half jaar opnieuw.
Je neemt ook updates en beveiligingspatches op je, het vernieuwen van TLS-certificaten, de database bereikbaar houden, en bewaken dat het geheel nog draait. Dat laatste is subtieler dan het klinkt: een kluis die al acht maanden stilletjes stuk is, is niet te onderscheiden van een werkende, tot de dag dat het nodig is.
En je neemt de encryptiesleutel op je. Raak je die kwijt, dan is de versleutelde inhoud werkelijk onherstelbaar weg. Er is geen helpdesk, geen herstellink en geen slimme procedure. Bewaar een reservekopie van de sleutel los van de database, want een back-up die beide bevat, is één voorwerp waarvan het verlies alles meeneemt.
Het opvolgingsprobleem
Dit is het deel waar de meeste zelf-hosters niet over nadenken, en juist bij deze toepassing weegt het het zwaarst.
Als het hele doel bezorging na je overlijden is, dan moet iemand anders dan jij de server draaiende kunnen houden, of op zijn minst bij de gegevens kunnen. Een kluis die alleen jij kunt beheren, is een kluis die precies op het verkeerde moment stopt. Het falen is stil en perfect getimed: de machine draait door tot een pasje verloopt of een schijf volloopt, en tegen die tijd is degene die wist hoe je het repareert precies degene op wie het systeem zat te wachten.
Behandel de infrastructuur dus als onderdeel van het plan in plaats van als een detail eronder. Schrijf op waar het draait, wie het betaalt en van welke rekening, wat het domein is en waar dat geregistreerd staat, hoe iemand anders erin komt, en waar de encryptiesleutel ligt. Leg dat ergens waar een familielid het daadwerkelijk vindt. Meestal betekent dat papier, bij de andere documenten die mensen na een overlijden zoeken.
Het loont ook om jezelf eerlijk te vragen of iemand in je huishouden het zou kunnen overnemen. Niet of ze het theoretisch zouden kunnen leren, maar of ze het zouden dóén, in de weken na je overlijden, met alles wat daar verder bij komt. Is het antwoord nee, dan is dat belangrijke informatie over welke optie je moet kiezen.
Voor wie het is
Zelf hosten is logisch als je al infrastructuur draait en dit gewoon één dienst extra is op een machine die je toch onderhoudt. Het is logisch als je de code wilt lezen voordat je er iets zo persoonlijks aan toevertrouwt. Het is logisch als je simpelweg liever hebt dat juist deze gegevens nooit op andermans hardware staan, en je bereid bent de prijs van die voorkeur te dragen.
Het is aanzienlijk minder logisch als niemand in je huishouden de server zou kunnen overnemen, of als dit je eerste ervaring zou zijn met iets in productie draaien. Dan is de gehoste versie geen compromis of mindere keuze; dan is het juist de optie die waarschijnlijker nog werkt op de dag dat het ertoe doet, en dat is hier de enige maatstaf die telt.
Beide draaien hetzelfde kernproduct. De keuze gaat niet over functies. Het gaat over wie de operationele last draagt en wie de sleutels beheert, en dat zijn vragen over jouw omstandigheden, niet over de software.
Lees hoe dan ook de code. Die staat er om gelezen te worden, en hem lezen is nuttig, ook als je besluit iemand anders hem te laten draaien.
Nog niet klaar om een kluis te starten?
Download in plaats daarvan onze gratis Digitale Nalatenschap Checklist als PDF. Een korte, praktische start om te regelen wat belangrijk is. Geen account nodig.
