> Twenty-four Homerun releases since the release channels post. The ones that matter: services that sleep when nobody's using them, Sentry-compatible error tracking built in, browser IDEs on your own server, incremental backups, your whole setup in a file, and a dashboard that feels like an app on your phone. > Source: https://orochibraru.com/blog/homerun-idle-apps-sleep-catches-crashes-works-on-a-phone · Site index: https://orochibraru.com/llms.txt # Homerun now puts your idle apps to sleep, catches their crashes, and finally works on a phone *26 October 2026* The last Homerun post was about [release channels](/blog/homerun-nightly-canary-stable), a month ago. Since then: 1.0.49 to 1.0.72, twenty-four releases, and a changelog long enough that nobody's reading it, me included. So here are the ones that change what Homerun is for. Not the polish, not the bug fixes, not the twelfth tweak to the sidebar. ## services can sleep now A homelab box runs out of memory long before it runs out of CPU, and plenty of what runs on one gets opened a few times a month while sitting in RAM the rest of it. **Container → Compute → Scale to zero** stops a service after a number of idle minutes (1 to 1440) and starts it again on the next request. The request that finds it asleep waits while it boots, up to 25 seconds, then gets a `307` back to the same address, so a `POST` keeps its body. If the app takes longer than that, the visitor gets a **Waking up** page, a `503` with `Retry-After: 2` that the browser reloads by itself until the app answers. In swarm mode it's 0 replicas and back. What it isn't: magic. "A request" means one through Traefik, on one of the service's domains. Another container calling it over the Docker network doesn't wake it, so don't put a database or a queue worker to sleep. And bots scanning your domains wake it too, because of course they do. Homerun doesn't make your app boot faster either: the wait is Docker's few hundred milliseconds plus however long your app takes. [The details](/homerun/docs/runtime-and-compute#scale-to-zero). ## a Sentry you don't pay for Apps throw errors. Without something collecting them, you find out from the logs if you happen to look, or from a user, which is worse. Turn on **Error tracking** in a service's **Observability → Errors** and Homerun gives it a DSN. It speaks the Sentry protocol, so you use the official Sentry SDK for your language, unchanged, pointed at your own server instead of sentry.io. Leave **Inject SENTRY\_DSN, SENTRY\_RELEASE and SENTRY\_ENVIRONMENT** on and the next deploy sets all three, so the app initialises the SDK with no arguments at all. The release is the git commit the deploy built, so every error says exactly which code threw it, and the stack trace sits next to that code. Errors are grouped into issues, which you can also work as a board: drag a card to resolve or ignore it. Upload your build's source maps (`homerun services sourcemaps upload`) and minified browser stack traces come back as your actual files and function names instead of `t` at `app.3f2a.js:1:48213`. A new issue, or a resolved one coming back, reaches you through your notification channels. [Error tracking](/homerun/docs/error-tracking). ## a dev box on the same server Up front: this one is a work in progress. Workstations are the newest thing in this post and the roughest. They work, but they need more love before I'd call them done, and they'll keep changing under you for a while. Try them, and tell me what breaks. **Workstations** are a VS Code in the browser (code-server by default, or openvscode-server) running on your own hardware, with a home directory that survives restarts. Pick a repository from a connected git provider and it's cloned in on first start, private ones included. Your git token goes into the credential store, so `git push` and `gh` work from the IDE's terminal without pasting anything. The setup is what makes it usable rather than a demo: - Extensions from Open VSX and your `settings.json`, applied on every start. - **Import from Settings Sync** reads what VS Code already syncs to your GitHub account and fills both in. Microsoft-only extensions that Open VSX doesn't publish are named and left out, not silently dropped. - A repository's dev container config can fill the settings in for you. - Presets, so the next one is two clicks. - **Auto-stop** when no browser has been connected for a while, so an IDE you forgot about isn't holding memory all night. Which, see the section above, is the theme of the month. It runs on the server itself, on an agent host, or on any Docker host you can reach over `tcp://` or `ssh://`. Workstations are personal: an admin doesn't see anyone else's. [Workstations](/homerun/docs/workstations). ## backups that don't upload everything every night Backups used to be a full `.tar.gz` of the volume, every time. Fine for a config folder, absurd for anything with photos in it. They're [restic](https://restic.net) snapshots now. The first backup uploads everything; every later one uploads only the chunks that changed, deduplicated across all of that volume's snapshots, so a nightly backup of a big volume that barely changes costs megabytes. Every snapshot is still a full restore point. The repository is encrypted with a password Homerun shows on the destination's page. Keep a copy somewhere that isn't Homerun: if its database dies, that password and plain `restic` are how you get your data back. Destinations aren't just S3 any more: SFTP, SMB and WebDAV too, which covers a NAS, a VPS, or a Hetzner Storage Box (there's a preset for it, tested down to a byte-for-byte restore). **Backups to keep per volume** caps the history and prunes what nothing uses. And restoring is a button on the volume's page, with **Wipe the volume first** if you want it to match the backup exactly, and the services using the volume stopped during the restore by default. Old `.tar.gz` backups stay listed and restorable. [Backups](/homerun/docs/backups). ## your setup, in a file Clicking through a form is fine until you have forty services and want to know what changed. A **Homerun Manifest** is a service's configuration as a file: port, env, resources, health check, build method, domains, login wall, previews. Commit it as `.homerun.json` (or YAML) and every deploy from that repository applies it before building. Or apply it to any service, image-based ones included, from the CLI or the API. [Homerun Manifest](/homerun/docs/manifest). For the whole instance there's a Terraform provider (OpenTofu and Pulumi work too) that covers stacks, services and every setting the dashboard has. The **Infrastructure as Code** page writes a starter configuration from what's already running and shows what changed outside it since. The REST API, the CLI and the MCP server cover all of it as well, so anything you can click, you can script, or ask Claude to do. [Infrastructure as code](/homerun/docs/infrastructure-as-code). ## it's an app on your phone now A deploy fails while you're away from a desk, and until now the dashboard on a phone was the desktop one, squeezed: tables running off the screen, menus pinned to a fingertip too small to hit. Responsive, technically. Usable, barely. It's been rebuilt for the phone, as far as a web page can go, and it feels like an app rather than a website you're tolerating: - A **floating tab bar** at the bottom, clear of the home indicator, with everything else in a **drawer** where each page says what it's for. - **Every context menu and dropdown is a bottom sheet.** Long-press a service and its actions slide up from the bottom, thumb-sized, instead of a tiny popover where your finger was. - A **create button** floating over Home, Services, Stacks, Templates and Workstations: deploy a service, start a workstation or browse templates without hunting through a menu. - **Search is a page**, not a keyboard-shortcut palette, with results as rows you can tap. - The new-service, onboarding and new-workstation forms are **steps**, one screen each, showing what comes next. - A section's **Save** stays on screen as you scroll, shows a dot when there's something unsaved, and stays greyed out until there is. - The profile is a hub: account, simple or advanced interface, light or dark theme, sign out. Desktop didn't lose anything; ⌘K and the sidebar are where they were. ## and the rest - **Certificates over DNS-01**, for domains on a DNS provider Homerun manages, which is how you get a wildcard, or a certificate for something that isn't reachable from the internet. [DNS](/homerun/docs/dns-automation#certificates-over-dns-dns-01). - **Pipelines**: your GitHub Actions, GitLab CI and Gitea Actions runs in Homerun, with timings and an estimated cost, linked to a service. [Pipelines](/homerun/docs/pipelines). - **Object storage** with a built-in [Garage](https://garagehq.deuxfleurs.fr) node, so apps that want S3 get S3 without a cloud account. [Object storage](/homerun/docs/object-storage). - **CrowdSec** and permanent IP bans, with the visitor's real IP even behind a Newt tunnel, and the network's abuse contact emailed if you want. [Blocked paths and IP bans](/homerun/docs/blocked-paths-and-ip-bans#crowdsec). - **Browser push notifications**, so a failed deploy reaches your phone, which is now somewhere you can fix it. - Appearance presets from **Windows 95 to Windows 7**. Nobody asked. It's staying. ## thanks To [Chooks22](https://github.com/Chooks22), the only person besides me in Homerun's history this month, and a big part of why the swarm side got better. Two pull requests merged: [#132](https://github.com/orochibraru/homerun/pull/132), which made the service settings accept a switch turned off (scale to zero's, and placement's) instead of refusing the save, and [#152](https://github.com/orochibraru/homerun/pull/152), which pointed the swarm status probe at the right endpoint. And eight issues, every one of them closed now, several of which turned straight into features in this post: [DNS-01 certificates](https://github.com/orochibraru/homerun/issues/150), [build server options](https://github.com/orochibraru/homerun/issues/148), [service placement](https://github.com/orochibraru/homerun/issues/123) and [path-based routing](https://github.com/orochibraru/homerun/issues/109). Using Homerun with swarm workers and writing down exactly where it hurts is worth more than any feature I'd have guessed at. If you run Homerun and something annoys you, [open an issue](https://github.com/orochibraru/homerun/issues). That's how a good part of this month happened. All of it is on stable, so the update notice in the sidebar already has it. And as [last time](/homerun/docs/upgrading): the new version boots next to the old one first, and only takes over if it answers.