Tech USP: Updates aren’t surprises. You set the window when maintenance can happen, we patch security issues without bothering you, and big changes come with a long runway and your call on the timing.
Buyer’s view: “We had a tool update brick our internal app at 11:00 on a Tuesday — the entire warehouse stopped scanning.” — that’s the failure mode. Kumiko’s answer: you set the window, we never push major changes during your peak, and security patches go out before anyone exploits them.
Three kinds of updates, three rules
Security patches. We watch the CVE feed for the components your app depends on. When something serious shows up, we patch it for you — typically within a day of disclosure. You don’t have to do anything. You get a notification after it’s done, with a one-line summary of what was fixed.
Why force-patch security? Because “we’ll patch when convenient” is how breaches happen. The alternative — you tracking CVEs across Postgres, Bun, Redis, Node, your dependencies — is what you hire us to avoid.
Minor updates (new features, internal improvements). Held until your maintenance window. Default is “Mon–Fri, 02:00–04:00 in your timezone” — you can change it in account settings, or pick a specific weekly slot. You can also mark whole months as freeze (Black Friday, Christmas, your busy season) and we hold updates until the freeze is over.
Major updates (anything that changes how the system works). Opt-in, on your schedule. The previous version stays available for 6 months as a comfort window — you migrate when you are ready, not when we ship. We tell you what changes, what to test, and stay on the call if you want.
Phased rollout — never all at once
When we ship, your app isn’t in the first batch. Updates roll out in phases:
- Internal test instances first.
- A small group of pilot customers next.
- The next group, after we’ve watched for a while.
- Then everyone else.
Between each step, we wait. If error rates rise or something looks off, we hold the rollout — the phase you’re in determines whether you’re affected. Most issues get caught before they hit the majority of customers.
High-availability for the apps that need it
Default behavior on a standard tier: an update means a brief restart, on the order of a few seconds. For 95% of internal tools, that’s invisible — the user reloads, the page is back.
For apps that genuinely can’t tolerate even seconds of downtime — public-facing tools, status pages, real-time control systems — we offer a high-availability mode that runs your app in parallel during updates. Old version stays up while the new version comes online, traffic switches over without dropping a request. Available on Pro and above, ask us when you need it.
What you control
| Setting | What it does |
|---|---|
| Update window | Day-of-week + time slot in your timezone |
| Freeze months | Mark months where no non-critical updates ship (peak season, Black Friday, audit prep) |
| Update-now button | Don’t want to wait for the window? Trigger the next pending update on demand |
| Notification channel | Email, Slack, webhook — your call |
| HA mode (Pro+) | Zero-restart updates if you opt in |
What we don’t do
We don’t push major changes during your peak season. We don’t surprise you with breaking API changes. We don’t update at 11:00 on a Tuesday “because that’s when our deploy ran”. We don’t make you research CVEs in your stack at 03:00 because something blew up.
The control is yours. The work is ours.