Beyond Self-Hosted Apps

We have already talked quite a bit about the importance of self-hosting
your apps due to the limitations of
centralized cloud services
and mentioned a number of great apps ready for self-hosting.
In this blog post, we assume that you already self-host your apps
to protect your data autonomy.
From here, we look at what happens after you set up an app on your hardware,
and how you maintain it:
a job that is typically done in organisations
by professional system administrators, aka sysadmins.

Human Sysadmins Do not Scale

In this decentralized dream, we quickly see that having a human sysadmin for
every personal data center is a luxury, either in terms of money needed to
hire one or of personal time needed to stay informed and on top of
all the current security threats. Security vulnerabilities are found almost
daily! A few recent popular ones include: Heartbleed,
Shellshock,
Logjam and FREAK...
(there's gotta be a song hiding in there with
all these nice exploit names 😀).

What if the current package — where people start out with a Linux SD card image
for a Raspberry Pi and are on their own from there — on is too low-level?

Open Source Platform Commons

We believe that the right level of abstraction for decentralizing the web is not
by providing only operating system images, but by providing a platform.
In such a platform, after installing that first self-hosted app,
the user can still easily get
automatic updates for security patches. It would include the collective wisdom
of the crowd, made transparent through an open source project,
the open source platform commons.

1. Auto-Updates

Heroku did a great thing for application development, allowing developers to
set up their clients with apps that are deployed to a platform where Heroku's
sysadmins handle the operations, freeing the app owners of needing dedicated
engineers to handle day-to-day operations. We need something like this for
self-hosting apps too.

Of course, at the time this came out, we had already hardened
our nginx configuration. All of the CloudFleet Blimps got this patch through
the nightly auto-updates we provide as part of the CloudFleet
Services.

2. Openness and Trust

The other key component is that we need to know that we can trust this group of
people that is pushing updates to us. For example, we love using Signal
for messaging internally and as Mark nicely put it:

Signal is built as an open source project by people who transparently discuss
its development in the open and are serious about security. This immediately
gives it more credibility than closed source apps
like WhatsApp that claim to have e2e encryption,
or even than some semi-open apps like Telegram, which were recently
criticized by multiplesides.

We are striving to develop CloudFleet in an open and trustworthy manner as well,
with all of the source code and protocols published as
open source. We are ready to discuss all aspects of our
project on our public (self-hosted) forum.

As we are striving to decentralize the Internet through self-hosting using
projects like the Raspberry Pi, we are asking more and more people to keep track
of everything that is going on in the
security sphere, which is simply not possible without investing a lot of time.
The end goal where individuals have their own hardware device for storing their
data will invariably mean the end of the sysadmin and necessitate
open source platform commons. Take a look at this CloudFleet
technical overview to see how we are building one in the open and
consider backing our crowdfunding campaign.

Discussion

About

In the CloudFleet Captain's Log you can read about our ongoing journey
towards providing easy-to-use solutions for self-hosting.