I have quite a few frontend projects. Once a project is written, the same string of jobs follows: run the build, store the static files, configure a domain, check which version is live, and find a working version when something goes wrong.

Those jobs used to be scattered across GitHub Actions, OSS, server configuration, and my own memory. A one-off release was fine. Coming back a few months later meant working out how that particular project had been shipped.

meow manages that whole release path. It started with versioned static files in OSS. It has since grown into a frontend release platform.

One project, from push to production

Once a project is in meow, I configure its repository, domain, runtime, and scripts. From then on I can start a build from the project page. The project's own workflow builds the site; meow receives the result and keeps the version record and a URL I can open directly.

Build progress, the version currently online, and any waiting candidate all appear on the same page. Reusable scripts can live in the script library and be enabled per project instead of being copied into several repositories.

None of those pieces is unusual on its own. Together, they mean adding a project no longer involves assembling another release system. It joins the one meow is already managing.

A version is more than a number in a log

Every meow build remains independent. v21 and v22 keep their own files and URLs, so a new version does not overwrite the old one. I can open two versions to compare them, or return to an older one without rebuilding old code.

That saved ashita once. When a navigation release broke the site, I temporarily put v55 back online. The page recovered quickly and I did not have to search a server for old files. Version history here is not decoration; an older version can serve traffic again.

Release immediately, or stage it first

meow recently gained candidate versions and conditional rollout. A new build can still go live immediately, or it can wait as a candidate. The candidate has its own preview URL and can receive only requests that match a rule. If it looks right, I promote it to everyone. If it does not, I pause or end the rollout.

Staged rollout is one new part of the platform. Projects, builds, versions, domains, scripts, previews, releases, and rollbacks still stay on the same path, and a failed build does not displace the version already online.

meow itself and ashita now use this release flow. When I make another frontend project, I can connect it to meow instead of rebuilding the same scattered setup.

meow's source lives on GitHub: meow (opens in a new tab) · meow-api (opens in a new tab) · meow-release (opens in a new tab). This blog is released through it.