5 min read

Yesterday's Top Launches: 1 Tools from October 22, 2026

Hoistbay, a free open-source desktop app for macOS and Windows, quietly launched on October 22 to handle the routine S3 and CloudFront tasks that follow each deploy.

Yesterday's Top Launches: 1 Tools from October 22, 2026

The Quiet Release of October 22

Only one thing landed on yesterday’s calendar, and it is the kind of tool that rarely gets a launch-day thread. No announcement video, no waitlist. Hoistbay showed up on GitHub and started solving a problem most developers have quietly accepted as normal overhead: the small pile of S3 and CloudFront chores that follows every single deploy. Among the new developer tools worth keeping an eye on this week, it is the one that will probably save the most people from themselves.

Hoistbay

Hoistbay is a free, open-source desktop app for macOS and Windows built around one assumption: if you publish a site to Amazon S3 and serve it through CloudFront, you have already made the same mistakes more than once. Wrong Cache-Control headers. A build uploaded a second time because the HTML got cached for a year. A SignatureDoesNotMatch error that took an hour to trace back to a session token. The app treats those as the actual product surface rather than edge cases.

The core of the workflow is header rules. You define rules per bucket, keyed by file pattern, and they cover Cache-Control, Content-Type, and Content-Encoding. The example on the site is the familiar static-site split: *.js and *.css get a long max-age, *.html gets no-cache. Set it once and every subsequent upload inherits it. For anyone running a deploy script that ends with “and now remember to set the right headers,” this removes a step that has no business being manual.

Multi-account handling gets similar attention. You save a profile per account and region, switch between prod, staging, and a sandbox with a click, and temporary session credentials work properly. Bucket regions are detected automatically, which quietly eliminates one of the more annoying causes of signing failures. If you have ever pasted a key into a terminal at 11pm and then spent twenty minutes wondering why it was rejected, that feature alone justifies a download.

Uploads, downloads, and bulk operations are what you would expect from a file manager pointed at S3, with folder structure preserved and cross-bucket or cross-region move and copy supported. CloudFront invalidation sits in the same window: distributions listed next to their buckets, invalidate /* or specific paths after a deploy, and watch the status until it confirms. Transfers, deletes, and cache clears all report into a single Activity panel with per-object failure status rather than a silent stop halfway through.

There are some smaller repairs in here that suggest the developer actually uses these services daily. Keys with spaces or special characters go through custom Signature V4 signing instead of breaking. Bulk deletes send the required Content-MD5. Folders beyond 1,000 objects paginate fully instead of showing you the first page and pretending that is everything. Any object’s Content-Type, Content-Encoding, or x-amz-meta-* tags can be fixed in a details pane without re-uploading the file. Network failures retry up to three times, and whatever still fails is named in the panel instead of vanishing.

What the security model actually looks like

The trust question matters more than the feature list here, and the answer is refreshingly boring. There is no backend. No analytics. No telemetry. Credentials live in the OS keychain through flutter_secure_storage, which on macOS means the Keychain and on Windows means Credential Manager, and keys are only read when the app talks to AWS. Everything goes to the official regional endpoints over HTTPS via the aws_s3_api SDK. The code is MIT licensed, so you can audit it, and the README documents the exact IAM permissions each feature requires if you prefer to scope them down.

That combination means adopting Hoistbay does not add another vendor to your AWS security review. For a category of tool where the default assumption is that a third party now holds your keys, that is a genuine differentiator.

Where it is rough

Nothing is finished on day one, and this is version 1.1.1. The macOS build is not notarized yet, so a first launch requires right-click Open. Windows will throw a SmartScreen prompt that you get past through More info and Run anyway. A Linux client is listed as coming soon with no date. And the scope is intentionally narrow, which cuts both ways: if you are on GCS, Azure Blob, or a CDN that is not CloudFront, there is nothing here for you. That is fine. Plenty of tools try to cover every cloud and end up mediocre at all of them.

The interactive demo on the site is worth a few minutes before you install anything. It is a working replica of the app running in the browser and does not touch AWS, so you can click around the header rules and invalidation panels without handing over a credential.

Who should care

Developers shipping static sites, front-end teams with a build-to-bucket pipeline, and freelancers juggling several client accounts will get the most out of it immediately. Anyone who has built an internal deploy script around the AWS CLI will recognise the exact pain points being addressed, and may find this replaces a good chunk of that script with something clickable. It is free, so the cost of trying it is a download and a right-click.

For a Thursday with only one launch on the board, that is a reasonable trade.

Quick Links