Theory

• 1: How SelfPrivacy automates server management
• 2: Project architecture

1 - How SelfPrivacy automates server management

Self-hosted means “independent server hosting” or “hosting yourself”. This is when IT people do not use popular services like Google, they install free (like freedom) alternatives on their own or rented servers (VPS). It turns out that you get the same service, but under your own control. Often, free analogues will be more functional, private and secure than free off-the-shelf options from big companies.

Self-hosting provides complete privacy of data, including meta-information. But it also imposes an obligation to manually operate the system:

• You need to set up a domain for the application and a TLS certificate;
• You need to take care of the server security;
• Do not miss critical security updates;
• Make regular backups;
• Make sure that the disk does not overflow;
• Create and delete service users;

For an IT person, the tasks are manageable, even though they are troublesome. But for the rest of us, they are almost unbearable. The task of SelfPrivacy is to simplify this process as much as possible. You don’t need to use a console or be a skilled technician. The program automates all for you.

Domain Management

Full automation

Once you have configured your domain on CloudFlare and copied the API key into the SelfPrivacy application — your domain is managed completely automatically:

• Records are created for all services;
• Updated if necessary;

All you have to do is pay for the domain once a year at your registrar. Don’t forget to check your email account.

Certificate management

Full automation

Security of communication with your server is ensured by TLS ≥ v.1.2, like in banks. For this purpose SelfPrivacy uses a certificate from Let’s Ecncypt, the world’s most popular provider trusted by millions of web portals.

Updating the operating system on your server

Full automation

A once-configured server is not completely secure. Over time, bugs may appear in the services, and the server becomes susceptible to hacking. Unfortunately, this is not such a rare occurrence. That’s why responsible IT professionals regularly update their servers. SelfPrivacy does it for you.

• System updates;
• Major NixOS releases;

Updating the server part of SelfPrivacy

Partial automation

SelfPrivacy consists of two parts - an app on your device, such as your phone or PC, and a server backend called the SelfPrivacy API. SelfPrivacy manages your service providers and your server. To do this, the SelfPrivacy API backend daemon runs on the server side. It also needs to be updated, for example when we add functionality or fix bugs. Updating often happens automatically, but sometimes you have to manually confirm a system configuration update to make the new features of the SelfPrivacy server side work.

Updating SelfPrivacy

Full automation

The SelfPrivacy application, roughly speaking, is a set of instructions that change something in the server. The work of the application after the initial configuration in no way affects the performance of services on your server. Nevertheless, every day we try to automate something, fix something, add new functionality. Application updates are done automatically from the repository, such as F-Droid, in the near future App Store and Google Play.

Server resource management

Partial automation

When there are a lot of users or services, the server can start to slow down. Through the application you can monitor the current resource consumption, and soon it will be possible to order an upgrade of the virtual machine.

Disk management

Partial automation

The application keeps track of the free space on the server disks and allows you to transfer data between them. If the partition is expandable, the app can automatically order more space after user confirmation.

Rescue copies

Full automation

Backups allow you to both repair broken servers and migrate from one server to another. All backups are encrypted, under the hood we use Restic. Each service’s data is backed up individually. Backups can also be done automatically at user-defined intervals.

User Management

Partial automation

Each service has its own administrator interface that allows you to manage users. However, we are working to integrate this functionality into the application and automatically create users from a common list.

Manual management via SSH (expert)

Manual operations

For security reasons, access to SelfPrivacy server administration via SSH is disabled by default. This reduces the attack surface. Console access is needed in exceptional cases:

• Upgrade error, or fixing unexpected situations;
• Server tuning, if you are an experienced NixOS user and want to tweak SelfPrivacy Server for your own needs;

In normal operation, the user does not need to use SSH administration through the console. We are working to ensure that the general configuration of SelfPrivacy can be extended with your own Nix files, which will not interfere with automatic updates.

The system is very complex, why is it private?

All transactions take place between your application, your server, and your service providers without SelfPrivacy being involved. Your copy of SelfPrivacy App is completely autonomous and independent in managing your infrastructure. No information about your interactions with your infrastructure reaches SelfPrivacy. All backups of your services leave your server in a fully encrypted form.

You can read more about this in our privacy policy.

2 - Project architecture

Yes, you could use kubernetes. But why when immutability is ensured by NixOS?

User app: Flutter/Dart was chosen because of the speed and smoothness of the UI and cross-platform.

Server side (backend): NixOS + Python. NixOS was chosen because of its reproducibility, python because of its versatility and popularity.

Service providers

We do not get paid by any service providers! We are not affiliated with them in any way. We chose them purely for professional reasons. But we do not exclude partnership in the future.

Hosting

SelfPrivacy supports two hosting providers: Hetzer and DigitalOcean

Both were chosen because of low price and acceptable level of service, quality REST API.

Candidates:

• Own personal iron server. Our main priority right now;
• A service provider that will provide an API to deploy an iron server. Outside FVEY;
• OVH
• Scaleway

There’s also free Oracle Cloud, but where you don’t pay, you’re usually a commodity.

DNS

There’s a choice between Cloudflare, deSEC, or DigitalOcean DNS.

deSEC is a more private option and is recommended by default.

Cloudflare likely collects data in proxy traffic mode, otherwise it’s hard to explain why they would offer such services for free. In our case, we don’t proxy anything and use it only as a DNS server.

Backup repository

We use Backblaze.

The first 20GB are free and significantly cheaper than AWS. Backblaze publishes its hardware developments in open source. They also shares very useful statistics on disk failures, based on which one can choose the most reliable and tested option.

In the future, we might replace them with a self-hosted solution or a peer-to-peer one. Currently, this is not a top priority since the data is encrypted, and the service provider only sees the IP address of your server, not the device with the application.