Miren v0.16: Release Highlights

Our dream for Miren is to have it surface exactly the information you need about your apps and deploys in an intuitive way, and for us to take the chores of operating and maintaining a deployment platform off your plate.

With our v0.16 release this week, Miren Cloud is able to show you a lot more about what’s happening in your cluster, and we can now automate one of the biggest chores in running a cluster: upgrading Miren itself.

INVENTORY GET

Miren has always been CLI-first and will always be fully drivable from the command line, but when it comes to getting a quick view of everything happening in a cluster, it’s hard to beat a good ole web page.

Miren clusters now publish details about their running apps, their health, and their deployment history to Miren Cloud.

This means you can get a nice roll-up view of the apps deployed to all your clusters.

If you drill into an app, you can see its deployment history.

You can also see a list of the nodes in your cluster, including the main coordinator node and the runners you’ve added.

Upgrades from Miren Cloud

The cluster page in Miren Cloud gains a new section that tells you what version it’s on, what the latest version is, and gives you a nice big button to upgrade.

The upgrade process is driven within the cluster, and includes a new step that backs up Miren’s internal datastore, automatically restoring to that snapshot if the new version doesn’t come up healthy.

Even better than a Miren Cloud-driven manual upgrade is an automatic one. You can turn this on from the cluster page, and choose a maintenance window that makes sense for your apps. Miren upgrades still require momentary downtime, so we decided to make this opt-in for now. The Miren Cloud upgrades guide covers release channels, maintenance windows, and getting notified in Slack.

You can see a history of operations taken on your cluster as well.

One last upgrade by hand

In keeping with our ethos, the bones of this new upgrade functionality are open source and wired to make your life easier even if you’re not using Miren Cloud.

First you’ll need to get onto v0.16. That takes one round of the old commands, once per machine:

sudo miren server upgrade   # on the coordinator
sudo miren runner upgrade   # on each runner
miren upgrade               # on your laptop (or brew upgrade miren)

Once you’re on v0.16, future upgrades are a single command on the coordinator:

sudo miren upgrade   # upgrades the server, then each runner in turn

miren upgrade does the right thing wherever you run it, so on your laptop it just upgrades the CLI. Upgrades also travel over RPC now, so miren cluster upgrade does the whole cluster from your laptop.

Or, of course, let Miren Cloud handle it: that big button, or a maintenance window, and you’re done upgrading by hand for good.

Static sites, straight from ingress

We want to make it dead simple for you to run static sites on Miren, whether you’re using a generator like Vite or Astro or just have a nice pile of HTML you’d like on the internet.

In this release, you can point static.dir in your app.toml at a directory, and Miren’s ingress serves those files itself, with no sandbox running your app:

name = "docs"

[static]
dir = "/app/site"

Your uploaded source lands at /app, so that serves the site/ directory in your repo. If your site is generated, Miren builds it first and serves just the output. The static sites guide has recipes for several different scenarios.

Declarative deploy targets

Once you’re juggling a handful of Miren clusters and several handfuls of apps, “which app deploys where” becomes a question you’re asking yourself more often than you’d like.

Miren already has a few tiny QoL features to make this easier: miren cluster switch remembers which cluster you picked for each app, and when you have multiple clusters in your config, you get a prompt on miren deploy to make sure you’re slinging your code to the right place.

These help, but they fall short once an app deploys to more than one cluster, like staging and production. We really wanted a way to let you say “this app goes to these clusters” explicitly. Now the repo can remember for you:

miren deploy target add staging
miren deploy target add prod

That writes a .miren/deploy.toml next to your app.toml:

[[targets]]
name = "staging"
cluster = "miren-staging"
cluster_id = "cluster-abc123"

[[targets]]
name = "prod"
cluster = "miren-prod"
cluster_id = "cluster-def456"

Commit it, and miren deploy goes to your default target (the first one, until you change it with miren deploy target set-default), while miren deploy --target prod goes to the other. Targets resolve by their Miren Cloud cluster ID, so the file works for everyone on the team, whatever they named the cluster locally.

And quite a bit more

These are just the highlights. There’s plenty more in this release. Check out the v0.16 changelog for all the details.

If you haven’t tried Miren yet, you get to skip the silly manual upgrade entirely: get started and put the whole thing on a box you control. Want us to handle the provisioning instead? Let us set up a cluster for you!