Anneke Rusz

To be precise about the diagnostic, because it's worth having for next time: 137 is 128 + 9, so SIGKILL. That on its own doesn't mean OOM - you also get it when compose gives up waiting during docker stop and kills the container. The thing that told you it was OOM is the OOMKilled: true you already checked, so good instinct.

If it had been the stop-timeout case, the fix would be handling SIGTERM properly rather than touching memory at all.

Quickest unblock is to drop --frozen-lockfile in CI and let it regenerate. The lockfile is a suggestion anyway and you get a clean install every time.

Internal dashboard, six weeks, two devs: consider that the bigger question is whether you can get away without SSR. A client-rendered SPA behind auth removes an entire category of problems (hydration, server state, deployment shape) and both frameworks do that perfectly well.

One more angle: check whether you're mixing into a limiter late at night. A lot of people push the master harder as they get tired and the extra density reads as excitement in the moment and mud the next day.

Add a smoke test. One Vitest file that calls getCollection and asserts length > 0 catches this whole class of thing forever and takes about four minutes to write.

Container versus managed is slightly the wrong axis. The question is who is on the hook when it's broken, and on a two-person team shipping fast the answer is "whoever least wants to be".

$19 is roughly 40 minutes of one developer's time a month. If self-hosting costs you more than 40 minutes a month averaged over a year - including the one bad night: managed is cheaper. In my experience at 8 GB with simple usage, self-hosting comes in well under that, as long as you do the WAL thing.

Whichever you pick, hide it behind a small struct with two or three methods rather than passing the map around. Then swapping the implementation later is an afternoon rather than a refactor, and you can benchmark both properly.

If it comes back within a few weeks of a flush and a rod swap, then it's worth testing the well itself for sulphate and for bacteria, because you may be continuously reseeding the tank. But start with the heater, it's cheaper and it's the answer most of the time.

Before any of the orchestration: are you building on the box? docker compose build during a deploy on a small VPS means your build is competing for the same two cores as the app that's still serving. Build in CI, push to a registry, and deploy becomes pull && up -d - and the pull happens before anything stops.

That change alone usually removes most of the window, and it turns rollback into a tag change instead of a rebuild.

Before you buy a tank, also make sure the small tube to the pressure switch isn't clogged with iron or sediment, which produces very similar surging. It's a five minute check and I've seen it be the whole problem twice.

One diagnostic: record the same line with the mic 20cm away and again at 1m, then compare. If the boxiness scales up with distance, it's the room. If it's roughly the same at both, it's the mic, the source or your chain.

On alpine vs slim for Prisma specifically: alpine is musl, so you need the musl engine target set in binaryTargets. It works, but it's one more thing to get wrong. If you aren't chasing the last 70 MB, slim is the boring correct answer.

Same warning for anything with native modules, sharp, bcrypt, better-sqlite3. Alpine will want either a build toolchain or exactly the right prebuilt, and an evening of debugging that costs more than 70 MB is worth.

Adding a fn assert_send<T: Send>(_: &T) {} and calling it on your future in a test gives you the failure at the point you care about rather than at the spawn site. Handy when the spawn is three layers up.

Neither having shipped Astro is a real cost but a small one: content collections and the client:* directives are basically the entire API surface for a docs site. Budget two days of confusion about when a component is server-rendered versus hydrated and you're through it.

The thing I'd actually be careful about is MDX. If your interactive demos import Svelte components into prose, get that pipeline working on day one with one page before you migrate 40. That's where the sharp edges are.

Ran it roughly like this. The 'when did it last happen' question got me a nine-minute story about a duplicate payment in April. The whole call turned on it.

Did this. They said yes, then didn't, then did it eight days later after one nudge. Which I gather is also normal.

Run astro build and look at what actually ships per page. That output tells you more than any advice in this thread, if a page you thought was static is pulling 60 KB, something on it has a directive you forgot about.

But if I record at -18 and then bring it up in the mix, doesn't the hiss come up too?

3 o'clock is basically maxed on this unit, so that lines up. Ordering one.

Watch egress on the uploads. 40 GB sitting in R2 is fine - no egress fee is the entire reason to use it. But if you serve those files through your API rather than direct from R2, you pay for that traffic on the VPS side. Hetzner's included traffic is generous but not infinite, and it's an easy thing to not notice until the overage line appears. Signed URLs straight to R2, always.

Deciding it up front rather than discovering it is a completely different mental habit from what I've been doing. Going to try that on the next module.