“F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff. We worked out a special arrangement so that this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access.”
Ugh. This 100% shows how janky and unmaintained their setup is.
All the hand waving and excuses around global supply chains, quotes, etc...it took pretty long for them to acquire commodity hardware and shove it in a special someone's basement and they're trying to make it seem like a good thing?
F-Droid is often discussed in the GrapheneOS community, the concerns around centralization and signing are valid.
I understand this is a volunteer effort, but it's not a good look.
> F-Droid is often discussed in the GrapheneOS community, the concerns around centralization and signing are valid.
Clearly the GrapheneOS community is clueless then.
You can host F-Droid yourself, which is the opposite of centralized. If the GrapheneOS community actually is concerned about centralization they can host an instance as well.
Futhermore, each author signs their own software, which again is the opposite of centralized. One authority signing everything would be centralized.
So F-Droid is decentralized in authorship and distribution. Google store is only decentralized in authorship.
> Another important part of this story is where the server lives and how it is managed. F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff.
> The previous server was 12 year old hardware and had been running for about five years. In infrastructure terms, that is a lifetime. It served F-Droid well, but it was reaching the point where speed and maintenance overhead were becoming a daily burden.
lol. if they're gonna use gitlab just use a proper setup - bigco is already in the critical path...
Modern machines go up to really mental levels of performance when you think about it and for a lot of small scale things like F droid I doubt it takes a lot of hardware to actually host it. A lot of its going to be static files so a basic web server could put through 100s of thousands of requests and even on a modest machine saturate 10 gbps which I suspect is enough for what they do.
This just reads to me like they have racked a box in a colo with a known person running the shared rack rather than someone’s basement but who really knows they aren't exactly handing out details.
> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access.
I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argument arose.
I know self-hosting is held as a point of pride by many, but in my experience you’re still better off putting lower cost hardware in a cheap colo with the contract going to the business entity which has defined ownership and procedures. Sending it over to a single member to put somewhere puts a lot of control into that one person’s domain.
I hope for the best for this team and I’m leaning toward believing that this person really is trusted and capable, but I would strongly recommend against these arrangements in any form in general.
EDIT: F-Droid received a $400,000 grant from a single source this year ( https://f-droid.org/2025/02/05/f-droid-awarded-otf-grant.htm... ) so now I’m even more confused about how they decided to hand this server to a single team member to host in unspoken conditions instead of paying basic colocation expenses.
> I know self-hosting is held as a point of pride by many, but in my experience you’re still better off putting lower cost hardware in a cheap colo with the contract going to the business entity which has defined ownership and procedures. Sending it over to a single member to put somewhere puts a lot of control into that one person’s domain.
If they really want to run it out of a computer in their living room they should at least keep a couple servers on standby at different locations. Trusting a single person to manage the whole thing is fragile, but trusting a few people with boxes that are kept up to date seems pretty safe. What are the odds they'd all die together? Paying a colo or cloud provider is probably better if you care about more 9s of uptime, but do they really need it?
There is nothing wrong with hosting prod at home. A free and open source project needs to be as sustainable and low maintenance as possible. Better to have a service up and running than down when the funds run out.
> one person had the physical server in their basement
Unless you have even the faintest idea about how F-Droid does it, please stop spreading FUD. All the article says is that it is not a normal contract but a special arrangement where one or a select few have physical access. It could be in a locked basement, it could be in a sealed off cage in a data center, it could be a private research area at a university. We don't know.
A special arrangement with an academic institution providing data center services wouldn't be at all surprising, that has been the case for many large open source projects since long before the term was invented, including Linux, Debian and GNU itself.
Many of these are run by professionals with high standards. The Debian project has done pioneering work with reproducible builds, for example, something the F-Droid project is also very much involved with. Those things are what creates trust in the project.
Ultimately hosting is not the most critical part as long as backups are stored in places other members of the projects have access to (and one copy could be in their own home, I don't think the f-droid repos have grown to be that big they can't be hosted on commodity NAS).
What is usually more critical is who has the credentials for the domain management.
There are two key concepts at play here: "least authority" and "infrastructure as code". The buildserver host is sensitive security-wise, but easy to set up an instance. We have multiple instances running, and spin up new ones from time to time. For production infrastructure, there should only be enough people with access to it as are needed to maintain it. No more. If a sysadmin goes rogue, we can always just spin up a new instance elsewhere with a new maintainer.
Physically held is _very_ different than only one person having access. It doesn't seem to imply it's hosted in a basement at all.
There is zero reason that server in the basement can't be a mirrored node to one or more vps'.
To extend your point, it's probably far better to have something cloud agnostic so it can flip between horribly compromised or attacked hosts.
Basement servers on Fibre, with a bit of knowledge and power backup can be just as reliable as most for one simple and over looked reason, they're reasonably obscure and don't fall under the attention large hosts receive. They absolutely have other issues to get rid of, which can be.
Self-hosting isn't about a "point of pride". Time reveals the value of self-sufficiency, not in every case to the absolute, but being able to.
Self-hosting at home is often similar skills to hosting a server in a datacenter, whether it's your own hardware co-located, rented server, or a managed server.
It's frankly embarrassing how many of the comments on this thread are some version of looking at the XKCD "dependency" meme and deciding the best course of action is to throw spitballs at the maintainers of the critical project holding everything else up.
I wonder if anyone knows about Droid-ify. Whether it it a safe option, or better to stay away of it?
It showed up one day while I searched about why F-Droid was always so extremely slow to update and download... then trying Droid-ify, that was never a problem any more, it clearly had much better connectivity (or simply less users?)
> not hosted in just any data center [...] a long time contributor with a proven track record of securely hosting services
This is ambiguous, it could mean either a contributor's rack in a colocation centre or their home lab in their basement. I'd like to think they meant the former, but I can't deny I understood the latter in my first read.
I think all the criticism of what F-Droid is doing here (or perceived as doing) reflects more on the ones criticising than the ones being criticised.
How many things went upside down and all the "right" things were done (corporate governance, cloud native deployment, automation, etc.). The truth is none of these processes are actually going to make things more secure, and many projects went belly up despite following these kinds of recommendations.
That being said, I am grateful to F-Droid fighting the good fight. They are providing an invaluable service and I, for one, am even more grateful that they are doing it as uncompromisingly as possible (well into discomfort) according to their principles.
Good. But I wish PostmarketOS supported more devices. On battery,
tons of kernel patches could be set per device plus a config package in order to achieve the best settings. On software and security...you will find more malware in Play Store than the repos from PmOS/Alpine.
I know it's not a 100% libre (FSF) system, but that's a much greater step towards freedom than Android, where you don't even own your device.
I wish they could give more clarity on whether its hosted in a professional server or someone's bedroom, because just saying that "it's held by a long time contributor with a proven track record of securely hosting services" is not very reassuring.
I don't understand why governments haven't started to fund F-Droid, almost all govt. apps are open-source.
Countries which fear they could be cut off from the duopoly mobile ecosystem should be forcing android manufacturers to bundle in F-Droid; For the amount of nonsense regulations they force phone manufacturers to adhere to, bundling F-Droid wouldn't be that hard.
Google won't be happy, but anti-trust regulations would take care of it.
I think there are quite some misconceptions about F-Droid in the comments :
- you can be your own F-Droid server
In fact it's a basic static HTTP(S) server that is generated with the list of .apk and meta-data so it rely doesn't require much.
I think what is concerning to people is that the most popular INSTANCE of F-Droid, the one that is by default when one downloads the F-Droid CLIENT, is "centralized" but again that's a misconception. It's only popular, it's not really central to F-Droid itself. Adding another repository in the F-Droid parlance is just a simple option of changing or adding a URL to more instances.
That being said if anybody here would like to volunteer to be provider a fallback to the build system to that popular instance, I imagine the F-Droid team would welcome that with open arms.
41 comments
[ 2.4 ms ] story [ 54.0 ms ] thread“F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff. We worked out a special arrangement so that this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access.”
All the hand waving and excuses around global supply chains, quotes, etc...it took pretty long for them to acquire commodity hardware and shove it in a special someone's basement and they're trying to make it seem like a good thing?
F-Droid is often discussed in the GrapheneOS community, the concerns around centralization and signing are valid.
I understand this is a volunteer effort, but it's not a good look.
> this server is physically held by a long time contributor with a proven track record of securely hosting services.
So you are assuming it's a rando's basement when they never said anything like that.
If their way of doing business is so offensive either don't use them, disrupt them or pitch in and help.
> I understand this is a volunteer effort, but it's not a good look.
What does make a "good look" for a volunteer project?
Clearly the GrapheneOS community is clueless then.
You can host F-Droid yourself, which is the opposite of centralized. If the GrapheneOS community actually is concerned about centralization they can host an instance as well.
Futhermore, each author signs their own software, which again is the opposite of centralized. One authority signing everything would be centralized.
So F-Droid is decentralized in authorship and distribution. Google store is only decentralized in authorship.
> The previous server was 12 year old hardware and had been running for about five years. In infrastructure terms, that is a lifetime. It served F-Droid well, but it was reaching the point where speed and maintenance overhead were becoming a daily burden.
lol. if they're gonna use gitlab just use a proper setup - bigco is already in the critical path...
This just reads to me like they have racked a box in a colo with a known person running the shared rack rather than someone’s basement but who really knows they aren't exactly handing out details.
Saying this on HN, of course.
I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argument arose.
I know self-hosting is held as a point of pride by many, but in my experience you’re still better off putting lower cost hardware in a cheap colo with the contract going to the business entity which has defined ownership and procedures. Sending it over to a single member to put somewhere puts a lot of control into that one person’s domain.
I hope for the best for this team and I’m leaning toward believing that this person really is trusted and capable, but I would strongly recommend against these arrangements in any form in general.
EDIT: F-Droid received a $400,000 grant from a single source this year ( https://f-droid.org/2025/02/05/f-droid-awarded-otf-grant.htm... ) so now I’m even more confused about how they decided to hand this server to a single team member to host in unspoken conditions instead of paying basic colocation expenses.
If they really want to run it out of a computer in their living room they should at least keep a couple servers on standby at different locations. Trusting a single person to manage the whole thing is fragile, but trusting a few people with boxes that are kept up to date seems pretty safe. What are the odds they'd all die together? Paying a colo or cloud provider is probably better if you care about more 9s of uptime, but do they really need it?
Unless you have even the faintest idea about how F-Droid does it, please stop spreading FUD. All the article says is that it is not a normal contract but a special arrangement where one or a select few have physical access. It could be in a locked basement, it could be in a sealed off cage in a data center, it could be a private research area at a university. We don't know.
A special arrangement with an academic institution providing data center services wouldn't be at all surprising, that has been the case for many large open source projects since long before the term was invented, including Linux, Debian and GNU itself.
Many of these are run by professionals with high standards. The Debian project has done pioneering work with reproducible builds, for example, something the F-Droid project is also very much involved with. Those things are what creates trust in the project.
What is usually more critical is who has the credentials for the domain management.
There is zero reason that server in the basement can't be a mirrored node to one or more vps'.
To extend your point, it's probably far better to have something cloud agnostic so it can flip between horribly compromised or attacked hosts.
Basement servers on Fibre, with a bit of knowledge and power backup can be just as reliable as most for one simple and over looked reason, they're reasonably obscure and don't fall under the attention large hosts receive. They absolutely have other issues to get rid of, which can be.
Self-hosting isn't about a "point of pride". Time reveals the value of self-sufficiency, not in every case to the absolute, but being able to.
Self-hosting at home is often similar skills to hosting a server in a datacenter, whether it's your own hardware co-located, rented server, or a managed server.
It showed up one day while I searched about why F-Droid was always so extremely slow to update and download... then trying Droid-ify, that was never a problem any more, it clearly had much better connectivity (or simply less users?)
This is ambiguous, it could mean either a contributor's rack in a colocation centre or their home lab in their basement. I'd like to think they meant the former, but I can't deny I understood the latter in my first read.
Also, no details on the hardware?
How many things went upside down and all the "right" things were done (corporate governance, cloud native deployment, automation, etc.). The truth is none of these processes are actually going to make things more secure, and many projects went belly up despite following these kinds of recommendations.
That being said, I am grateful to F-Droid fighting the good fight. They are providing an invaluable service and I, for one, am even more grateful that they are doing it as uncompromisingly as possible (well into discomfort) according to their principles.
Brought to you by the helpful folks who managed to bully WinAmp into retreating from open source. Very productive.
Countries which fear they could be cut off from the duopoly mobile ecosystem should be forcing android manufacturers to bundle in F-Droid; For the amount of nonsense regulations they force phone manufacturers to adhere to, bundling F-Droid wouldn't be that hard.
Google won't be happy, but anti-trust regulations would take care of it.
I'm curious why supply chain issues got in the way and why they couldn't just configure a Dell Poweredge and get delivery in a couple weeks.
I'm assuming they have some special requirements that weren't met by an off-the-shelf server, so I'm just curious what those requirements are.
- you can be your own F-Droid server
In fact it's a basic static HTTP(S) server that is generated with the list of .apk and meta-data so it rely doesn't require much.
I think what is concerning to people is that the most popular INSTANCE of F-Droid, the one that is by default when one downloads the F-Droid CLIENT, is "centralized" but again that's a misconception. It's only popular, it's not really central to F-Droid itself. Adding another repository in the F-Droid parlance is just a simple option of changing or adding a URL to more instances.
That being said if anybody here would like to volunteer to be provider a fallback to the build system to that popular instance, I imagine the F-Droid team would welcome that with open arms.