Dropserver Progress - August 2025
This is the progress report for Dropserver for August 2025. The previous report is here.
This month I worked on getting an instance of ds-host running in my home. Now that it’s trivially easy to make an appspace a Tailscale node, running my instance away from the public internet is the way to go.
But there are caveats! And new footguns! And countless little decisions I made while developing ds-host that are no longer helpful! Finding all those out, and working on solutions occupied plenty of time.
Domain Names Should Not Be Required
The ds-host config file asks for the domain name of the instance. Oof. What if you don’t have one? Why do you have to have one?
I used to think all instances would be on the public internet, with a domain or a zone pointing to their public IP. I no longer think this way.
It’s perfectly reasonable, and in fact it’s probably a good approach to run ds-host on a machine at home, and access it exclusively through Tailscale. This takes care of all the networking challenges in one shot while being far more secure than exposing your instance to the public internet. It’s a giant win for self-hosters.
So domain names should not be a requirement. While I was pulling on that thread, I wondered about all the ways someone might want to connect to their instance. It’s quite a matrix! See issue 142.
Dropping DropIDs
What are DropIDs? I never got around to writing that up in the docs. So here is how they came about:
One of the principles of Dropserver is that you can move your service from one instance to another without undue hurdles to climb (illustrated by the move-your-sh**.png icon on the home page). Since a user on the appspace may not be a user in the new instance, appspace users have to be identified by some sort of globally unique name.
Imagine for a moment that I was even more naive than I am and had used the instance’s user ID as the appspace user ID? Is user #2 in one instance the same as user #2 in a different instance? Of course not.
So I cooked up DropIDs. I was fully into the “every instance will have a public domain” phase of Dropserver, so using the instance’s domain name made sense! Your DropID is your instance’s domain with a username appended as a path, so somedomain.com/oli could be my DropId.
With that as the user identifier in appspaces, an owner could move an appspace to a new instance and there would be no confusion as to who’s who in the list of appspace users.
But wait, did I mention that DropIDs were also part of:
Remote logins
DropIDs enabled remote logins to appspaces from other instances. If an appspace is on ownerdomain.com and a user is on an instance at userdomain.com, then that user could “join” that appspace from within their instance, and log in from there by clicking on a link from within their instance (no additional password needed.)
I was really keen on this “federation” feature in ds-host. I didn’t want people to have to create accounts at countless Dropserver instances to be able to participate in other people’s appspaces.
I implemented all this, but I did not give this capability the dev time it deserved. And something like this takes a lot of work to get right.
Now that I fully expect many instances will be hidden from the internet and have no public domain name the whole idea falls apart.
Use email instead
I still need a unique identifier because moving appspaces around is still key.
I realized that the obvious one to use is email addresses. Everybody’s got one, and they are globally unique. Everybody knows what they look like and can recognize their friend’s addresses (sometimes).
The only hiccup is that ds-host currently does not send mail so I’ll need to be clear that the email is for identification, not for sending.
No more remote logins?
I still think it’s important to make it as easy as possible to let other appspace users log in to an appspace. But the picture is more complicated now. Tailscale is great, but nobody I know has the Tailscale app, especially among my non-technical friends.
There is more thinking to do, but anything based on public domain names I now consider DOA. So the remote login aspect will go away in a future update along with DropIDs.
I do hope to bring it back someday, but it will be quite different.
ds-host At Home: New Challenges
Installing ds-host is a pain. I know this and plan on improving the situation as much as possible, but more concerns came up as I went through my own install at home.
Backing up
Having my own instance at home brings up some new questions: what happens if this cheap hardware I bought gives up the ghost? I have lots of data on some of my appspaces and I do not wish to lose it. (My chat-style note/journaling app has 17,679 hand typed entries as of this moment.)
I had to get Proxmox to generate backups of the VM once per night and place them on my Synology NAS. That’s good, but ds-host itself should have built-in backup capabilities. It should be able to backup itself and all its appspaces periodically. You should also be able to backup appspaces to a remote location automatically. More things to think about.
Monitoring
On my older instance I installed Grafana and Prometheus in a docker compose setup to monitor the ds-host instance and its VM. It worked fine, but it’s an unreasonable lift for non-technical people. Also, it generates tons of graphs that won’t make sense to most people.
This led me to wonder what could be done to give just enough visibility and what are the use cases for visibility into runtime metrics?
Running Dropserver should just work. Things that just work don’t require dashboards full of graphs of low level metrics. It’s important not to carry over habits from running public SaaS apps into the world of self-hosting private apps from home. These are different things, like a Formula 1 car is different from a Honda Civic. One requires constant care and attention by engineers and the other just runs.
But sometimes even the Honda needs some love, so perhaps there should be something like a “check engine light” on ds-host, and a page that gives current metrics that can be shared on a forum to help with diagnosis and resolution.
More thought needed there.
Onwards
That was long! The time spent pondering things this month will help me put my efforts in the right place in the following months.
See you then!
