<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Preservation on isoul.uk</title>
    <link>https://isoul.uk/tags/preservation/</link>
    <description>Recent content in Preservation on isoul.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Mon, 14 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://isoul.uk/tags/preservation/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Enshittification and the case for self-hosting</title>
      <link>https://isoul.uk/posts/enshittification-and-the-case-for-self-hosting/</link>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://isoul.uk/posts/enshittification-and-the-case-for-self-hosting/</guid>
      <description>Why platform decline makes local copies, open formats and practical exit routes more important.</description>
      <content:encoded><![CDATA[<p>Self-hosting is becoming more interesting for a reason that has little to do with fashionable infrastructure. People are discovering that services they relied on can become worse while they are still using them.</p>
<p>Features disappear. Prices change. Limits arrive. Advertising takes over. A product that began as useful becomes harder to use, less private or dependent on an account that can be closed.</p>
<p>Cory Doctorow calls this process <strong>enshittification</strong>. In <em>Enshittification: Why Everything Suddenly Got Worse and What to Do About It</em>, he argues that platforms can first attract users with convenience, then lock in users and businesses before shifting value away from both groups.<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> The Creative Salon article supplied alongside this book is another useful reference point for the discussion.<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></p>
<h2 id="what-this-has-to-do-with-self-hosting">What this has to do with self-hosting</h2>
<p>Self-hosting is not a cure for every problem. It does not remove the need for electricity, updates, backups, domains, broadband or sensible security. It also does not mean every cloud service should be replaced.</p>
<p>It does provide something valuable: an alternative place for important data and services to exist.</p>
<p>A local photo library means a company changing its storage rules does not become the only authority over the family archive. A self-hosted media server means access to an owned collection does not depend entirely on one catalogue or subscription. An encrypted backup means a hardware failure is not automatically a permanent loss. A service such as Karakeep can keep bookmarks and saved material in a system you can back up and inspect.</p>
<p>The goal is not technological purity. The goal is to avoid making one company the only place where an important service, memory or copy of a file exists.</p>
<h2 id="the-practical-test">The practical test</h2>
<p>Before adopting a service, ask:</p>
<ul>
<li>Can the data be exported?</li>
<li>Is the export usable somewhere else?</li>
<li>Does it work without a mandatory cloud account?</li>
<li>Are open formats or documented APIs available?</li>
<li>Can the application data be backed up and restored?</li>
<li>What happens if development stops?</li>
<li>What happens if the company changes its pricing or licence?</li>
<li>Can the service be replaced without losing the underlying data?</li>
</ul>
<p>A nominal export is not necessarily an exit route. A collection of files that cannot be opened elsewhere is only a different kind of lock-in.</p>
<h2 id="a-balanced-approach">A balanced approach</h2>
<p>Cloud services remain useful. They can provide availability, collaboration, off-site protection and less maintenance. The mistake is not using them. The mistake is allowing a provider to become the only copy, the only login and the only route to something important.</p>
<p>A reasonable arrangement is often mixed:</p>
<ol>
<li>Use a hosted service where it is genuinely convenient.</li>
<li>Keep local copies of important data where practical.</li>
<li>Prefer open or widely supported formats.</li>
<li>Maintain an independent backup.</li>
<li>Test restoring something before it is urgent.</li>
<li>Know what you would use if the provider disappeared.</li>
</ol>
<p>This is why the principle here is simple: <strong>keep it simple, keep it local, keep a copy</strong>.</p>
<p>Self-hosting is not about building a private version of every website. It is about keeping enough control that a platform becoming worse does not automatically make your own data, memories or workflow worse with it.</p>
<h2 id="sources">Sources</h2>
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p><a href="https://www.versobooks.com/products/3341-enshittification">Cory Doctorow, <em>Enshittification: Why Everything Suddenly Got Worse and What to Do About It</em></a>&#160;<a href="#fnref:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:2">
<p><a href="https://creative.salon/articles/features/enshittification-david-bain-bmb">Creative Salon — Enshittification</a>&#160;<a href="#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
</ol>
</div>
]]></content:encoded>
    </item>
  </channel>
</rss>
