A blog post by Lukas Mathis has been sitting open in my browser tab for almost two weeks now. Every time I see it, it reinforces something I’ve believed for years: our growing dependence on big tech services comes with hidden costs that many of us don’t fully consider. Lukas’s post strikes a chord with me on multiple levels, and I think it’s worth exploring why digital independence matters more than ever.

The most obvious concern is privacy. When you upload your photos to Google Photos, your documents to Google Drive, or your files to any cloud service, you’re essentially handing over control of your personal data. Sure, these companies have privacy policies, but those policies can change. And even with the best intentions, your data becomes subject to their business models, government requests, and potential security breaches. Lukas uses photos as his primary example, but the issue extends far beyond image storage. Your emails, documents, notes, contacts, calendars—essentially your entire digital life—can end up in the hands of companies whose primary allegiance is to their shareholders, not to you.

The second issue that resonates with me is dependency. Cloud services can disappear overnight. Companies can change their terms of service, increase prices dramatically, or simply decide you’re no longer welcome on their platform—all without meaningful recourse for users. I’ve seen this happen repeatedly. Google alone has a graveyard of discontinued services that once hosted people’s important data. When you’re dependent on a single provider, you’re essentially betting your digital life on their continued goodwill and business success.

This is why I’ve made deliberate choices to maintain my digital independence, even when it means sacrificing some convenience.

I gravitate toward Apple’s ecosystem not just for the user experience, but because their business model doesn’t depend on harvesting my personal data. I also deliberately limit my social media usage—partly for mental health reasons, but also to reduce my digital footprint. For photos, I’ve skipped iCloud Photos entirely. Instead, I store my photo library on a local NAS (Network Attached Storage) device, which I then back up to the cloud using strong encryption. This gives me the best of both worlds: local control over my data with the safety net of remote backup.

One of my longest-running projects has been hosting my own email server—something I started doing over 20 years ago. Back then, it meant manually compiling and configuring everything from scratch, spending countless hours debugging mail server configurations and fighting spam filters. Today, I use Mail-in-a-Box, which has transformed email self-hosting from a masochistic technical exercise into something remarkably straightforward. The software handles all the complex configuration automatically while still giving me complete control over my email infrastructure.

The beauty of this approach extends beyond just privacy. Because I control the entire stack, I can host it with any VPS provider I choose. If I’m unhappy with my current host’s service, pricing, or policies, I can simply spin up a new server elsewhere and restore from backup. This portability is freedom in the truest sense.

If you’re interested in taking back control of your digital life, you’re not alone. The self-hosting community has grown tremendously, and the barrier to entry has never been lower. Lukas mentions the awesome-selfhosted GitHub repository, which is an incredible resource. This curated list contains hundreds of open-source applications that can replace virtually any cloud service you’re currently using. Whether you need file storage, media streaming, password management, or collaborative tools, there’s likely a self-hosted solution available.

I won’t pretend that digital independence comes without costs. Self-hosting requires time, some technical knowledge, and ongoing maintenance. You become responsible for updates, security, and troubleshooting. The convenience of “it just works” that comes with major cloud services is genuinely valuable. But for me, the trade-offs are worth it. The peace of mind that comes from knowing I control my data, that I’m not subject to arbitrary policy changes, and that I can switch providers without losing years of digital history—that’s invaluable.

Last weekend I updated my Mail-in-aB-ox server because my old server was still running Ubuntu 18 and the current version requires Ubuntu 22.04. I was several versions behind because I dreaded the upgrade process. In the end it almost went smoothly, I had some struggles with restoring my data but that was caused by my inexperience. I’m stil in awe of how simple it has been made.

By re-installing my box I also had to go through my own instructions of running AWStats for the static websites that are hosted on the mailserver. I noticed som small inconsistencies and made some steps a bit clearer on what to do.

The other change I made is the addition of another configuration file in my multipass setup scripts. I’ve been playing with AWS Chalice. It’s a framework on top of AWS Lambda functions and DynamoDB. The installation includes a docker image of a local DynamoDB server to use for local development. The file is called chalicedev.yaml. Have fun.

Having only static pages available makes it harder to integrate tracking solutions to analyse website visitors. In line with my philosophy to privacy concerns I’ve chosen to implement a simple solution that runs on the server itself that isn’t very intrusive to the users as well: AWStats.

The setup is to generate static html reports on the usage of the websites you host by analysing the logfiles generated by nginx. The static websites are hosted on the same box in a separate directory or a subdomain. Optionally you can restrict access to the statistics, I’ve included a basic authentication configuration to access. Feel free to use it, leave it out or even include a better solution. I’ve not included any Geo-ip tracking which is possible with additional configuration and packages.

As far as I can tell at the moment this setup will not interfere with MAIB configuration for 99%. The only affected area might be the logrotate configuration which could be affected by an update from nginx.

install AWStats

This is the simplest part of the setup, just run: sudo apt install awstats

Configure Nginx

To proces the logfile for each site we need to split them out. MIAB has configured nginx to log everything to a single file which does not work for AWStats. You only need to configure the domains you want to include in your AWStats reporting.

Create an example.com.conf file (where example.com should be replaced by the domain name you would like to include) in the location /home/user-data/www with the following content:

access_log /var/log/nginx/example.com.access.log;

(again, replace example.com with your own domain name). Repeat the previous for all domains you would like to monitor. To check your configuration run the following commands:

/root/mailinabox/tools/web_update
sudo nginx -s reload

This should run without problems if you haven’t made any mistakes. You should see logfiles appear for each configured domain in /var/log/nginx.

Configure AWStats

You need to create a separate configuration file for each domain, like in the nginx configuration. Somehow AWStats uses this file instead of the generic file for the static generation proces therefore we need to include those config options as well.

Create a file named /etc/awstats/awstats.example.com.conf with the following content:

LogFile="/var/log/nginx/example.com.access.log"
SiteDomain="example.com"
DirData="/var/lib/awstats/"
HostAliases="www.example.com"
LogFormat = 1

ShowSummary=UVPHB
ShowMonthStats=UVPHB
ShowDaysOfMonthStats=VPHB
ShowDaysOfWeekStats=PHB
ShowHoursStats=PHB
ShowDomainsStats=PHB
ShowHostsStats=PHBL
ShowRobotsStats=HBL
ShowSessionsStats=1
ShowPagesStats=PBEX
ShowFileTypesStats=HB
ShowOSStats=1
ShowBrowsersStats=1
ShowOriginStats=PH
ShowKeyphrasesStats=1
ShowKeywordsStats=1
ShowMiscStats=a
ShowHTTPErrorsStats=1
ShowFlagLinks=""
ShowLinksOnUrl=1

Repeat this for all the domains you have configured in nginx and want to actively monitor.

Create a location for publication

I’ve chosen to host the stats on a subdomain of my MIAB box. You create the domain stats.example.com (by creating a dummy email user in the MIAB admin page). Next, in the web section of the MIAB admin site change the directory for the static site to: /home/user-data/www/stats.example.com. In the TLS/SSL section provision the certificates for this new domain.

Copy all the images files from the AWStats package using the following commands:

cd /home/user-data/www/stats.example.com
cp -R /usr/share/awstats/icon .

Automation

To generate everything automatically I’ve chosen to use the logrotation moment and added everything to the nginx script. You do this by editing /etc/logrotate/nginx and change it so it looks like to following example.

/var/log/nginx/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 0640 www-data adm
	sharedscripts
	prerotate

      ## this next line is added:
      /usr/share/doc/awstats/examples/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl

      if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
			run-parts /etc/logrotate.d/httpd-prerotate; \
		fi \
	endscript
	postrotate
		invoke-rc.d nginx rotate >/dev/null 2>&1

      ## this nex line is also added, repeat this one for each domain you want to report on.
      /usr/share/awstats/tools/awstats_buildstaticpages.pl -config=example.com -dir=/home/user-data/www/stats.example.com**

   endscript
}

You’ll see the changes made in the pre and postrotate script, configure all domains separately in the postrotatescript by copying the line and change the domain name. To test your configuration and setup you can run lograte manually by using the command sudo logrotate -f /etc/logrotate.d/nginx

This should run with lots of output and you should see files appearing in /home/user-data/www/stats.example.com You can point your browser to stats.example.com/awstats.example.com.html and see how it looks.

Please remove the file awstats that might be installed in /etc/cron.d, this runs way to often and doesn’t do it like we prefer.

To make access easier and not to have to remember all the links you could create a simple index.html file located in /home/user-data/www/stats.example.com with in it the linkst to all the configured domains like:

<a href="http://stats.example.com/awstats.example.com.html">Example</a>
<a href="http://stats.example.com/awstats.other.com.html">Other</a>

And point your browser to the http://stats.example.com.conf

Security

If you don’t want to make the information publicly available we can introduce some basic security measure to have a user/password combination for basic authentication. As we don’t have apache or httpd-tools installed I used an online method of generating the hash password information: https://wtools.io/generate-htpasswd-online

Use this site to enter a user and password combination (for instance when using admin/admin something similar to this should appear admin:$apr1$y3uha0wx$EgVwp9d2c24zAJdU5bVK1/ )

Copy the result into a new file: /etc/nginx/htpasswd

To configure nginx create a stats.example.com.conf file (where stats.example.com should be replaced by the domain name you use) in the location /home/user-data/www with the following content:

location / {
    auth_basic           "Administrator’s Area";
    auth_basic_user_file /etc/nginx/htpasswd;
}

To enable this run the following commands:

/root/mailinabox/tools/web_update
sudo nginx -s reload

Next time you go to your statistics page you’ll need to enter the username and password to gain access.