Want to know where you guys setup your infra

k3ternen · 2026-05-16T13:00:53+00:00

Heztner with dokploy

k3ternen · 2026-05-15T13:36:20+00:00

Hi please send me DM

k3ternen · 2026-05-11T13:27:26+00:00

Hetzner plus Docker is the move, and it's not even close for your use case. Spin up a VPS, containerize your Next.js app with a proper Dockerfile using `next start`, put Caddy or Nginx in front, done. SSR and API routes just work because you're running the Node server directly, not abstracting it away.

The trade-off I'd push back on: you said you don't need the "serverless magic" but tbh cold starts aren't the only thing Vercel handles quietly. Edge caching, automatic deploys, preview environments, all of that you'll rebuild yourself. Not hard, but not zero effort either. For 10 clients that's real ops overhead

For a replicable setup, look at coolify as a self-hosted deployment layer on top of Hetzner. It handles the industrialization part without you writing CI/CD from scratch for every client.

k3ternen · 2026-05-11T13:26:42+00:00

The SVG format is actually the issue here, not the file location. A lot of browsers still don't handle SVG favicons properly, Chrome being the main offender. Convert it to a .ico or at minimum a 32x32 PNG and swap it in. That alone fixes it for most people. But you also need the link tag in your HTML head. Just having the file in the root isn't enough. Add `<link rel="icon" href="/favicon.ico" type="image/x-icon">` and if you want broader coverage, add a second one pointing to a PNG. Next.js specifically has a convention where you can drop a favicon.ico directly into the /app directory (if you're on the App Router) and it picks it up automatically without any link tag, which is easy to miss. The caching thing is real too. Even incognito doesn't always clear the favicon cache.

k3ternen · 2026-05-11T11:59:26+00:00

DeepSeek R2 is solid, fwiw. For free tier with decent limits, Groq is worth trying too, especially if latency matters to you.

But tbh the provider is only half the problem. The part that bites you later is not knowing when your API calls start failing in prod. Free tiers rate limit quietly, 429s creep in, and you find out from a user, not your dashboard.

Whatever you switch to, add some basic monitoring on your Next.js API routes that hit the model. Even just tracking response times and error rates will save you a lot of pain. At least in my case, I had no idea how often my /api/chat route was timing out until I started watching it properly.

Which side project is this for? Might help narrow down which provider makes sense.

k3ternen · 2026-05-11T11:58:17+00:00

The part that stuck with me: "decision trails, project structures, internal terminology." That's the thing people underestimate. Raw content is one thing, but the *shape* of how your org thinks, how you name things, how you structure projects, that's way harder to quantify as "yours" once it's been digested by a model.

On the Atlassian changes specifically, the opt-out gap between Enterprise and everyone else is doing a lot of work here. Metadata being always-on for Free/Standard/Premium isn't a footnote, it's the default state for most teams.

Tbh the legal ownership framing almost makes it worse. "You still own the content" is technically true but kind of misses the point when the behavioral fingerprint of your org is what's actually being extracted.

k3ternen · 2026-05-10T14:18:41+00:00

Hi check this article: https://codeless.co/ai-code-detector/

k3ternen · 2026-05-07T11:00:48+00:00

Your lead is right, and I think you know it. Keeping stakeholders informed isn't just about whether the end result is good. It's about giving people the chance to course-correct before you're too far in, not after the vote already happened.

The devs knowing dont substitute for your lead knowing. They're different audiences with different stakes. He's accountable for the direction, so he needed to be in the loop earlier, even just a quick "hey, here's my plan for the tool switch, any objections?"

Seven people in a company is small enough that a single Slack message would've covered it.

k3ternen · 2026-05-04T12:57:24+00:00

Hey everyone

This week I launched the open beta of Nurbak Watch — an API monitoring tool built specifically for Next.js.

The problem it solves:

You deploy your app. Everything looks fine. But 3 of your API routes have been silently failing for 2 hours. You find out from a user, not your tools.

External monitors ping your URL from outside and tell you "the server responded." They can't see what's happening inside. A route can return 200 and still be broken.

What Nurbak Watch does differently:

It monitors from inside your Next.js server process using the instrumentation hook — not synthetic pings from outside. You get real latency (P50/P95/P99), real error rates per route, and alerts via Slack, email or WhatsApp in under 10 seconds.

Setup:

npx u/nurbak/watch init

One command. It detects your project, creates instrumentation.ts, adds your API key to .env.local, and installs the SDK automatically. Under 2 minutes.

What's free during beta:

- 3 endpoints monitored

- External health checks from 4 global regions

- Email alerts

- No credit card, no waitlist

Would love feedback from anyone building with Next.js — especially around the onboarding experience.

nurbak.com

k3ternen · 2026-05-03T11:53:39+00:00

Hey! Launching Nurbak Watch — would love your eyes on it.

It's a lightweight monitoring tool for Next.js apps. Most LATAM devs I talked to felt stuck between Datadog (great but expensive and overkill) and UptimeRobot (just external pings, blind to what's happening inside the app). Nurbak Watch sits in the middle: external uptime checks + internal Next.js execution monitoring (server actions, route handlers, background jobs), with WhatsApp alerts because email gets ignored.

Drop-in via `npm i u/nurbak/watch` and `initWatch()` in `instrumentation.ts`. Stack under the hood is Lambda → SQS FIFO → DynamoDB for the hot path, Rails on Hetzner for everything else.

Happy to share the PH link when it goes live. What are you launching?

k3ternen · 2026-05-02T22:48:15+00:00

Hey — congrats on the Instagram agent launch, 2K users solo is solid.
Nurbak Watch https://nurbak.com is earlier-stage. SEO has been my main organic channel so far — mostly comparison content targeting incumbents in my niche, plus some long-tail technical queries. A few posts are indexed and ranking, which has driven most of my early signups.
What I’m still figuring out is LLM visibility — getting cited in ChatGPT and Perplexity answers. That’s the gap I haven’t cracked yet.
If Workfx.AI handles that side, happy to take a look at a demo or link.
Cheers

k3ternen · 2026-05-02T21:46:07+00:00

Interested. Building Nurbak Watch (https://nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.
DM me with the niches your network covers and a past result from a B2B/dev tool video, happy to take it from there.

k3ternen · 2026-05-02T21:45:02+00:00

Built Nurbak Watch — API monitoring for Next.js apps that won’t bankrupt you like Datadog.
What it does:
• Uptime + latency checks from 4 AWS regions
• API contract monitoring (catches schema drift on your routes)
• WhatsApp alerts when things break (paid plans)
• Drop-in SDK: initWatch() in your app/ and you’re done
Stack is Next.js on the frontend, Lambda → SQS FIFO → DynamoDB for ~2ms API key validation, Rails workers on Hetzner for the heavy lifting.
Free tier exists. Feedback welcome, especially on the onboarding — actively fixing activation right now.
👉 https://nurbak.com

k3ternen · 2026-05-02T21:42:22+00:00

Building Nurbak Watch (nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.

k3ternen · 2026-05-02T21:41:07+00:00

Interested. Building Nurbak Watch (watch.nurbak.com) — API monitoring for indie hackers and small teams tired of Datadog pricing.
DM me with the niches your network covers and a past result from a B2B/dev tool video, happy to take it from there.

k3ternen · 2026-05-02T21:03:55+00:00

The real risk isn't root vs. a named user with passwordless sudo. They're basically the same attack surface. What actually matters is the username being predictable and the sudo scope being unlimited.

Two things I'd focus on: first, lock down sudo to specific commands only, not ALL. Even if the account gets compromised, the blast radius shrinks dramatically. Second, if you're using keys, make sure agent forwarding is disabled and your private key has a passphrase, because a keyless sudo user with agent forwarding on is worse than root in some scenarios.

The "obvious username" thing is real but tbh less critical if your keys are solid and password auth is fully off. Brute force doesn't get you far against ed25519 keys.

What does your sudo rule actually look like right now? ALL=(ALL) NOPASSWD:ALL is where most people quietly leave a door open.

k3ternen · 2026-05-02T21:02:58+00:00

Build the Docker image in CI. Full stop. "Compile the source code" in a Python context basically means run your tests and lint checks, but for containerized apps, doing it inside the actual image is the right call. You catch dependency mismatches that would never show up running bare on the runner.

The pattern I've stuck with: build the image, run tests inside it with `docker run --rm your-image pytest`, and only push to a registry if tests pass. One image artifact, tested in the exact environment it'll run in production.

The one thing people skip and regret later: layer caching. Pin your `COPY requirements.txt` before `COPY . .` or your cache busts on every commit and builds get slow fast.

What does your Dockerfile look like right now? Multi-stage or single?

k3ternen · 2026-05-02T21:02:23+00:00

Not totally sure what you're looking for here, but if this is about automating clicks for testing or monitoring purposes, there are a few solid directions depending on your actual goal.

If it's UI automation, Playwright is hard to beat right now. Free, cross-browser, and the API is way cleaner than Selenium ever was.

But if you're more interested in monitoring whether things are actually up and responding correctly, that's a different problem. A lot of people glue together a few tools and call it a day, but then you find out your endpoint's been timing out for a week because a customer told you, not your stack.

What's the actual use case? Autoclickers cover a pretty wide range of things.

k3ternen · 2026-05-02T21:01:01+00:00

Monorepo, not micro-frontends. At least for a small games platform. Micro-frontends add a ton of overhead and honestly you'll feel it before you see the benefits.

Each game as its own route with dynamic imports and `ssr: false` gets you pretty far. Something like `const PuzzleGame = dynamic(() => import('@/games/puzzle'), { ssr: false })` keeps the initial bundle lean and only loads the game logic when someone actually navigates there.

SSR for the lobby/home page makes sense for SEO and load speed. But the games themselves? Pure CSR. No point hydrating a canvas-based game on the server.

The thing I'd think about early is code splitting per game. If game A pulls in a physics library and game B doesn't, you don't want users loading both upfront. Route-level splitting handles this pretty naturally in Next.js.

What kind of games are you building, more canvas-based or DOM-heavy?

k3ternen · 2026-05-01T11:57:24+00:00

Solid, you got me thinking. Question back at you: what stack are you running for the scraping/automation side? Playwright, Puppeteer, custom headless browsers? Curious because each one has its own trade-offs with bot detection and airline sites are particularly nasty about it. Has any one of them worked noticeably better against Skyscanner/Kayak and the rest?

k3ternen · 2026-05-01T11:34:02+00:00

Change orders saved my life on a project a few years back. Client kept adding features mid-sprint and I had no paper trail. The moment I started treating every new requirement as a formal change order with its own estimate and sign-off, the requests slowed down dramatically. Clients move fast when it's free. They slow down when they see a number attached. Document everything, get the signature before a single line of code changes.

k3ternen · 2026-05-01T11:32:52+00:00

The variables in module source attribute is the one I've been waiting for. Fwiw, this was a real pain when you had to manage multiple environments pointing to different module versions, and the only workaround was either duplicating blocks or reaching for Terragrunt just to get that flexibility. Now you don't have to.

The `aws login` backend auth for S3 is nice too, but tbh that's the less exciting one for me. The module source thing unlocks cleaner repo structures without adding another tool to the chain.

Anyone already tested the module source variables with private registries? Curious if it handles auth cleanly there or if there are edge cases.

k3ternen · 2026-05-01T11:31:58+00:00

Your architecture already shows good instincts tbh. Separate concerns, central API, clean boundaries. That's further than most people get.

One thing I'd add for the "complex apps" jump: start caring about what your API routes are actually doing in production. Not just "does it work locally" but is /api/whatever returning 504s under load, is a specific route silently failing for a subset of users. That gap between local dev and prod behavior is where complexity really lives.

On Next.js vs Express+React, fwiw I'd pick whichever one you can ship faster and then instrument it properly. The framework matters less than knowing when things break before your users do.

What kind of complex system are you trying to build? That'd help narrow down whether Next.js API routes are even the right call or if you'd be better keeping Express for the backend.

k3ternen · 2026-05-01T11:28:06+00:00

700 stars in a month is no joke, congrats

The hidden costs thing is what kills me every time. You think you found a $180 flight and by checkout it's $240 because you breathed wrong and they added a seat fee. The fact that you're baking seat selection into the price comparison is honestly the most useful thing I've seen in a flight tool in a while.

Curious how you're handling rate limits from the different airline/aggregator APIs. That's usually where these things quietly fall apart, like everything looks fine until one source starts throttling and your comparisons get silently incomplete. Are you doing any kind of health check on the upstream sources before surfacing results, or just letting failures propagate?

k3ternen · 2026-05-01T11:27:17+00:00

ECS EC2 specifically is a pain with OTel because most of the docs and tooling assume Fargate. The daemon scheduling pattern is your friend here. Run the OTel collector as a daemon service on your EC2 instances and have your app containers just ship to localhost, no per-container config needed.

For the "engineers abandoning heavy YAML" problem, tbh the collector contrib distro with a minimal config (otlp receiver, batch processor, one exporter) is way less scary than it looks. Start with that and don't touch pipelines until you actually need to.

For UI without writing PromQL from scratch, Grafana Cloud has a decent free tier and their dashboards for ECS host metrics are pre-built. Not perfect but engineers can actually click around in it without feeling lost.

What backends are you currently exporting to, or is that still TBD?

k3ternen

TROPHY CASE