Dropserver uses Deno as its app runtime and sandbox, and Deno is done.

So what does this mean for Dropserver? It’s not good. But then again things weren’t going swimmingly for DS development lately. I lost some courage for a couple of reasons.

Why I built Dropserver

Endlessly frustrated by siloed and predatory social media corps, I wanted to give regular people a way of controlling the web services they use. I imagined that hosting a web service could be as easy as loading a web page.

My goal was to give users agency over the code they interact with on a server. Think about it: for the vast majority of users, every single request made (via a web browser or from within an app) is an interaction with a server they have no control over.

I wanted to create a platform that gave users the power to deploy small, tailored web-apps. Users should have agency over the stuff they run on servers without getting bogged down in the technical minutia of typical “server maintenance”, or being exposed to the risks of running such a service.

With an easy and safe way to run their own thing, perhaps people would start moving away from giant predatory services.

Original Concept

At first I was going to provide a hosted version of Dropserver. I kind of knew that the requirement to install or configure anything would deflate most people’s enthusiasm. Remember I am doing this for non-technical people.

But running people’s apps for them exposes me to all kinds of problems: running untrusted code, keeping users safe, keeping them online, obeying local laws around privacy. It’s a lot. It’s way too much. And it’s not clear anybody would want to pay for any of this.

After some reflection I decided I did not want to run anything myself for now. I’d rather build something that let people run something entirely independently of me, and I could just focus on building and not on running a service.

What Sets Dropserver Apart

Some will say there are multiple such platforms out there already, and to some extent this is true, but pretty much all of them drop the user into the Linux command line to install it. I think this is too scary for most regular folks.

As I reoriented towards having people install and run Dropserver entirely themselves I intended to give ds-host these characteristics:

• No CLI use for installation, backups and maintenance
• Installs on typical home-use operating systems

Just these two points would make DS an entirely different beast than most of the others. Unfortunately I haven’t succeeded in achieving the above. I did release ds-host for Mac, which is a step in the right direction. The Windows version is feasible, but I don’t have it sorted yet. But it is feasible, and that is thanks to Deno, which runs on the major operating systems.

Where I failed miserably is the initial install process. It’s terrible. Remember that originally I was going to provide this as a service, so the install process was not thought out for regular users. I have plans for improving it dramatically, but for now it’s just bad.

Apart from the above I feel better about the work I did:

• Install an app by pasting a link (apps are publishable to any static website host)
• Upgrade to latest app version with migrations and safeguards
• The app sandboxing via Deno and a strict CSP, while a little severe, gives a lot of protection against bad code.
• Each app instance’s data can be backup up, copied, and moved.
• The app instance can be recreated in a different Dropserver instance remarkably easily.
• User management is under-developed but having it in Dropserver instead of in the app is a good move.

Unfortunately there is one thing I could not crack.

Networking Pains

The biggest pain of self-hosting is the networking side. Modern web-apps need to run in a secure context to take advantage of the web’s modern APIs, and that requires a TLS certificate. And right there, what started out as hosting something on localhost over HTTP escalates into a big endeavor with lots of decision points and no good, easy, obvious solutions.

I documented all the pitfalls of connecting your personal app to the web in this post: Serving a Web App Like a Home Cooked Meal.

To get around most of these pains I integrated Tailscale into ds-host. This completely bypasses the networking issues for many use cases: your ds-host instance can be a node on your tailnet, and each appspace is another node. Tailscale user ids are used for auth, so there are literally no passwords and no sign-in required if you load an appspace via a tailnet. And with that you can hide your instance and appspaces from the internet. It’s brilliant!

Well, it’s brilliant if you have Tailscale on your devices running all the time. I do, but for other users I’ve heard of battery drain issues from running Tailscale 24/7. I’ve also heard complaints about needing to turn TS off to run a VPN. Having to turn on Tailscale on a phone just to use an app is enough of a hurdle to stop someone using the app.

And unfortunately, to give someone access to the app in an ad-hoc fashion, someone who very likely does not have Tailscale on their devices, brings you back to square one. With your app hidden from the net there is no easy way to invite them in.

(I asked Tailscale if they could implement auth on their funnel product, so that only authenticated requests would get through, but I haven’t seen it yet.)

While I deeply appreciate having my ds-host instance hidden from the net yet accessible from anywhere thanks to Tailscale, particularly during this period of continuous vulnerability disclosures, it limits what kind of apps I can use in Dropserver. I had ideas for small apps to help parents of my kid’s class organize, but cornering parents in the school parking lot to get them to install Tailscale is not going to happen. Any hoop they have to jump through will kill the effort.

While I was thinking about all that, the world changed.

Hardware Costs

When I started DS you could buy a Pi for $35 or a Mini PC with ample specs for $100. Pi just announced that it was increasing the price of the Pi 5 with 16 Gigs of RAM by 80$ to $385. It is of course a completely different beast than the Pi 3. And you can still get a Pi for less than $100 if you limit your RAM. But… the trend is not good.

Prices have climbed so much that buying even “cheap” hardware is expensive. You just can’t get a decent deal on any kind of computing equipment nowadays. So the tradeoff for hosting yourself just got even worse. The amount of dough you have to shell out is immediately disqualifying.

(Using old hardware that you have on hand is an option, if you have it and can spare it.)

Vibe Coded Personal Apps

There has been a seismic shift in the effort required to write a small app for personal use. You can literally get one working with only a short paragraph as your input effort. That’s insane!

When I thought up the original shape of Dropserver, I decided to cut free from the constraints of running existing open source projects. This decision allowed me to do things quite differently from the projects that do run existing apps, but it meant users had basically no apps to run on Dropserver (save for one or two).

I hoped that people who did adopt Dropserver would write apps for it, and maybe publish some. I may have been mistaken about that: people who build personal apps make them for themselves personally, and don’t necessarily intend to share.

But no matter! The era of vibe coding is here! If you’re OK using AI you can build a personal app in no time. You can even get it deployed if you give your agent enough leeway. So what does that mean for Dropserver?

On one hand using AI to write an app for Dropserver is exactly what I didn’t know I needed and couldn’t imagine would exist. It makes my decision to not support existing apps a defensible one, years before I could justify it.

On the other hand, LLMs can do so much and platforms are so eager to support agentic use of their services that I have to ask myself: what is the role of Dropserver in all this?

What Now

The problem Dropserver set out to solve is that it’s too hard for non-tech people to do anything involving a server. The problem is alive and well and I still want to crack it.

The issues with Dropserver are much bigger than Deno corpsing out on us.

Times have changed. Some things are now easier than ever. Others, like exposing your service on the Internet, are riskier than ever. Code is now cheap and the hardware to run it is unaffordable.

So for now, I’m in a stop and think mode. I’m rethinking the shape of Dropserver as a whole.