In the vast landscape of social media platforms, Mastodon has emerged as a refreshing alternative. With its decentralized nature and commitment to user privacy, Mastodon offers a unique experience that fosters community building and meaningful interactions. However, mastering Mastodon requires navigating through different levels of proficiency, especially for someone coming from a traditional, centralized platform, like Twitter. In this article, we will explore the various stages of mastery on Mastodon and uncover the possibilities that each level brings.

Level 1: Picking a Home

As a newcomer to Mastodon, the first step is to select a server, also known as an instance. Mastodon is built upon a federated model, meaning that it consists of multiple interconnected servers rather than one centralized platform. Each server has its own community, rules, and moderation policies. This decentralized structure empowers users with the ability to choose an instance that aligns with their interests and values.

During this stage, it’s essential to research and understand the ethos of different instances. Some instances cater to specific topics or themes, such as art, technology, or activism, while others focus on fostering a safe and inclusive environment. By picking the right server, you can easily connect with like-minded individuals and immerse yourself in communities that resonate with your passions.

It’s worth noting that the decision of picking a server is not permanent or binding. Mastodon allows users to seamlessly move their account from one server to another. If you find that your chosen server doesn’t meet your expectations or you wish to explore new communities, you can easily migrate your account to a different server without losing your followers or the people you follow¹. This flexibility ensures that even if you initially choose a server that doesn’t align perfectly with your preferences, it’s not a big deal, and you have the freedom to make adjustments as you explore the Mastodon ecosystem.

At this point, you have pretty much everything you need to get started on Mastodon. Using the official website or mobile app, you can set up your profile, post your first toot², which I recommend it be an introduction post, and start exploring the platform. However, if you’re looking to take your Mastodon experience to the next level, you can consider other third-party apps that offer additional features and customization options. We’ll explore this in the next section.

Level 2: Experimenting with different apps

There are many third-party apps available for Mastodon, like Tusky and Tooot on Android, or iceCubes and iMast on iOS, that offer intuitive interfaces and a range of features that could enhance your experience. Experimenting with different apps allows you to find one that suits your preferences in terms of user interface, customization options, and additional functionalities.

As you delve into different apps, you’ll discover features like customizable timelines, advanced search options, and the ability to mute or block specific users or keywords. By familiarizing yourself with these features, you can tailor your Mastodon experience to suit your individual needs and preferences.

I personally haven’t evolved past this level, and I’m sure most people won’t either. However, if you’re looking to take your Mastodon experience even further and gain more control over moderation policies, server versions, data, and more; you can consider hosting your own instance which we’ll turn to in the next section.

Level 3: Hosting Your Own Single-User Instance

At this stage, you have the opportunity to take complete control over your Mastodon experience by hosting your own single-user instance which allows you to personalize your Mastodon environment to your exact specifications.

By hosting your own instance as a single user, you gain unparalleled freedom and flexibility. You become the sole administrator of your instance, allowing you to define the rules, moderation policies, and themes according to your preferences. With this level of control, you can curate a space that truly reflects your values and interests.

One of the major advantages of hosting your own single-user instance is the ability to customize the appearance and functionality to suit your needs. You can tailor the instance’s design, branding, and features to align perfectly with your personal style and requirements. Whether it’s the color scheme, layout, or additional functionalities, you have the power to shape your Mastodon experience exactly the way you envision it.

Hosting your own instance also eliminates any concerns about relying on external servers. You have full autonomy over the server maintenance, ensuring optimal performance, security, and data privacy. It goes without saying that hosting your own instance does require technical knowledge and resources, as you will be responsible for server setup, maintenance, and regular updates.

It’s worth clarifying that being the sole user of your instance doesn’t prevent you from engaging with others, and building your online presence. While your instance doesn’t aim to build a community, you can still connect with other users as if you were all on the same server.

Now, you don’t have to stop here. While hosting your own single-user instance is more than what most people will ever need, you can take it a step further and open your instance for registration to welcome other users. We’ll explore this in the next section.

Level 4: Fostering a Community

As you continue to explore Mastodon and expand your reach, you may consider opening registration for users on your instance, with the intention of fostering a community around shared interests and values.

By opening registration, you provide an opportunity for people who resonate with your content or the community you aim to build to join your instance and participate. This step allows you to create a space where individuals with similar passions can connect, collaborate, and engage in meaningful discussions.

As the administrator of your instance, you have the power to shape the community by defining the rules, themes, and moderation policies. Encourage respectful and constructive interactions, foster a supportive environment, and create spaces for people to share their thoughts, ideas, and creations.

Additionally, by welcoming others to your instance, you not only create a space for like-minded individuals to connect but also contribute to the decentralization and scalability of the Mastodon network. In a decentralized ecosystem like Mastodon, distributing the user load across multiple instances is crucial to ensure stability, performance, and avoid instances becoming overcrowded. Opening your instance to newcomers allows for a healthier distribution of users across the network, preventing the concentration of a large user base on a few instances. This decentralization is key to maintaining a vibrant and sustainable Mastodon community.

Wrap Up

Mastering Mastodon is an exciting journey that unfolds across different stages of proficiency. From selecting the right server to exploring various apps, hosting your own single-user instance, and potentially fostering a community, each level offers unique opportunities to shape your Mastodon experience. Embrace the flexibility, connect with others, and discover the diverse communities within Mastodon. Whether you’re seeking an alternative to traditional social media or championing privacy and inclusivity, Mastodon has something to offer at every step of your personal mastery. So, embark on this journey, make meaningful connections, and let Mastodon become your digital haven.

In the present digital epoch, it has become imperative for companies with an online presence to host a blog which is nothing more than a compendium of articles or posts, typically organized chronologically. This is not limited to companies obviously and anyone can, and is even highly encouraged to, run a personal blog. If you’re one of the fortunate who own a personal blog and are currently relying on a database to power it, you may be under the impression that it’s necessary for your blog to function properly. Wrong! In this article I’m going to explain why that’s not the case and why your blog doesn’t actually need a database. I will even go further and suggest that your blog should not use a database. While databases can be useful, if not mandatory, for certain types of websites, blogs are definitely not one of them.

One of the main reasons why blogs don’t need a database is that they are typically static websites. This means that the content on the website does not change frequently and isn’t customized for any particular visitor, and the website does not require any user interaction. In such a case, a database would be unnecessary as the information on the website can be stored in the form of HTML and CSS files.

Before going further, if your website has any dynamic functionality like user registration and login, or first party comment support, you’re out of luck and there’s no way around using a database; unless you’re feeling adventurous enough to delegate those functionalities to third party providers and hook your website onto them solely through the frontend. This adds a bit of complexity and calls for some technical knowledge though, which voids some of the benefits of static websites. Maybe you don’t need those dynamic functionalities to begin with and might be better off without them. Food for thought.

The Old School

The traditional method of running a blog is by utilizing a database to store the articles and a server-side script that dynamically generates the pages upon a user’s request. This method, commonly referred to as a “dynamic” approach, has been the prevalent norm for a considerable duration. However, this has several drawbacks.

First, the energy consumption is a paramount concern. Databases necessitate a substantial computational capacity, and oftentimes, they are run on servers that consume copious amounts of energy. This energy consumption leads to a substantial carbon footprint, thereby exacerbating climate change. Furthermore, the servers that host these databases are usually situated in data centers, which consume substantial amounts of energy to cool the servers and keep them operational. In addition, databases are frequently over-provisioned and underutilized, resulting in the squander of resources. This is a direct result of the fact that a database must be able to handle the peak load, even though the actual load is frequently much lower. This is a significant waste of resources, both in terms of energy and hardware.

Another drawback of using a database is the cost. Hosting a dynamic blog requires a powerful server, as well as a database. This can be expensive, especially for personal blogs which are not typically meant to generate revenue. Additionally, the more traffic a blog receives, the more powerful the server must be, and the more resources are required to handle the traffic. This can make it difficult for a blog to scale, and can also be a significant barrier to entry for those who are just starting out and do not have a lot of resources.

The third drawback of using a database is the slower page load times. When a user requests a page on a dynamic blog, the server must first query the database to retrieve the data, and then execute the server-side scripts to generate the page. This process takes time, and the more traffic a blog receives, the longer it takes to generate the pages. This can lead to a poor user experience, and can also negatively impact the blog’s search engine rankings.

The Hot New Thing

An alternative approach is to use a statically generated blog, which pre-generates all the pages and serves them as plain HTML and CSS files. This approach has several advantages over using a database besides the obvious benefits of not carrying the aforementioned drawbacks.

First, since the pages are pre-generated, they can be served directly by a web server without the need for any dynamic processing. This means that the hosting costs are lower, as you don’t need a powerful server or a database. Additionally, the static pages can be served directly by a Content Delivery Network (CDN), which can further reduce the hosting costs, and are often cached by the browser which also improves the page load times.

Another advantage of using a statically generated blog is the ability to generate pages offline. With a dynamic blog, the pages are generated on the fly, which means that the server must be online and accessible in order for the website to function. With a statically generated blog, however, the pages can be generated offline, and then uploaded to the web server. This can be useful for testing and brings a high degree of portability. Given that the website is nothing but static files, you can almost instantly move your website from one hosting provider to another.

The third advantage of using a statically generated blog is the increased security. With a dynamic blog, there is always a risk that the server-side scripts or the database could be hacked, which could potentially lead to sensitive information being compromised. With a statically generated blog, on the other hand, there is no server-side script or database to hack, which reduces the risk of a security breach.

I Don’t Want To Deal With HTML And CSS

If the thought of having to manually create and manipulate HTML and CSS files makes you sweat, don’t you worry. Using a statically generated website doesn’t mean that you need to become an proficient frontend developer. There are tools, so called static site generators (SSG), that allow you to create your blog using simple text files, such as Markdown, and then generate the necessary HTML and CSS files. This means that you can exclusively focus on creating content and customizing the design of your blog, by leveraging off-the-shelf themes.

One of the most popular SSG is Jekyll, which is written in Ruby. Jekyll takes your content, written in Markdown or Textile, and uses layouts to create a static website. Jekyll also supports data files, which can be used to store data in a structured format, such as YAML or JSON, that can be accessed in your templates.

Another popular SSG is Hugo, which is written in Go. It is a fast and flexible tool that can be used to build a wide variety of websites, including blogs. Hugo uses markdown files to generate your website, and it supports data files and template variables, which can be used to store and access data in a structured format.

It goes without saying that there are many more static site generators to choose from. Once the static website files are generated, they need to be hosted by a web hosting provider for the website to go online and be accessible from the internet. Here again, there’s no shortage of web hosting providers on the market. In fact, many would even be happy to host your static website for free! Providers like Netlify, Codeberg Pages, Github Pages, and Vercel immediately come to mind but I’m sure there are plenty others.

Wrap up

In today’s world, environmental sustainability is a top priority. And when it comes to blogs, statically generated sites are the clear winner. They require less energy and computing power, are much more secure than their dynamic counterparts, and are much easier to maintain. While I doubt that we can solve all our climate problems by making blogs static, I do believe that every bit of contribution towards that goal helps, however minute it seems. So if you’re looking to reduce your environmental impact and create a secure, cost-effective blog, be sure to go static!

Everybody needs to take notes, may it be for school, to have a handy grocery list in the store, or to keep a log of business expenses for accounting purposes. Some people use physical notebooks, some pick up whatever napkin happens to be in the immediate vicinity and roll with it for the day, and others, like myself, prefer to leverage digital notes. In this article, I’ll take you through my journey with note taking apps. We’ll go over my personal definition of a “good” note taking app, explore some of the options I used and the challenges I faced, and finally land on the solution I ended up adopting with a couple of learnings that emerged along the way.

The Beginning

My journey with digital note taking started with whatever default notes app happened to be on my phone. At first, I didn’t have any particular framework for note taking; it was just a random collection of digital post-it stickers. Similar story on the desktop, a structureless heterogeneous cluster of text files scattered all over the place.

Then, I started taking notes more seriously (pun intended) to capture knowledge, such as book summaries and highlights, things I learn from videos and documentaries, new vocabulary I come across, random ideas or questions I want to get answers to, and more. Before you know it, my notes catalogue started getting a bit heavy and it was apparent that I needed some sort of framework to better tag and organize all that knowledge. At the time, Evernote was the new kid on the block and it had some attractive features, so without putting much thought into it, I created an account and poured all my notes over to it.

I used Evernote for a long time, longer than I would want to admit. But one day, shortly after I’d begun getting serious about my online privacy, I had a “Oh shit!” moment that I still remember to this day.

The Rabbit Hole

I geared up and I ventured down the rabbit hole of privacy-friendly, and open-source, note taking apps. I set a few criteria to guide my expedition:

1. The service has to be free of charge, or offer a free plan;
2. It has to be offline and/or support end-to-end encrypted backup and/or sync; and
3. It must respect user privacy, so no tracking, ads, or telemetry.

If there’s one thing I would never accept, it would be having my notes up in the cloud in the clear¹, may that be temporarily for synchronization or permanently for backup. My notes hold so much information about me, from future plans, to areas of interest in life, to just general knowledge. I bet that even my IQ could be deduced with a reasonable degree of certainty using the right AI model. Now that I think of it, I would definitely see myself in the future training a model on my notes and delegating some decision making to it: a tailored virtual assistant of sort. I’m no AI expert and this does seem far-fetched today, but I wouldn’t be surprised if it were a thing even half a decade from now. Anyway, I digress.

During my research, StandardNotes stood out as a good candidate with its end-to-end encrypted backup and sync, and focus on privacy. It seemed to check all the boxes, so I gave it a shot. I created a free account and, once again, migrated all my notes off of Evernote into my StandardNotes account. I have to admit that this immediately felt like a downgrade; the feature set of StandardNotes’ free tier is rudimentary at best. But in the name of privacy, I sucked it up and worked around the limitations for a while. Thinking back, I realize that this was more of a “stop the bleeding” step than a permanent solution. Case in point, I never actually stopped exploring the free and open source note taking space for better options. Then, I came across Joplin.

At first, Joplin’s UI/UX looked out-dated, especially on mobile devices, but I was willing to be more lenient given that it’s a free and open source software maintained by a handful of generous people. What grabbed my attention was its self-hostable end-to-end encrypted capability. So I downloaded a copy of the app, set up a WebDAV server to handle the sync, and migrated all my notes over. After a few weeks of me getting used to its archaic UI, Joplin began setting itself as my permanent note taking solution. I started tinkering with various plugins, and even looked into making my own. All was great until the day the sync broke! My client was getting 503 errors from the sync server which corrupted some notes and rendered them unusable. Luckily, I had an offline backup of the affected files, so I managed to recover, albeit laboriously, from this crash. A few weeks later, another sync crash wiped my entire notebook. I wasn’t so lucky this time around, however, and ended up permanently losing some of my newer notes. This was the straw that broke the camel’s back. I couldn’t take it anymore; I had to find a better solution.

I decided to give StandardNotes another shot, but going with a self-hosted instance this time. This will ensure that I have full control over my notes’ backups, and that I enjoy a more decent set of features; or so I thought. So I migrated all my notes, once more, to my StandardNotes instance and started playing around with premium themes and extensions. The fact that a simple notes service required so many backend services, a.k.a micro-services, has never really sat well with me. I had the feeling that this level of complexity will eventually prove too cumbersome to maintain. And guess what? It did! After a recent update of the desktop client, my setup was brought to a halt. I was no longer able to connect to my self-hosted instance, running an old version of the server. It seemed like the new client version wasn’t backward-compatible and required a backend upgrade. When I tried to make that happen, I realized that the StandardNotes’ team overhauled their entire architecture. At this point, I wasn’t really down to learn the new setup, build new docker images, and get everything back online. It felt like a lot more work than a simple notes service should call for.

Refocusing

I took a step back, and went back to the drawing board. A quick cost/reward analysis confirmed that all of this friction wasn’t worth it. I realized that I didn’t really need the cross-device sync, since the vast majority of my notes fell under 2 categories: desktop, and phone. I seldom need notes from my phone when I’m on the desktop, and I almost never need notes from my desktop when I’m on my phone. So I decided to use 2 different note taking applications: vim with vimwiki for desktop notes, and my phone’s default notes app with cloud backup disabled. I suppose you know the drill by now: I migrated all of my notes, yes once again, from StandardNotes to vim and my phone’s default note app, hoping that this was the last time I perform this dance.

I’ve been driving this setup for weeks now and so far have a couple of takeaways. First, I’m struck by how pleasant it is to enter a typo’ed keyword into a search bar and watch the powerful fuzzy search engine instantly populate the page with extremely relevant results, the first one being the one I had in mind most of the time. I can’t remember a single time where this failed me. This made me realize just how mediocre, if not completely futile, StandardNotes’ search functionality was, particularly on mobile. Second, I never actually needed the cross-device sync or cloud backup for my notes. Offline backup, and segregated notebooks work just fine, check all the boxes with regards to privacy, and cost me practically no effort.

Before closing this off, I’d like to mention a couple other note services that I considered at some point, but wasn’t entirely sold on so I never took them for a test drive. Obsidian is more than just a note taking app. With its graph features and automatic note linking, it appears to be more of a knowledge management software; way more than I actually need for my personal use. Plus, the sync is a paid service with no option to self-host. Logseq is another solution that briefly caught my attention until I learned that it had no native sync support; the only way to sync data was to go through Github or iCloud.

Wrap up

If there’s a lesson to be drawn from this journey, it has to be that the most complex solution isn’t always the right one. I would argue that the simplest one turns out to be the best, more often than not. It just took me multiple migrations, hours if not days of tinkering around with various setups, and quite a bit of frustration wrestling with poor-UX software and dealing with lousy error handling, to realize it.

That being said, their introductory free tier leaves a lot of be desired. It could work for users with basic note taking needs but if you want to organize your notes in nested folders, use multiple editors like Markdown and Rich text, switch between a variety of themes, or schedule regular backups, you have to go with a premium plan. At $12/month, or $5/month if billed yearly, their cheapest plan is definitely at the higher end of the spectrum, especially that the service isn’t complex enough to warrant the hefty subscription fee in my view. It should come at no surprise if a Standard Notes subscription is considered a quite hard expense to justify by regular users who don’t fiddle with notes on a daily basis, or heavily rely on note taking in a professional capacity.

Fortunately, the Standard Notes team is nice enough to open source all their stack for anyone to self-host for personal use. On top of the obvious benefit of enjoying all the premium features free of charge, self-hosting comes with the advantage of full data control. The official documentation around self-hosting published by the Standard Notes team is clear and straightforward. They put together a docker-compose file that defines the entire stack along with a convenient script to create configuration files, bring the stack up and down, view logs, and more.

Thanks to the power of containers, you can be up and running in a matter of minutes, unless you’re running an ARM chip like a Raspberry Pi. Sadly, Standard Notes don’t provide official Docker images for ARM processors. You can either pick one of the third-party images made available by random users, or build your own. I tend to go with the latter option because it grants more control over the software version packed in the image, and most importantly it obviates the inherent security risk that comes with running untrusted Docker images¹. In the next section, we’ll go over the steps to build Docker images from source compatible with ARM processors, or any target architecture for that matter. If the official Docker images work on your processor architectures, feel free to jump straight to the “Premium extensions” section.

Building Docker images for ARM

First, we need to pull the code of the service we want to build a Docker image for. Let’s go with the auth service.

git clone https://github.com/standardnotes/auth

Then, from within the auth folder, let’s switch to the latest tag, or any other target version you want to use:

cd auth
git checkout 1.46.1

If you’re not sure what’s the latest tag, you can either check it directly on Github or list all available tags using:

git tag --list

If you’re building the image on the same machine that’s going to ultimately run the container, all you have to do is run a typical Docker build command like:

docker build -t arm-auth:1.46.1 .

However, if you’re building the image on a separate machine, perhaps because your server doesn’t have enough resources to carry out the build process, you can target a specific CPU architecture using buildx. Here’s what the command would look like:

docker buildx build --platform linux/arm/v6 -t arm-auth:1.46.1 . --load

Here, we’re targeting the version 6 of ARM and tagging the image with arm-auth:1.46.1. If you’re running a different version of ARM make sure to update the --platform flag accordingly.

As a side note, this will only work if linux/arm/v6 is loaded in the current buildx builder. To check the platforms supported by your buildx builder, run:

docker buildx ls

If your target platform is not currently loaded in buildx, try running a binfmt container like the following:

docker run --privileged --rm linuxkit/binfmt:a17941b47f5cb262638cfb49ffc59ac5ac2bf334

Now that the image is built, we need to move it to the server where it’s supposed to run. To do so, we first need to save it in a tar archive using the following command:

docker save arm-auth:1.46.1 -o arm-auth.tar

Then, after transferring it to the server via rsync, a USB key, or whatever other means deemed most convenient, we should load it on the server using:

docker load -i arm-auth.tar

Now, if we list all Docker images using docker images we should see our new arm-auth image. All that’s left to do is reference this image inside the standalone docker-compose file provided by Standard Notes.

It goes without saying that all the steps we’ve gone through in this section would need to be repeated for each one of the official Standard Notes services, which currently are:

• syncing-server-js;
• api-gateway; and
• files.

On top of their own services, Standard Notes use Redis for cache and MySQL for storage. The latter can be replaced with a MariaDB ARM image like linuxserver/mariadb while the former can be used as is; it already has a Docker image for ARM.

Premium extensions

Once your self-hosted Standard Notes instance is up, you can connect to it by pointing your Standard Notes client to your instance, under the “Advanced” section of the account creation or login view. You first need to create an account, which will be a “Basic” one by default, equivalent to the free tier. To be able to use premium themes and editors you need to upgrade your account with a couple of commands. Unfortunately, having a premium account in your self-hosted instance doesn’t automatically give you access to premium themes and editors. Standard Notes don’t give out their official premium extensions for free but you can load other community-built alternatives. Here are a couple of sources to get you started:

• https://snexts.github.io/
• https://github.com/jonhadfield/awesome-standard-notes

To load an extension, head over to your desktop client under Preferences > General > Advanced Settings. Then, enter the extension URL in the “Install Custom Extension” input field and hit “Install”.

Wrap up

Self-hosting Standard Notes is strikingly straightforward, barring few extra steps that require some Docker knowledge when working with an ARM chip. In this article, we’ve gone over everything needed to setup a Standard Notes server that’s not covered in the official documentation.

If you have any questions or face difficulties with the instructions laid out above, feel free to reach out on Mastodon.

Long gone are the days when websites consisted of static HTML pages styled with basic CSS, when links actually directed users to new web locations instead of calling a Javascript function. Now, websites (or should I call them web apps?) have grown so complex that browsers had no choice but to turn into operating systems. This made for a much richer user experience with so many possibilities; you can do online banking, play video games, join video conferences, shop, and even install apps, all within the same application: the browser. It’s obvious that the more complex any software gets, the more chances there are for security vulnerabilities to emerge, and the browser is no exception. The surge of browser CVEs we’ve witnessed in recent years is a good testament to that. Additionally, the more user interactions are made possible in the browser the more attractive it becomes to marketers and companies looking for new revenue streams. Online advertising, which is fueled by online tracking, has become so lucrative that it’s consistently been the top revenue category for so many big tech corporations. So, should we just throw our hands up in the air and accept our imposed destiny? Do we have to give up our privacy if we’re to do any meaningful browsing on the internet?

Using a sound browser will go a long way in mitigating the risk of privacy violations. Like anything else in life, it’s important to use the right tool for the job. If you’re going on a road trip across the country, you’d want to drive the right vehicle, have spare tires, make sure the engine is healthy and won’t overheat, plan charging breaks if you’re going electric, and so on. The same applies to browsing the internet. In this article, I’ll go over different security and privacy measures implemented in Firefox, my favourite browser.

Before we dive in, let me note that my decision to run Firefox as my daily driver is not a political one or based on Mozilla’s management, work conditions, or product line. I’m only focused on the software itself and how it serves my personal internet browsing needs.

HTTP header sanitization

In this day and age, web pages have become remarkably complex to the point where it’s quite rare to find web services that don’t pull resources from other domains, may they be fonts, images, videos, scripts, or other types of resources. When a browser goes out to fetch external resources, it attaches the original URL to every request in the HTTP Referer header. The entire URL that the user had initially put in their browser address bar ends up transmitted to all the domains that the page being visited depends on. To give you an idea, if a user was reading an article on a news site in dark mode with big font (URL: https://www.allthenews.com/breaking-news-read-now?mode=dark&font-size=big); and this site loaded “share” buttons from Google, Twitter, and Facebook; all of these companies would be made aware of the article the user was reading and the preferred settings for article consumption.

Firefox trims the path and query parameters from the HTTP Referer header for all cross-origin requests by default. So in our previous example the URL would be turned into https://www.allthenews.com/ when communicated as a referrer to Google, Twitter, and Facebook, thereby reducing the amount of leaked user information.

Cookie store isolation

When it comes to cookie management, Firefox has really stepped up their game. I don’t think any other browser handles cookies nearly as well. Firefox not only blocks cookies from domains that were identified as trackers, it totally cripples cookie-based tracking with its Total Cookie Protection. It works by operating completely isolated cookie jars, each dedicated to a website that the user explicitly visited. By way of illustration, cookies set when the user visits website A are only ever attached to requests triggered by user actions on website A, including third-party cookies. This is exceptionally powerful because it means that a third-party cookie coming from Facebook, for instance, while browsing a news site will never make it back to Facebook when browsing any other website that uses Facebook’s assets.

In addition, Firefox’s Enhanced Cookie Clearing (ECC) allows you to wipe out all the data that were created by a specific website. This include first and third party cookies, local storage data, settings, and cache. This is different than the typical “delete website cookies” setting you’ll find in other mainstream bowsers in that ECC not only deletes data that belong to the selected website, but also all other data that were saved in your browser while visiting that website. Let’s say you’re on recipes.com that pulls in some assets from google.com, while also being directly logged into google.com in a separate tab. Clearing cookies of recipes.com using ECC will have the following effects:

• Delete all the data created by recipes.com
• Delete all the data created by google.com while browsing recipes.com. This means that we’ll remain logged into google.com in the second tab. This is extremely potent as it grants you the ability to make your browser effectively forget about all your activity on a given website.

Process isolation

Every time you visit a website with Javascript enabled, you run code that you’ve most likely never seen on your computer¹. The vast majority of browsers do a great job containing this code in a tight sandbox to prevent malicious out-of-scope access, but not all enforce good segregation within the sandbox. Firefox goes to great lengths to isolate code pulled from the internet that runs on your machine. With its Site Isolation, also called Project Fission, each website is loaded in a separate Operating System (OS) process. So if you visit “example.com” and, in a new tab, load “example.org”, these 2 websites’ code will run in 2 OS-segregated processes, each with its own isolated memory. And this isn’t specific to tabs; if “example.com” had an iframe that loaded content from “example.org”, the same thing would happen: Two processes would be spawned, one for each domain. This drastically improves protection against timing attacks like Spectre and Meltdown where one process can illegitimately peak into another’s memory. To see Firefox processes type “about:processes” in the address bar and hit “Enter”.

Moreover, Firefox is smart enough to also account for Public Suffix List² domains where multiple sites can be served as different subdomains of the same domain. For instance, if you were to load “my-site.codeberg.page” and “another-site.codeberg.page”, they would each get a separate process because they would be considered two different websites even though they share the same domain, since this domain is part of the Public Suffix List.

Session isolation

Now, let’s go up few layers and look at what Firefox does at the session level. While there’s no built-in session separation beyond Private Browsing in Firefox, their team has built the Multi-Account Containers add-on which takes compartmentalization to the next level. Every container is a fresh browser session with its own storage and cookie store. Think “Private Browsing” but not limited to a single private session. This is particularly convenient when you want to log into multiple accounts on the same website. Furthermore, all the security and privacy measures we touched on so far are maintained inside each container. When you first visit a website in a container, Firefox remembers that and asks you the next time around if you’d like to assign that website to that container. Replying yes makes Firefox always open that website in the chosen container without you having to do so every time. Who said you had to pick between privacy and convenience again?

You can also set a separate Virtual Private Network (VPN) per container. For example, if you want to use a VPN when shopping online you could create a “shopping” container and configure it to always use your VPN³.

Profiles

To push compartmentalization even further, Firefox allows you to manage multiple profiles within the same installation. A profile is nothing more than a set of user information, like bookmarks, saved passwords, settings, etc. While using profiles is generally not needed, there are few cases where it comes in very handy. Imagine dealing with a website that doesn’t work properly with Firefox strict tracking protection mode, which you should always have on by the way. You could, short of ditching that website and finding a better alternative, spin up a new profile where you don’t use strict tracking protection mode for the sole purpose of visiting that website. This can apply to anything that’s not impacted by the Multi-Account Containers add-on like bookmarks, extensions, and themes.

Wrap up

Well that was a lot of material! We’ve covered various security and privacy features that come with Firefox out of the box, in addition to an add-on that brings a new dimension of compartmentalization to the mix. Things like cookie store, session, and process isolation; HTTP header sanitization; and more. In my view, this makes Firefox the best browser, at the time of this writing, for a privacy-conscious internet user like myself.

If you know a free and open-source browser that offers all the guarantees mentioned in this article, please bring it to my attention; I’d love to see how it compares to Firefox.

In this article, we’ll learned a bit about DoH with a quick refresher on DNS and how it works, and go over a few strategies to improve online privacy by securing DNS.

What’s DoH?

The Domain Name System (DNS) is the system used to identify computers on the internet. Computers can only communicate with one another if they know each other’s IP addresses. But IP addresses, which are basically a bunch of numbers bundled together, are hard to memorize. If we had to use IP addresses to access websites, the web wouldn’t have taken off the way it did and you wouldn’t be reading this article online today. DNS was invented to accommodate humans, not machines.

Every time you type a URL in the browser, it issues a DNS a query to your DNS server in order to resolve the IP address of the website you’re trying to visit. The same thing happens when you open an app on your mobile device, when your smart light bulb phones home to fetch the most up-to-date brightness level it should shine at, and when you add a new show to your list on your smart TV Netflix app. Basically, every single action you make online triggers one or more DNS queries.

However, DNS was not built with privacy in mind. All DNS queries are routed through the internet in plain text. This means that anyone sniffing traffic on a network, or acting as a proxy to the internet, like an ISP or an enterprise router, can see the web locations that everyone on that network is visiting. While watching DNS traffic alone doesn’t give out information about the interactions between a client and a given website, it does paint a detailed picture of the web locations that a user has visited, an estimate of how long they have been on each website, the apps they’re using, and the type of Internet-of-Thing (IoT) devices they have installed in their homes, if any. It goes without saying that this is extremely detrimental to one’s online privacy. Fortunately, there are solutions to this problem.

One way of protecting one’s DNS queries from snooping eyes is to use encryption, like with DNS over TLS (DoT) or DNS over HTTPS (DoT). In this article we’ll focus on DoH which routes DNS traffic in an encrypted HTTPS tunnel. The client establishes a secure connection with the DNS server and funnels all DNS queries through it. This effectively encrypts DNS communications and renders them inaccessible to spying third parties. Now, let’s explore a few options of leveraging DoH to protect online activities¹ and improve privacy.

Client Settings

Many browsers² nowadays offer the option to configure a custom DoH server. However, this kind of configuration only applies to the activity happening in the browser and as mentioned previously, not all web requests originate from a browser. If we want to protect all DNS traffic emerging from a network, say a user’s home network, we should configure the network to use a local DNS server under our control that will turn around and delegate DNS resolution to a trusted upstream provider using DoH. First, let’s see how we can build this local DNS server.

Local DNS Server

Cloudflare built a nice little application called cloudflared that converts plain DNS queries to DoH. It’s free, open-source and easy to run. If you’ve read any other post on this blog you must’ve realized how much I love containers. So let’s build a cloudflared Docker image to run as a local DNS server. Unfortunately, Cloudflare doesn’t offer an official Docker image for cloudflared but we can make our own fairly easily. To do so, in a file named Dockerfile put the following content:

FROM alpine:3.15

RUN apk add --no-cache bash

RUN wget -q https://github.com/cloudflare/cloudflared/releases/download/2022.1.2/cloudflared-linux-arm \
	&& chmod +x cloudflared-linux-arm \
    && mv /cloudflared-linux-arm /usr/local/bin/cloudflared

Here, we’re using alpine version 3.15 and cloudflared version 2022.1.2 but more versions might have been released since this article was published. Feel free to update these versions to the latest.

In order to use this Docker image we can build a docker-compose service to run cloudflared. Alongside the previously created Dockerfile, let’s make a new file called docker-compose.yml with this content:

version: "3.8"

services:
  cloudflared:
    build: .
    ports:
      - "53:5053"
    # replare <UPSTREAM SERVER> with the URL for the upstream DoH server
    # e.g.: https://doh.libredns.gr/dns-query
    entrypoint: bash -c "cloudflared proxy-dns --port 5053 --address 0.0.0.0 --upstream <UPSTREAM SERVER>"
    restart: unless-stopped

Make sure to replace <UPSTREAM SERVER> in the entrypoint command with your DoH server of choice. PrivacyGuides lists a few options you can pick from if you don’t already have a favourite DNS server. At this point, you have everything you need to convert all DNS queries in your network into DoH. Here are the steps to accomplish this:

1. Run docker-compose up cloudflared from the folder where you put the Dockerfile and docker-compose.yml files to spin up a cloudflared container. Ideally, this should be done on a machine that’s constantly running on your network with a static IP address. A Raspberry Pi or a home server are great candidates for this.
2. Configure your network’s DHCP server to use the machine where cloudflared is running as its default DNS server. This will automatically instruct all devices on the network to use the cloudflared container for DNS resolution. If you don’t have control over your DHCP server, or it’s too complicated to reconfigure at the moment, you can always start off by manually editing the DNS configuration on your most-used devices.

DoH in Pihole

If you already have a Pihole docker container running in your network and serving DNS queries, you can now set the cloudflared container as an upstream DNS server in Pihole and automatically upgrade all DNS queries to DoH. We’ve seen in a previous article how to set up Pihole using Docker. We’ll use the same docker-compose file here to illustrate how to integrate cloudflared.

First we need to place the Dockerfile file we created in the previous section inside a folder called cloudflared. Then, using our previous Pihole docker-compose file, we can add a new service for cloudflared as shown below:

version: "3.8"

services:
  pihole:
    # ...
    environment:
      # ...
      - PIHOLE_DNS_=172.31.0.200#5350
    # ...
    depends_on:
      - cloudflared
      - dhcphelper
    # ...

  dhcphelper:
    # ...

  cloudflared:
    build: ./cloudflared
    environment:
      # set UPSTREAM_PROVIDER to the URL for the upstream DOH server
      # e.g.: https://doh.libredns.gr/dns-query
      - UPSTREAM_PROVIDER=
    entrypoint: bash -c "cloudflared proxy-dns --port 5053 --address 0.0.0.0 --upstream $$UPSTREAM_PROVIDER"
    networks:
      backend:
        ipv4_address: '172.31.0.200'
    restart: unless-stopped

networks:
  # ...

volumes:
  # ...

You’ll notice that the cloudflared service looks similar to the one we built in the previous section. Here, we don’t need to expose the port 53 to the host because the only client connecting to the cloudflared container is the Pihole container running in the same Docker network. Also, we have to set a static IP address for the cloudflared container and add it to the PIHOLE_DNS_ environment variable of Pihole in order for it to be used as an upstream DNS server.

With the modifications above, restart your Pihole container by running docker-compose down and bringing it back up with docker-compose up pihole, and you should have a cloudflared container running alongside Pihole, ready to receive requests.

Wrap up

Congratulations, you made it! You now understand why protecting your DNS traffic is paramount to improving your online privacy and have in your toolbox 3 strategies for doing so, some more potent than others. In case you can’t run a full-fledged Pihole and cloudflared setup on your network, or don’t have the time to set that up yet, at least configure your most-frequently-used browser to resolve DNS through DoH. It takes almost no time, and goes a long way in getting you to a better place when it comes to your online privacy.

Password managers have become a crucial tool that every online user must rely on. Since they handle extremely sensitive data, like login credentials, credit card information, secret notes, and more, careful consideration is recommended when choosing a password manager. This article goes over the phases I’ve gone through in my experience with password managers, the different solutions I used, and how I got where I am today.

First Password Manager

My journey with password managers started way back when I used the “save password” feature in the Chrome browser. I was still “generating” passwords myself but relying on Chrome to save and automatically insert them when I’m on the login page of various websites. At that time, I didn’t really have too many accounts - probably no more than a dozen. But as the web started turning into a plethora of sign-up walls, where you can’t hover on a button without having to log in first, I quickly ran out of ideas to create new unique passwords. This is the point where I knew I needed a proper password manager.

Around this time, Lastpass was one of the most dominant actors in the field of password management and they were doing some good work. So I decided to give Lastpass a try and I really liked it. The convenience of not having to come up with a “secure” password that I haven’t used before when signing up on a new website, brought such a relief to my account creation flow and reduced a considerable amount of friction. Lastpass had some issues however. The data breach of 2015 was the first thing to sound the alarm for me. I started to realize that fully trusting an entity with my most valuable data, the keys to every single account I own, was probably not a good idea. To make matters more scary, Lastpass does not publish their source code for others to view, analyze, and even contribute to. Security by obscurity is never the way to go. Furthermore, they include third-party trackers in their codebase which is a very bad practice for a security-critical service like Lastpass.

I’m not trying to sabotage Lastpass here, or imply that their security is lacking. As a matter of fact, their security model seems to be solid. As far as I know, there has never been any breach that exposed user sensitive data like passwords in clear text. All I’m saying is that it wasn’t the right fit for me. Not to mention that their recent up-sell push to convert free users to premium by restructuring their pricing and feature models just didn’t sit right with me. They were turning into another Big Tech player, and it was time for me to walk away.

Gaining back control over my data

When I started using Lastpass, there weren’t many options to choose from. But few years later, other password managers started popping up and one of them was particularly good at distinguishing itself amongst the privacy-focused community. This password manager is no other than KeepassXC. I believe it’s the first open-source password manager that I was made aware of and I instantly fell for it. It’s a free, community-driven, offline password manager that I simply couldn’t ignore. Next thing you know, I was migrating all of my passwords off of Lastpass and celebrating the addition of yet another open-source tool to my arsenal.

The only problem that I had to solve was synchronizing data across multiple devices. With a cloud-based service like Lastpass, this issue is taken care of by the service itself and changes on one device are replicated across the others automatically. With an offline password manager like KeepassXC on the other hand, data synchronization becomes the responsibility of the user. So, I moved all my credentials to a KeepassXC database (DB), and used a cloud service to regularly back it up. When I needed a fresh version of my DB in any of my devices, I either transferred it directly within my home network, or pulled it from the cloud service provider, and used an open-source client to read it. To make things simple, I also only ever made changes to the DB on my computer, and stuck to read-only mode on the other devices. You can imagine how this could sometimes prove tedious, especially when I needed to update existing or create new entries in my credentials list from a device other than my main computer. I started to seriously miss the convenience of the seamless synchronization I enjoyed with Lastpass, but I wasn’t ready to downgrade my security and privacy just for that.

The best of all worlds

Luckily, there was this new kid on the block, a new solution that ticked all the boxes for me - it’s open source, free¹, and self-hostable! This meant that I could get all the benefits of data control I have with KeepassXC and the convenience of seamless multi-device synchronization. The solution I’m referring to is Bitwarden. Ever since I launched my own instance of Bitwarden, I’ve never looked back. I truly love this piece of software and am so grateful to the amazing people behind it. Plus, the beauty of it all is that when you host your own instance you get all of the premium features for free!

Wrap up

As you see, I wasn’t fortunate enough to pick a winner right from the start. I began my journey naive, prioritizing convenience without paying much attention to security, let alone privacy. As I learned more about password managers, I shifted my priorities and started giving more weight to security and privacy, even at the expense of convenience at times.

If you have comments or suggestions, or if you just want to strike a conversation on this topic, feel free to hit me up on Mastodon.

Bitwarden is a password manager that allows users to generate and store strong passwords. It also handles other types of data like secure notes and credit card information. At the time of this writing, it is one of the best password managers out there because in addition to offering strong and zero-knowledge encryption, the codebase is open source. This means that anyone can inspect the code and run it for their personal use. In this article, we’ll go over the steps to build a fully functioning Bitwarden instance that anyone can run on a server at home.

Docker setup

Let’s start by setting up a docker-compose.yml file to run the Bitwarden server:

version: "3.8"

services:
  bitwarden:
    container_name: "bitwarden"
    image: vaultwarden/server
    ports:
      - "3012:3012"
    volumes:
      - data:/data

volumes:
  data:

Here, we’re using vaultwarden/server image which is a rust-based version of Bitwarden server. We’re exposing a TCP port to be able to communicate with the container from outside of Docker network. Then, we create a volume and mount it on /data inside the container. That’s where Bitwarden stores its data, including users, vaults, and attachments.

If we bring up this container and try to access Bitwarden through https://localhost:3012, it will not work. Bitwarden requires all communications to go through a TLS tunnel. In other words, we need to use HTTPS instead of HTTP. We’re going to use a second container running Nginx to handle TLS for us and proxy requests to Bitwarden’s container.

version: "3.8"

services:
  bitwarden:
    # ...
    depends_on:
      - nginx

  nginx:
    image: nginx:1.21.0-alpine
    ports:
      - "23984:443"
    volumes:
      - ./nginx/ssl:/etc/ssl:ro
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
    restart: unless-stopped

volumes:
  data:

In this configuration, we’re declaring a new service nginx using the alpine image of nginx, exposing a port so that the container can be reacher from outside Docker’s internal network, and specifying a couple of read-only volumes. We’re also instructing Docker to automatically restart this container unless it was manually stopped. This can help increase availability by automatically recovering from sudden crashes.

The final result looks like follows. Notice that we introduced a environment variable ADMIN_TOKEN that can be used to access the admin section of Bitwarden. More on how to do this later.

version: "3.8"

services:
  bitwarden:
    container_name: "bitwarden"
    image: vaultwarden/server
    environment:
      - ADMIN_TOKEN=SOME_SECRET_TOKEN
    volumes:
      - data:/data
    depends_on:
      - nginx

  nginx:
    image: nginx:1.21.0-alpine
    ports:
      - "23984:443"
    volumes:
      - ./nginx/ssl:/etc/ssl:ro
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
    restart: unless-stopped

volumes:
  data:

TLS Support

Now that we have our containers set up, it’s time to configure Nginx to handle TLS connections and forward them to Bitwarden’s container. Let’s create a server configuration file named bitwarden.conf and place it under nginx/conf.d/. This path relative to wherever you place the docker-compose.yml file.

server {
    listen 443 ssl http2;

    # Allow large attachments
    client_max_body_size 128M;

    location / {
        proxy_pass http://bitwarden:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://bitwarden:80;
    }
}

This is a pretty typical Nginx proxy configuration where we define a port to listen to along with protocols we want to handle. Next, we have a directive to allow large attachments¹ and we declare few paths and how they should be handled. We’re not going to dive into each directive used here but If you want to know more about how to configure Nginx, I encourage to check out their official documentation.

If you’ve been following along you’ll notice that we haven’t addressed the SSL connection yet, and without it our setup will not work. So let’s figure that out. In case you’re planning to use a real domain name for your Bitwarden instance, you can skip this section and jump directly to Nginx Configuration.

In order to make a self-signed TLS certificate, first we need to generate a private key and a certificate for our Bitwarden server using the following command.

OUT_FOLDER=/path/to/ssl
DOMAIN=your.bitwarden.domain

openssl req -x509 -nodes -days 365 -newkey rsa:4096 \
        -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:$DOMAIN\nbasicConstraints=CA:true")) \
        -keyout $OUT_FOLDER/private/nginx-bitwarden.key \
        -out $OUT_FOLDER/certs/nginx-bitwarden.cert \
        -reqexts SAN -extensions SAN \
        -subj "/C=US/ST=New York/L=New York/O=Company Name/OU=Bitwarden/CN=$DOMAIN"

This will generate a new public key nginx-bitwarden.key using RSA with a key length of 4096 bits, and a self-signed TLS certificate nginx-bitwarden.cert valid for 365 days in the private/ and certs/ folders respectively. These folders should be placed under the folder ssl/ that lives alongside our docker-compose.yml file, so make sure you set the $OUT_FOLDER variable properly. In addition, the $DOMAIN should be set to the fully qualified domain name of the machine where you’re planning to run Bitwarden and Nginx. It’s not complicated to assign an FQDN to your local machine using a local DNS, especially if you’re running Pihole. If you’re interested in getting Pihole set up locally with Docker, check out this article.

Nginx Configuration

Now that we have our certificate and private key, we should tell Nginx where they are located in order to use them for TLS connections.

server {
    listen 443 ssl http2;

    ssl_certificate      /etc/ssl/certs/nginx-bitwarden.crt;
    ssl_certificate_key  /etc/ssl/private/nginx-bitwarden.key;

    # ...
}

It’s recommended to generate a Diffie-Hellman file for stronger connections and use it in our Nginx configuration. We can generate one with the command:

openssl dhparam -out $OUT_FOLDER/certs/dhparam.pem 4096

To be honest, I haven’t yet looked at the functions of this Diffie-Hellman file to fully understand how it improves security. But if you know more about it and are interested in contributing your knowledge to this article, feel free to reach out to me on Mastodon.

The complete Nginx configuration after linking the .pem file should look like follows.

server {
    listen 443 ssl http2;

    ssl_certificate      /etc/ssl/certs/nginx-bitwarden.crt;
    ssl_certificate_key  /etc/ssl/private/nginx-bitwarden.key;

    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    client_max_body_size 128M;

    location / {
        proxy_pass http://bitwarden:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://bitwarden:80;
    }
}

Finally, we have our containers configured to run Bitwarden. All we need do to in order to bring them up is run:

docker-compose up -d bitwarden

Once the containers are up, you’ll be able to reach Bitwarden through its domain name. Given our example configuration, that would be https://your.bitwarden.domain. The first time you open the page, your browser will most likely complain about an insecure connection and display a flashy warning. If it doesn’t, stop using this browser and get yourself a real one! This is due to the self-signed certificate. Since the certificate is not signed by a Certificate Authority (CA) present in the browsers or the OS’s root CA store, the browser considers the connection insecure. You can add an exception for this certificate in your browser so that it doesn’t freak out every time you access your self-hosted Bitwarden. Similarly, you will have to install this certificate on your device and trust it, otherwise the OS will prevent Bitwarden’s app to communicate with our running container. To do so, send the nginx-bitwarden.crt file we generated in the TLS Support section to your device², open it and follow the installation steps. It should be straightforward in most OS’s but it’s always safe to follow the official guide to make sure you cover all the steps. For instance, in iOS, on top of installing the certificate you have to explicitly trust it for TLS connections.

Admin Access

Like we’ve seen in a previous section, in order to unlock the admin panel we need to set a token in the ADMIN_TOKEN environment variable. Let’s generate a token using the following command.

openssl rand -base64 48

Once Bitwarden’s container is restarted after setting the admin token, you can access the admin panel at https://your.bitwarden.domain/admin.

Wrap up

We finally made it. We built a docker setup running a container for the Bitwarden server with an Nginx proxy handling TLS connections using a self-signed certificate. This grants us full control over our credentials and any other data we choose to store in Bitwarden, all without having to trust any third party to handle this for us.

Running Pihole on Docker is pretty straightforward, but things start to get a bit complicated when it comes to enabling DHCP - using Pihole to serve DHCP requests. With Docker’s default bridge network mode, we can’t use Pihole as a DHCP server. So we have two options: (1) use the host network mode, or (2) run a DHCP relay (more on this later).

Option (1) is the easiest because all we’d have to do is set network_mode: "host" in the service definition, but it comes with a considerable disadvantage. It undermines the network isolation provided by Docker’s bridge driver, not to mention that it will take up ports from the host’s network which could be a concern depending on what’s running on your server. Option (2) allows us to stick to the bridge mode but adds a good amount of complexity. If you’re anything like me, you’ll favour security and try to maintain Docker’s network isolation.

Option (2) it is. Make sure your cup of coffee is full, and let’s dive in!

Pihole on Docker

First, let’s build a docker-compose.yml file with a basic configuration to run Pihole.

version: "3.2"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    environment:
      - TZ=America/New_York
      - WEBPASSWORD=very-secure-password # Choose a password for admin
      - PIHOLE_DNS_="1.1.1.1;1.0.0.1" # Set upstream DNS servers
      - ServerIP="10.10.0.10" # Your host's external IP
    volumes:
      - pihole:/etc/pihole/
      - dnsmasqd:/etc/dnsmasq.d/
    restart: unless-stopped

volumes:
  pihole:
  dnsmasqd:

In this example, we define a service called pihole using the official Pihole Docker image. Then, we publish few ports to get DNS requests (UDP port 53) forwarded to the container running Pihole, and to allow access to the web panel (TCP port 80). After that, we set some environment variables:

• WEBPASSWORD¹: The password to use when logging into the admin panel.
• PIHOLE_DNS_: A semicolon separated list of upstream DNS servers. These are the servers Pihole will reach out to in order to resolve DNS queries.
• ServerIP: The external host IP. This is the IP that machines on the network will send their DNS queries to. In other words, this should be the hosts IP on the LAN network.

Last, we define a couple of volumes to persist configuration across multiple container restarts.

DHCP through Docker’s Bridge Network

At this point, we have a working Pihole deployment ready to manage DNS on the host’s network. Since we didn’t specify the network mode in the docker-compose file, the container is provisioned using the default driver: bridge network. This means that Pihole lives in a separate network than the host along with other machines on the LAN. Docker daemon bridges these 2 networks and forwards ports as specified in the docker-compose file. This works great for DNS, but not so much for DHCP. If we tried to enable DHCP on Pihole’s web interface, it would unfortunately not work. To understand why, let’s go over a brief overview of how DHCP works.

When a client joins a network it starts broadcasting a DHCP discovery request on that same network on UDP port 67. If there’s a DHCP server listening, it will respond to this request with a lease offer that the client then accepts². This is how machines get assigned IP addresses dynamically when joining a network.

DHCP is not routable however, so discovery requests don’t span across different networks. In our setup, since Pihole is running in a Docker container with bridge network mode, it lives in a separate network (Docker internal network) than the LAN, so DHCP discovery requests stop at the edge of the LAN and never make it to Pihole. To solve this, we need a DHCP relay connected to both the LAN and Docker’s internal network. It will intercept discovery requests on one network and forward them to Pihole on the other.

With the theory out of the way, let’s move on to a practical solution to our problem. We will use dhcp-helper as a DHCP relay. First, we create an small image with that package and place the Dockerfile in a folder called dhcp-helper.

FROM alpine:latest
RUN apk --no-cache add dhcp-helper
EXPOSE 67 67/udp
ENTRYPOINT ["dhcp-helper", "-n"]

The file content is self explanatory. We’re using an alpine image, adding the dhcp-helper package, exposing the UDP port 67 in order to receive DHCP discovery requests, and we’re running the helper command at startup.

The next step is to update the original Pihole docker-compose file to include the DHCP relay. We will need to add a service for the relay, an additional network with a fixed IP for the Pihole container, and make the Pihole service depend on the DHCP relay.

version: "3.2"

services:
  pihole:
    container_name: pihole
    # ...

  dhcphelper:
    build: ./dhcp-helper
    restart: unless-stopped
    network_mode: "host"
    command: -s 172.31.0.111
    cap_add:
      - NET_ADMIN

Notice that we’re using the host network mode for the DHCP relay service. This is important if we want to intercept discovery requests on the same network as the host (LAN). Also, we’re adding a flag to the entry point command specifying the server’s IP. We’ll assign this IP to Pihole’s service as follows:

version: "3.2"

services:
  pihole:
    container_name: pihole
    # ...
    networks:
      backend:
        ipv4_address: '172.31.0.111'

In order to use this new network that we named backend we need to define it in our docker-compose file:

version: "3.2"

services:
  pihole:
    container_name: pihole
    # ...

  dhcphelper:
    build: ./dhcp-helper
    # ...

networks:
  backend:
    ipam:
      config:
        - subnet: 172.31.0.0/16

With all these modifications, we end up with the following docker-compose file:

version: "3.2"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    environment:
      - TZ=America/New_York
      - WEBPASSWORD=very-secure-password # Choose a password for admin
      - PIHOLE_DNS_="1.1.1.1;1.0.0.1" # Set upstream DNS servers
      - ServerIP="10.10.0.10" # Your host's external IP
    volumes:
      - pihole:/etc/pihole/
      - dnsmasqd:/etc/dnsmasq.d/
    restart: unless-stopped
    depends_on:
      - dhcphelper
    cap_add:
      - NET_ADMIN
    networks:
      backend:
        ipv4_address: '172.31.0.111'

  dhcphelper:
    build: ./dhcp-helper
    restart: unless-stopped
    network_mode: "host"
    command: -s 172.31.0.111
    cap_add:
      - NET_ADMIN

networks:
  backend:
    ipam:
      config:
        - subnet: 172.31.0.0/16

volumes:
  pihole:
  dnsmasqd:

One More Thing

So far, we’ve managed to:

1. Run a Pihole container with bridge network mode
2. Run a DHCP relay container that listens for discovery requests on the LAN and forwards them to Pihole on Docker’s internal network.

However, by default Pihole sends out leases instructing clients to use its IP as a DNS server. The IP used here is Pihole’s IP address on the network where it received the DHCP request. This means that the clients will be configured to send their DNS queries to an address on the network 172.31.0.0/16 and this will not work. This is an internal Docker network that we created to connect Pihole to the DHCP realy, and that machines on the LAN have no access to. In order to resolve this, Pihole needs to grant DHCP leases with the host’s external IP as the DNS. we can accomplish this by adding a configuration option to dnsmasq running inside Pihole’s container. This is as simple as creating a file inside Pihole’s container under /etc/dnsmasq.d/ with the following:

dhcp-option=option:dns-server,<PIHOLE_HOST_EXTERNAL_IP>

To make our lives easier, let’s put this in a script file called update-dhcp-dns and also support multiple DNS servers while we’re at it.

#!/bin/bash

DNS_SERV_IPS="" # A comma separated list of DNS IPs. E.g.: "10.10.0.10,1.1.1.1,1.0.0.1"

if [[ -z $DNS_SERV_IPS ]]; then
    echo "Please set DNS servers IPs by modifying the script file."
    exit 1;
fi

docker-compose exec pihole bash -c "echo 'dhcp-option=option:dns-server,$DNS_SERV_IPS' > /etc/dnsmasq.d/07-dhcp-options"

Wrap up

We finally have all the pieces we need to run Pihole in a Docker container with bridge network mode and have it serve DHCP requests on the host’s LAN. After updating docker-compose.yml and update-dhcp-dns with your desired configuration values, like the web password, server IP, and DNS IPs, you can deploy using the following commands.

docker-compose up -d pihole
./update-dhcp-dns

Note that you only need to run ./update-dhcp-dns once. The modifications introduced by this script will persist across container restarts because we’re using a Docker volume in Pihole’s service definition.