Just paid for and installed Elementary after being a Linux user for a decade. I was looking for something more polished that would stop me tinkering, and force me to focus on what I’m building and making money and life (I usually have had this experience owning macs, but love my Framework hardware).

I had never considered Elementary before due to it being on an Ubuntu LTS base. What changed? Over the last few years Flatpak + Homebrew Linux + distrobox containers became central to my workflow, so it doesn’t matter what the OS is based on and I can just pick something pretty that works well! It’s “pretty unix” as Paul Graham called it in an essay that stuck with me.

They make a new kind of computer that’s as well designed as a Bang & Olufsen stereo system, and underneath is the best Unix machine you can buy.

I installed Elementary on my Framework laptop. I also love how unlike every other Linux distribution, you don’t add another logo underneath the “Framework” logo on the bootsplash - such thoughtful minimalism.

Everything works really well and is integrated nicely. The system is also crazy memory efficient and snappy. I came from the Universal Blue / Bazzite ecosystem and loved the worry-free, automatic updates which also exist on Elementary since I leave the underlying system untouched and updates are applied automatically.

I was using Bazzite before but my OS was just too exciting as described above. I also like how Elementary is backed by a company and is more likely to (and has already been) long-lived, vs. a project that relies solely on free labor.

Thank you for building this, Elementary! You have a new fan! Elementary OS in 2026 is a great common-sense balance between openness, while still being aesthetic and allowing me to get work done.

Swarm logic (or swarm intelligence) in software is a design approach where complex, intelligent behavior emerges from many simple agents following simple local rules — with no central controller coordinating them.

Each agent only knows about its immediate environment and neighbors, yet the collective produces sophisticated global behavior. The “intelligence” lives in the system, not any individual.

A problem we had with initial versions of Pila Energy was that our leader/coordinator would be reset or knocked offline, leading to the followers becoming “dumb” batteries again. This is obviously not acceptable for a resiliency product. We also don’t want to move the controller to the cloud, because we believe that your hardware should belong to you, no matter whether our cloud is accessible or not.

One day when surfing at Ocean Beach, a V-formation of pelicans flew overhead. From my low vantage point over the water, I saw how one pelican peeled off and the others seamlessly closed the gap in the V. I was reminded of how resilient and simple swarm logic can be. Each bird follows 3 simple rules: stay close, avoid collision, match direction. This leads to the V, and makes the system very resilient.

This “leaderless” logic became known as the “pelican logic”, and the swarm of equals is now implemented for Pila’s mesh aggregation and decisioning. This makes our whole-home battery system act as a whole whether you’ve decided to pair with our cloud or not, and dynamically adapts even if certain batteries get moved or become unavailable.

Note: LA times covered how pelicans glide above the ocean, but I stole this photo from Ian Wood.

I’d like to propose a self-hosted PaaS as a great middle-ground. By combining two open source projects (Flatcar, Dokploy) I run 4 projects on a $5 VPS with all of the conveniences of Heroku.

The Problem

Problem 1: Maintenance - Renting a cheap VPS from someone like Hetzner or Digital Ocean is great. But you need to know a minimum about server maintenance and backups. What about OS updates and security of the underlying OS? What if something goes wrong with an automatic upgrade? How about closing and opening the right ports. Don’t have a password login! One of the main benefits of “serverless” like Firebase Functions or “container platforms” like AWS Lightsail or Fargate is that you don’t need to babysit an Ubuntu installation with automatic upgrades and OS updates.

Problem 2: Costs slowly add if you add a VPS per project, especially if they’re continually running even when not needed. If you have a few projects kicking around that bring in minimal revenue like I do, it’s useful to not pay a lot of overhead for a Heroku server each. Container services fall into this category too - 5+ bucks a month per container indefinitely makes you cull periodically. On the serverless function end of the spectrum, your usage can unexpectedly spike from an HN post and you’ll get billed for it (Tweets documenting this are wide-spread). You also get walled into whichever walled garden is currently cool (Vercel, Firebase before it, etc).

A Solution

A locked-down, automatically-updating container host OS like Flatcar Container Linux or Fedora CoreOS solves most of the server maintenance problems for you. You install it once, close all but the relevant ports in the cloud provider’s firewall, and it’s pretty much set-and-forget. These installs are only accessible over your SSH key by default. At its best, Flatcar provides a lot of the low-maintenance platform of PaaS, with all of the affordability and vendor neutrality of a VPS. But in comparison to running Ubuntu with unattended upgrades we have atomic rollbacks which are the “killer feature” here. If an update fails, it rolls back to the previous partition. Ubuntu should mostly be fine, but when it isn’t it requires manual maintenance. And you’ll always be on vacation when the manual maintenance becomes necessary.

So we have an affordable, reliable server with predictable and low costs. We can put multiple projects on it (as we’ll do in the next paragraph), adding another project doesn’t add more marginal cost overhead until you hit the limits of the VPS, and then scales slowly. Cost is solved.

Convenience is not solved yet though: deploying applications with raw Docker still takes focus away from working on your project itself. What about all of the sweet hassle-free features from PaaS like deploy from git, easy database deploys, and - you know - not having to mess around with Kubernetes for your side project? Here’s where the second move comes in: Dokploy. Dokploy is your CI, can put as many projects on your server as you like, builds containers from git, helps you debug logs, is an env manager, and provides UI around container orchestration. It’s Heroku, but open-source. You only access Dokploy through https, meaning you can close all SSH and management ports and remove a whole class of (ssh, access) attacks. You back up your relevant databases to an external storage service (best-case S3 on a separate cloud provider), to make things very resilient. Note that for a single-node setup like I run, there will be a brief window of downtime during OS updates unless you configure a reboot strategy.

Dokploy itself runs in a container, all your projects and databases do too, and the underlying OS automatically updates (with rollbacks) forever. I think modifying a VPS into a “container service” in this way is the sweet spot of convenience and cost: load that VPS with a bomb-proof no-config OS like coreOS, and put Dokploy on it for a no-fuss container service UI. It gives you the hassle-free experience of a Heroku-like platform, but with the cost and independence of a VPS.

This way you can have your cake and eat it too: most of the benefits of serverless, with most of the benefits of running your own VPS.

Let’s implement this Flatcar + Dokploy stack on Hetzner in a quick example.

Go to Hetzner and sign up for an account.

Add an SSH key.

Some VPSs like EC2 or Vultr support Flatcar out of the box. To get an image on my preferred Hetzner, you need to upload the Flatcar image to Hetzner yourself. We’ll do so with the officially documented few lines below:

I downloaded hcloud-upload-image binary, then in the folder with hcloud-upload-image, ran:

export HCLOUD_TOKEN=<your-token>
export CHANNEL=current
export VERSION=current

./hcloud-upload-image upload \
 --architecture=x86 \
 --compression=bz2 \
 --image-url=https://${CHANNEL}.release.flatcar-linux.net/amd64-usr/${VERSION}/flatcar_production_hetzner_image.bin.bz2 \
 --labels os=flatcar,flatcar-channel=${CHANNEL} \
  --description flatcar-${CHANNEL}-x86

Create a server from this image you uploaded, and SSH into it. Note we went slightly off of the recommended path here and didn’t add an Ignition file. The main thing an Ignition file does is adds your SSH key to the OS image. But Hetzner adds this into your userdata already, so I found this unnecessary. You can also start your containers with an Ignition file, but that’s cumbersome and somewhat non-standard IMO, and that’s what we have Dokploy for. So we skipped the Ignition file. Feel free to add one if you need it - either through the Hetzner CLI or paste it into “cloud init” when creating a new image from your snapshot.

Welcome to your fresh, auto-updating instance of Flatcar!

ssh core@<your ip> # we'll lock this down real soon don't worry

Now let’s install Dokploy.

sudo systemctl enable docker # auto-start Docker on reboot (as we didn't define this in Ignition). From there, Dokploy will do the rest.
sudo -i # one-time, for root
curl -sSL https://dokploy.com/install.sh | sh

That’s it! Go to your server’s IP at port 3000 and set up Dokploy, close your ports, and be on your merry way!

You now have an easy to use UI on top of an automatically-updating immutable OS.

Assign the Dokploy UI to a subdomain or domain, and then you can close all the ports except for 80 for http and 443 for https, which will let those pesky bots bite their teeth out when they’re sniffing for our non-standard SSH port. Access everything you need through the web dashboard. You shouldn’t really need to check in much on the underlying linux system again. You now have an auto-updating and sealed off host, with an auto-updating container deployment system, itself running in a container.

Caveat: if your traffic is super intermittent and spikey go for serverless functions. If you’re just starting out go with Heroku.

The status quo

The U.S. electric grid, as it stands today, runs largely on old-school communication networks - and in some ways, that’s a blessing in disguise. While intelligence and connectivity can unlock enormous potential, they also come with trade-offs: Too often, they introduce brittle complexity. “Smart” yet inflexible hardware often ages quickly. And they can introduce new forms of risk from software vulnerabilities and excessive dependency on internet access to exposure to unstable supply chains. We’ve already seen how this can go wrong - when Enel X deprecated the software that kept JuiceBox EV chargers running, they left 25,000 of commercial users suddenly unsupported.

In the world of energy, those kinds of failures are more than inconvenient - they’re downright dangerous. When a smart speaker fails, the music stops. But when a smart grid component fails, people lose power. Resilience isn’t optional. And yet, too much of today’s “smart” infrastructure depends on unnecessary cloud servers, mobile apps, vendor APIs, or firmware updates to function properly. That’s not good enough.

Where we need to go

We believe the intelligence layer should be just as resilient as the physical grid itself. It can’t be the weakest link. Some consumer products that have paved the way for our vision include Ollama, Home Assistant, Trmnl, Shelly, and the Powerwall and the original Nest (before Google made Home app obligatory). These products can function without the internet and “official apps” from the app store.

At Pila, we’re building infrastructure-grade, local-first intelligence that runs at the edge, continues working when cloud services go down, and doesn’t rely on remote updates to stay useful. On-device processing and local networking - paired with optional local APIs, Home Assistant integration, and more - ensure your microgrid keeps running at full functionality, no matter what happens. The energy system must remain anti-fragile. Of course there’s a tremendous amount of value added with an internet connection - from real-time power price signals to weather data to convenient remote control from your smartphone. But this value can exist as an optional benefit atop the core functionality, not a mission-critical failure point.

If AI becomes embedded into everything, it too should work local-first and not require a cloud. We believe it belongs on the edge - close to the energy assets themselves, designed to operate and coordinate autonomously, and built to outlast the hardware it runs on. The future grid won’t rely on fragile, centralized control. It will emerge from billions of resilient, intelligent systems at the edge.

A lot of effort is wasted in volunteering. Especially when people are giving away their time for free, I think we need to be just as careful as what we point their time at as if they were charging for their time.

For solo projects, there’s an additional layer: it’s fun to write software. Who cares if anyone’s using it? But there might also be another problem that would be both fun to write software for AND people would actually use.

Closed projects do this to prove their value (say quarterly results or even on their landing page), it’s interesting that open ones often don’t. Capitalism has come up with a great way to not waste money and effort on things no one uses: we track what’s being used, and how, and inform time investment based on that. Because time is free when we’re building the commons, why measure? I think this is backwards.

Universal blue project - a downstream project of Fedora - recently started measuring very precisely who is using what. More interestingly, the same tools helped me shed light on who was using what of the upstream. And the numbers were surprising.

I think we need to track who’s using what in the commons, so that less effort is wasted. If you have volunteers, you’re more obligated to measure, not less. Let’s use the tools of capitalism to improve the commons.

Though extremely well-hidden, this feature does exist. I eventually found this Youtube video - the only place I ever have seen it mentioned.

• You hold the lock button
• you then simultaneously double-press (!) the unlock button (Subaru starcluster logo)
• Your key fob is now off, you can remove the valet key, and place your fob into the car without a radio bag.
• You press any button on the fob to turn the fob back on.

Happy surfing.

But one of the best things to happen to Node in the past few years was Bun and Deno. Node’s pace of improvement has increased dramatically once it got some real competition to be inspired by (.env support, test runner, watch mode, glob support, top-level await, require/ESM cross-import, single file bundle, Typescript support out of box, SqlLite, window shim, and stable fetch).

While I like the Gnome desktop project, they do sometimes feel a little slow in their rate of innovation & their openness to innovation. Merge requests that everyone’s pretty much on board with can be open for years. Maybe Cosmic desktop’s “fork” (technically re-build) and a little competition will speed them up like Node was sped up by Bun and Deno!

Like many, I’ve recently discovered how far along “Heroku-like” solutions like Appliku and Coolify have come that add a layer of ergonomics onto a raw server/VPS (or even a Raspberry Pi if that floats your boat).

Coolify lets me get the benefits of self-hosting my sites and apps on a VPS (cost savings, freedom, cost control), while still getting all the benefits of a stable, abstracted-away platform like Heroku. It allows me to focus on building apps and features without fussing too much about ports, certificates, containerization (god forbid I go near a Kubernetes timesink). 

There’s two steps involved:

1. Sign up at Hetzner.com (I used an arm instance) for $3/mo, and self-updating Fedora CoreOS (or normal Fedora though you’ll need to set it to auto-update)
2. Install Coolify with the one-liner and start donating $10/mo to their project.

There is no step 3 - start deploying apps in docker containers (or more Heroku-like Nixpacks if you can get them to work) to your new small server. Follow a hardening tutorial and create snapshots of the server.

Coolify can create backups of your databases to the server itself (which you’ll have to download to local) or to S3. You can layer in as many apps as you want until memory runs thin. Most apps won’t see much traffic, and if you see spikes you can grow your instances or spin them out to a separate server (“VPS”). At 2 apps and 2 databases, I’m at 900mb/4096mb memory usage (including the OS).

I originally started researching solutions like Kamal and Dokku, but for me these are a step too far into the “distraction” of devops. I love devops, and I will happily bikeshed and optimize my servers all day without getting any profitable/valuable work done. I need to keep myself away from these these choices and abstract them away. I need a button to push that requires no setup. Coolify provides that button!