pops | Boogas

Platform engineer. k8s, tf and the pager that comes with them. Notes from prod, opinions on tooling. Dad of three. Side gig after bedtime. Open to work.

[pops | Boogas @devpops_]

Make shipping software routine.

DevPops is my engineering studio: web software, plus the pipelines, cloud (Azure, AWS, Google Cloud) and Kubernetes platforms it runs on.

You work directly with the engineer doing the work, first commit to production.

https://t.co/JgWSBX7Fnn

[pops | Boogas @devpops_]

@PotLady_ Hru today ?

[pops | Boogas @devpops_]

@HughTipping Clean way to price it. The part that bites later is drift: dedicated clusters slowly stop matching the shared one. Same Terraform modules and one GitOps repo for every cluster, with only per-tenant values different, keeps upgrades one PR instead of N.

[pops | Boogas @devpops_]

@0xlelouch_ Solid list. If I had to pick one starting point for working devs: requests/limits and probes. A lot of small-team k8s pain traces back to a missing readiness probe or a memory limit set by guesswork. Get those right before touching autoscaling.

[pops | Boogas @devpops_]

@dgniccum Cheap guard for this: validate required env vars at startup and exit non-zero if any are missing, then run a smoke test against one real endpoint right after deploy. A missing var then fails the deploy instead of the first user's request.

[pops | Boogas @devpops_]

@bbbrint Strong list. Two I'd put near the top: alerts that reach a phone, not a channel nobody watches, and a one-command rollback you've actually used. The first bad deploy with paying customers is when you find out whether either exists.

[pops | Boogas @devpops_]

@lyeuhm It's the Ubuntu mirrors, not you. Quick unblock: point apt at another mirror in the Dockerfile, or add -o Acquire::Retries=5. Longer term, bake your apt deps into a base image once and stop running apt-get install on every workflow run.

[pops | Boogas @devpops_]

@0xJackMarsh @github @vercel The pattern behind most scary CI bills: every push rebuilds and retests everything from scratch. Remote cache fixes the root cause. Teams not ready for a full RBE setup still get a big chunk of the win from Turbo or Nx remote cache plus cancel-in-progress.

[pops | Boogas @devpops_]

@orenaksakal For side projects I'd default to LXC: lighter, faster to spin up, easy vzdump backups. Use a VM when something needs its own kernel, Docker with odd networking, or real isolation. And keep the Proxmox UI behind Tailscale or a VPN, not the open internet.

[pops | Boogas @devpops_]

@frederickjames Nice, one $20 box goes a long way. What I'd add before it matters: nightly off-box backups you've restored at least once, an uptime check from outside Hetzner, and the setup in a script or Ansible so a dead VPS is a 30 min rebuild, not a weekend.

[pops | Boogas @devpops_]

@twtayaan The trick is that nobody needs the whole landscape. A boring pipeline, one way to deploy, logs and a few alerts. Add the rest only when a real problem asks for it, not because it's on the map.

[pops | Boogas @devpops_]

@PratikAtX Sure brother, tag me in a post and I give you support in public

[Messi @Messia367558]

An ordinary, simple-looking stone on the outside, but a rare masterpiece of nature within... Truly, some things are far more precious inside than they appear on the outside. ❤️✨

[pops | Boogas @devpops_]

@buildwithpb Anytime buddy

[pops | Boogas @devpops_]

I'm a one-person studio in Bucharest. I build the product and the pipeline that ships it. This week I'm going to reply more to people stuck on CI, deploys and cloud bills, because that's the work. If you're a founder without a DevOps person, that's who I'm writing for. https://t.co/d6rkLGQVAT

[pops | Boogas @devpops_]

@PratikAtX Congrats 👏 and GL

[pops | Boogas @devpops_]

@yunchanyq6 Thanks. Once you know which bucket is slow, the fix is usually obvious: shallow fetch for checkout, lockfile-keyed cache for deps, and split or skip tests that don't need to run on every push.

[pops | Boogas @devpops_]

When CI is slow I don't start with faster runners. I time the job in three buckets: checkout, dependencies, and tests. The waste is usually in one of those, and a quicker machine won't fix a job that repeats work it already did.

[pops | Boogas @devpops_]

@paschals_robert Exactly. One staging rehearsal also shows whether the migration rollback is actually safe, not just whether the app comes back up.

[pops | Boogas @devpops_]

@buildwithpb Hope it quiets down. If docker stats still shows a busy container after you cap the VM, the leftover culprit is often a file watcher on a bind-mounted node_modules.

[pops | Boogas @devpops_]

@strube That's a common first pass with Paratest. Shared database state is usually the culprit, not the runner. Isolated schemas or a fresh migrated dump per process, and no shared Redis or cache between workers, often lets you keep the suite parallel without a full rewrite.

[pops | Boogas @devpops_]

@buildwithpb Start with the bill itself: sort by service, then look at NAT Gateway, idle staging, and unattached disks. A budget alert plus cost anomaly detection catches the next spike mid-month. If you want a second pair of eyes on it, that's the work at https://t.co/3NkEdD5omn.

[pops | Boogas @devpops_]

@PratikAtX The portal hops are the usual pain. One pipeline that builds a single artifact and deploys it to each environment, with env-specific config in code (Bicep/Terraform or a values file), keeps Azure and AWS from becoming a click-path you have to remember.