标签：#DevOps

Introduction: The Developer's Credential Dilemma As developers, we manage dozens—if not hundreds—of sensitive credentials daily. From database connection strings and SSH keys to API tokens and third-party service logins, keeping track of these secrets securely without destroying developer velocity is a constant challenge. Far too often, developers fall into bad habits: reusing simple passwords, storing raw API keys in unencrypted .env files committed to Git, or sharing production tokens over Slack. These practices are major security risks. While there are many password managers on the market, Bitwarden has rapidly become the preferred choice for software engineers and DevOps teams. In this article, we will explore why Bitwarden is uniquely suited for developers, examine its developer-centric feature set, and walk through practical CLI examples. 1. True Open-Source Transparency For security software, trust is paramount. Closed-source proprietary password managers force you to trust the vendor's claims without verification. Bitwarden flips this model on its head. The entire Bitwarden codebase—including web vaults, mobile applications, desktop clients, browser extensions, and backend infrastructure—is 100% open source under GPLv3 and AGPLv3 licenses. You can inspect the source code directly on GitHub. Why Open Source Matters for Security: Public Auditing: Security researchers and the global developer community continuously audit the code for vulnerabilities. No Hidden Backdoors: Transparency ensures there are no intentional backdoors or tracking mechanisms. Longevity: Even if the company behind Bitwarden were to disappear, the software and server implementations could be maintained by the community. 2. Developer-First Workflows: The Bitwarden CLI ( bw ) Most password managers focus exclusively on GUI interfaces designed for non-technical users. Bitwarden provides a full-featured Command Line Interface (CLI) that allows developers to interact with their vault directly f

Opening four coding-agent sessions feels like scaling. On a shared machine, it is closer to giving four fast contributors the same repository, shell, credentials, ports, caches, and merge queue without deciding who owns any of them. The first failure probably will not come from model quality. One task will restart a dev server while another is testing it. Two workers will touch the same lockfile. A branch will pass its own checks and still conflict with a migration waiting in the merge queue. Four chat windows create concurrency. Four owned workspaces plus one deliberate merge queue create a system. Parallelism multiplies shared state Tasks that sound independent in a prompt can overlap in the environment. A frontend change and an API change may both edit generated types. Two test runs may expect the same database or browser profile. Separate worktrees can still launch services on the same port, read the same environment variables, and write to shared caches. The agents do not collide in the prompt. They collide in everything the prompt lets them touch. This is why adding a second agent changes the job. With one worker, the operator can keep a surprising amount of state in their head. With four, every unstated assumption becomes a race condition or a review problem. The fix is to make ownership visible before execution starts. A worktree is the start, not the boundary Git worktrees are a sensible first step. Each task gets its own branch and working files, so one agent is less likely to overwrite another agent's edits by accident. That is useful isolation, but it is narrow isolation. A worktree does not reserve a port. It does not separate process trees, temporary directories, credentials, network access, browser state, or external services. Treating it as a sandbox gives the workflow more confidence than the boundary deserves. Proliferate is an instructive project example because its documented design pairs isolated task worktrees with visible review state. The imp

A modular monolith without enforcement is not an architecture — it is a monolith with good intentions. The Problem Most teams skip the modular monolith and jump straight to microservices. The ones that do attempt a modular monolith rely on convention — "don't cross module boundaries" — which fails the moment deadlines hit. The difference between a well-structured modular monolith and a mess is whether boundaries are maintained by tooling or by convention. The Solution Structure Each module is a pair of .NET projects: src/Modules/ Orders/ YourApp.Orders/ ← internal: domain, application, infrastructure YourApp.Orders.Contracts/ ← public: DTOs, interfaces, events Payments/ YourApp.Payments/ YourApp.Payments.Contracts/ The rule : modules may only reference each other's *.Contracts projects. The compiler enforces this physically — no project reference means no type access. Four Layers of Enforcement Compiler — project references prevent cross-module type access NetArchTest — architecture tests fail the build on namespace-level violations NDepend CQLinq — catches dependency cycles and coupling the compiler can't see Quality Gates — block PRs that introduce new boundary violations Module-Scoped Data Each module owns a dedicated DbContext with a schema prefix ( orders.* , payments.* ). No module queries another module's tables. Cross-Module Communication Modules communicate via MediatR in-process events. Orders publishes OrderPlaced ; Payments subscribes — without Orders knowing Payments exists. This is also the extraction seam: when you eventually extract a module into a service, MediatR becomes a message broker. The event contract stays the same. Parallel CI strategy : matrix : module : [ Orders , Payments , Inventory ] fail-fast : false Each module's tests run in parallel. CI time scales with the slowest module, not the total count. The Extraction Path When a module genuinely needs independence: Add outbox table → publish to real broker Replace MediatR handlers with brok

Google's developer verification requirement starts enforcing in about a month, and Brazil is one of the four countries it lands in first. If you work here, this is not a 2027 problem you get to read about later. Most of the coverage I've seen frames this as a sideloading story, or an F-Droid story, or an "Android is losing its freedom" story. Those are real arguments, but they're not the thing that's going to interrupt my week. The thing that's going to interrupt my week is much smaller and much more annoying: how a build gets onto a QA engineer's physical phone. The rule, in one paragraph From September 30, 2026, apps installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand must be registered to a verified developer. Certified devices are roughly 95% of Android outside China. The requirement applies whether the app came from Play, from an alternative store, or from an APK you downloaded off a link. Verification means an identity check plus registering each package name against the SHA-256 fingerprint of its signing key. Global rollout follows in 2027. Two things matter for how you read that. It's the package name that gets registered, not the app in some abstract sense. And it's tied to a specific signing key. What does not break Before the panic, the exemptions are wide, and if you only skim one section, skim this one. ADB installs are unaffected. Local development and testing over adb install keep working exactly as they do today. Google has been explicit about this. Enterprise deployment is exempt. Apps installed through an EMM Device Policy Controller, or published as private apps in Managed Google Play, are exempt indefinitely. If your organization ships to managed clinic devices through an MDM, that path is fine. If you're already on Play, you're probably already done. In March 2026, Google auto-registered package names and signing keys for the large majority of existing Play apps under the accounts that own them. Worth confirming i

I kept hitting the same wall with coding agents. One Claude Code or Codex session in a repo works great. The moment I wanted two tasks moving at once - login in one terminal, payments in another - they started stepping on each other. Same working directory, same checked-out branch, two processes editing the same files. Chaos. The fix turned out to be a Git feature that has been sitting there for years: git worktree . It gives you several working directories backed by the same repository . Each folder has its own checked-out branch, but all of them share the same objects, commits and branch list. The setup From your main checkout: git worktree add ../integration -b integration main git worktree add ../feature-login -b feature/login main git worktree add ../feature-payments -b feature/payments main Which leaves you with something like: project/ ├── main/ → branch main ├── integration/ → branch integration ├── feature-login/ → branch feature/login └── feature-payments/ → branch feature/payments Now every agent gets its own folder. One terminal per worktree, one agent per terminal, and nobody touches anybody else's files: cd feature-login # agent 1 works here cd feature-payments # agent 2 works here, at the same time The part that surprised me: no push, no pull My first instinct was: agent finishes login, pushes the branch, then I pull it into integration. That's the muscle memory from working in a team. It's unnecessary here. All the worktrees belong to the same repository on the same machine, so Git already knows every branch locally. When agent 1 finishes: cd feature-login git add . git commit -m "feat: implement login" ...the integration worktree can merge it directly: cd ../integration git merge feature/login git merge feature/payments npm test No git push , no git pull . The directories are different, but feature/login and integration are branches of the same repo. When integration is green: cd ../main git merge integration You don't even have to wait for a worktr

Docker has become an essential tool for developers, DevOps engineers, and anyone deploying applications today. It solves the age-old problem of “it works on my machine” by packaging an application with everything it needs into a lightweight, isolated unit called a container. This guide takes you from absolute beginner to confidently building and running real‑world applications with Docker. 1. Why Docker Exists (The Problem) Before Docker: “It works on my machine” is the daily mantra 😵 Different OS → different bugs, different dependency versions Onboarding a new developer takes hours (Node, DB, caches, environment variables…) Servers are hand‑configured snowflakes, impossible to reproduce exactly Docker solves this: 👉 It packages your app plus everything it needs into a lightweight, isolated unit called a container . That container runs identically everywhere : Your laptop A teammate’s machine A CI/CD pipeline A production server in the cloud 2. What is Docker? Docker is a platform that lets you: Define application environments as code ( Dockerfile ) Build images from those definitions Run containers from those images Share images via a public registry ( Docker Hub ) Simple analogy: Docker = Lunch box 🍱 Your app + dependencies = the food inside Container = the sealed box you can carry anywhere, and when you open it the meal is exactly the same 3. Key Concepts (Must Know First) 📦 Image A blueprint of your application environment. It contains the OS files, dependencies, code, and configuration needed to run your app. Example images: node:18-alpine – Node.js on a tiny Alpine Linux postgres:15 – PostgreSQL database server nginx – a fast web server Think: “Class in OOP” 🚀 Container A running instance of an image . You can have multiple containers from the same image, each isolated from the others. Think: “Object created from a class” 🧱 Dockerfile A text file that defines how to build an image . It lists step‑by‑step instructions, like a recipe. Example: FROM node:18 WORKD

I just released Vincent 0.7.0 , and this release marks an important milestone for the project: Vincent now builds Vincent. All development on the project now goes through Vincent workflows — from creating an approved GitHub issue through planning, implementation, verification, human gates, merge, and release preparation. The journey from 0.4.0 to 0.7.0 added quite a bit. Workflows became real interfaces Workflows can declare their expected inputs, including: labels types required fields RE2 validation Vincent also gained a workflow-authoring skill designed around a principle I care about quite a lot: don't use an AI agent when deterministic automation can do the job better. Commands and native control flow come first. Agents are used where reasoning is actually required. Recovery became part of the workflow Real automation fails. So Vincent now has mechanisms for continuing rather than throwing work away: follow-ups on completed tasks recorded repair agents for blocked tasks retry backoff safer daemon backup/restore improved diagnostics through vincent doctor The control plane became scriptable 0.7.0 significantly expands the CLI. Tasks can now be started idempotently, created from GitHub issues, populated through JSON/stdin, queried through vincent status , limited with max_cost_usd , and integrated with notifications. Logs, transcripts, approvals, retries, repairs and task answers can all be handled without entering the TUI. The TUI hasn't been neglected either — tasks now open into a dedicated workspace containing steps, attempts, metadata, output and file-grouped diffs. Vincent builds Vincent This is the part I'm most excited about. My own development workflow now uses Vincent itself: GitHub issue ↓ planning ↓ implementation ↓ documentation ↓ cross-platform verification ↓ human gates ↓ merge ↓ release audit Claude Code, Codex or Cursor can provide the inference. Vincent owns the durable workflow, state and verification around them. That's the architecture I've b

Nginx Load Balancing with DNS-Based Service Discovery on Incus Hari ini saya buat satu practical lab untuk memahami Nginx Load Balancing , DNS-based Service Discovery , dan operational logging dalam persekitaran self-hosted menggunakan Incus. Lab ini bermula dengan architecture yang simple: Client │ ▼ Nginx LB │ ├──► web01 └──► web02 Kemudian saya tambah satu DNS server supaya backend tidak perlu bergantung sepenuhnya kepada hard-coded IP address. 1. Architecture Final architecture: DNS dns / dnsmasq 10.107.109.18 ▲ │ DNS lookup: web.incus │ │ Nginx LB 10.107.109.69 │ Load Balancing ┌──────────┼──────────┐ ▼ ▼ ▼ web01 web02 web03 .100 .253 .xxx Ada dua jenis communication flow dalam architecture ini. DNS resolution Nginx LB ──────► DNS │ └── web.incus ↓ .100, .253, .xxx DNS hanya digunakan untuk mengetahui IP address backend. HTTP traffic Client │ ▼ Nginx LB │ ├────► web01 ├────► web02 └────► web03 DNS tidak membawa HTTP traffic . DNS hanya menjawab: Where is web.incus ? Nginx kemudian menggunakan IP yang diperoleh daripada DNS untuk melakukan load balancing. 2. Static / Hard-Coded Upstream Cara paling mudah untuk configure Nginx Load Balancer ialah dengan meletakkan IP backend secara terus. Contoh: upstream backend { server 10.107 .109.100 ; server 10.107 .109.253 ; } Architecture: Nginx LB │ ├──► 10.107.109.100 │ └──► 10.107.109.253 Kelebihan Simple Mudah difahami Predictable Sesuai untuk environment kecil Tidak memerlukan DNS service discovery Kekurangan Kalau tambah web03 : web01 web02 web03 Nginx configuration perlu diubah: upstream backend { server 10.107 .109.100 ; server 10.107 .109.253 ; server 10.107 .109.xxx ; } Kemudian configuration perlu divalidasi dan biasanya Nginx perlu di-reload. 3. DNS-Based Service Discovery Pendekatan kedua ialah menggunakan hostname sebagai service identity. Contohnya: web.incus DNS: web.incus ├── 10.107.109.100 ├── 10.107.109.253 └── 10.107.109.xxx Nginx tidak perlu mengetahui backend IP secara hard-coded. Contoh: resolver 10.

After development comes deployment - whether on-premise or on a cloud based environment. And then we face a simple question: how much resource should I assign to this system? What is the ideal numbers? If we get this wrong, we often need to go back time and again to fine tune - either to ensure our application is capable of handling the targeted load, or to avoid paying for resources we are not using. This article explains the approach step by step. So that we spend just enough time upfront to avoid spending exponentially more time and money at later stages. Who Is This For? This article is written primarily for developers. But if you are a manager or a CTO, there are sections written specifically for you. Feel free to jump straight there. 👉 If you are a Manager or Project Manager 👉 If you are a CTO or Architect For everyone else - the full article is worth reading top to bottom at least once. But if you are revisiting a specific topic, jump to whatever is relevant. Table of Contents Local is the Starting Point When Should You Start Thinking About Right Sizing? How Long Will This Actually Take? Start With What You Have - Your Local Setup Setting Up Your Load Generation - The Hammer The Cost of Testing - This Is Not Free Sizing Your Pod More Resources Per Pod or More Pods? Scaling - Easy to Set Up, Hard to Get Right Periodic Right-Sizing - You Are Not Done Yet Local is the Starting Point Local system is always where we start. To try things out, to check if things work. But 99% of what we test locally is the sunny day scenario. Does the MVP work? Does the happy path hold? Even if you're diligent enough to test negative scenarios, you're almost certainly not testing production-level load on your laptop. Which means you have no idea what resources your app actually needs when it matters . This is where the problem starts. On local, we routinely kill the heavy IDE, close browser tabs, shut down background processes -without ever stopping to ask: how much memory and CPU d

I wrote this for the All Things Agentic Hackathon. Every incident-response demo you have seen ends the same way: something breaks, the agent fixes it, everyone applauds. I want to show you the opposite. Here is my agent, at 95% confidence, having correctly diagnosed a bad deployment, deciding not to roll it back. That refusal is the whole project. The question underneath At 3am an alert fires. An engineer wakes up, reads several hundred log lines, correlates them against recent deploys, and rolls something back. Most of it is mechanical. It is an obvious target for automation. But "automate it with an LLM" does not dissolve the problem, it relocates it. The new question is: how much would you let an agent change in production without asking you first? Give it too little and it is a chatbot that writes summaries. Give it too much and one confidently wrong diagnosis takes down your service at 3am with nobody watching. I named the project Sonjomon — Bengali for restraint. The autonomy ladder An agent should not have one blanket permission level. How far it may act alone is a function of two things: how confident it is, and how much damage the proposed action does if that confidence turns out to be wrong. tier = f(confidence, blast_radius) OBSERVE record findings, take no action SUGGEST recommend to a human, do not execute APPROVE stage the action, execute on explicit approval ACT execute now, then verify independently A restart is medium risk — reversible in seconds. A rollback is high risk — it shifts production traffic, and a needless rollback during a real outage extends it. Deleting data is critical, and no confidence level unlocks it. Six conditions can only ever push the tier down, never up: the blast-radius ceiling, thin evidence, a similar action that just failed, a third attempt at the same fix, a stale incident, and a global dry-run switch. Nothing pushes it up. A wrong action is far more expensive than a missed one. Three things the model does not control It

Most nginx misconfigurations announce themselves. You typo a directive, nginx -t fails, you fix it. That feedback loop is fast and it works. The dangerous ones are different. The config is valid. nginx -t passes. The server starts, serves traffic, logs nothing unusual. And the thing you configured is quietly not happening. I maintain gixy-ng , a static analyzer for nginx configs. A growing share of its checks exist for exactly this category, because it turns out static analysis is the only practical way to catch a failure that produces no signal at runtime. Here are four worth knowing about. 1. OCSP stapling that staples nothing server { listen 443 ssl ; server_name example.com ; ssl_certificate /etc/ssl/example.com.pem ; ssl_certificate_key /etc/ssl/example.com.key ; ssl_stapling on ; ssl_stapling_verify on ; } Looks right. It does nothing. OCSP stapling means nginx fetches the certificate's revocation status from the CA itself and attaches it to the handshake, so the client does not have to. To do that, nginx has to make an outbound request to a hostname. nginx does not use the system resolver for runtime lookups. It has its own, and it only exists if you configure it. No resolver in scope means the hostname never resolves, the fetch never happens, and stapling is silently skipped. Your config test passes. Your clients go do their own OCSP lookups, which is the exact thing you turned stapling on to avoid. resolver 127.0 .0.1 valid=300s ipv6=off ; resolver_timeout 5s ; Use a local resolver or your cloud provider's internal DNS. Pointing this at 8.8.8.8 sends every internal lookup off your network in cleartext, which is its own problem. Check it with: echo | openssl s_client -connect example.com:443 \ -servername example.com -status 2>/dev/null \ | grep -A 17 'OCSP response' Working stapling prints OCSP Response Status: successful . Broken stapling prints no response sent . Run it twice, since the first handshake after a reload usually goes out unstapled while the f

This article is Part of a series on running vLLM on AKS and walks through creating an AKS cluster with a GPU node pool, deploying vLLM onto it, and wiring up Prometheus and Grafana for visibility. Companion pieces: Choosing the right GPU | Why your autoscaler flaps | Source Setup Summary Cloud: Azure GPU node: Standard_NV36ads_A10_v5 (1× A10, 24 GB) Image / model: vllm/vllm-openai:latest serving Qwen/Qwen2.5-7B-Instruct-AWQ Observability: kube-prometheus-stack (Prometheus + Grafana), KEDA, NVIDIA DCGM exporter All commands below are bash. The steps are ordered and each one depends on the previous. Dependency chain The build order follows one chain: model → VRAM requirement → GPU SKU → region availability → quota. Step 0 — Prerequisites (one-time, survives resource group deletion) GPU quota. Request through Portal → Quotas → Compute → This article: Requested Standard NVADSA10v5 Family vCPUs = 108 in westus (108 = 3 nodes × 36 vCPUs, matching the autoscaler's max-count 3 set in step 3). Quota is granted per-subscription and survives resource group deletion, so this step happens once, not on every rebuild. A quota is Azure's per-subscription limit on how much of a resource (here, GPU vCPUs in a specific VM family) you're allowed to provision at once. New subscriptions start at 0 for GPU families since it's expensive and can be abused. You need it because without an approval, az aks nodepool add for a GPU will fail outright. The request goes through manual Azure approval, so it has to happen before you plan to build. * Prerequisites * Existing Azure Subscription: Local tooling: Helm 3+ kubectl Bash Bash Variables to set for use through the setup RG = <resource-group-name> CLUSTER = <cluster-name> LOCATION = <preferred-location> Step 1 — Create Resource group az group create -n $RG -l $LOCATION Step 2 — Create AKS cluster, on a CPU system pool az aks create -g $RG -n $CLUSTER \ --node-count 1 --node-vm-size Standard_D2s_v5 \ --generate-ssh-keys The GPU does not go on thi

An AI agent telling you "done" is not evidence. When I started delegating work to Codex, I took those reports at face value — until I checked the code and found the change missing, the wrong file edited, or no commit at all. So I stopped trusting language and started making the shell write the facts to disk. Why this design works When you hand a task to Codex, it comes back with "Completed." At first that satisfied me. But when I actually checked the code, the critical change wasn't there, or a different file had been touched, or git commit had never run. The output "I did it" and the fact "it was actually done" are two different things. This is true of Claude Code too. Whether tool results were read correctly, whether errors were swallowed — even with code I wrote myself, running a self-audit right after declaring completion turns up something every single time. Delegating implementation to an AI amplifies that problem by one more notch. The fix is simple: make it write state to a file, not to language. Even if the AI says "completed," it isn't complete unless State: completed exists in the status file. If the handoff file doesn't contain the real output of git status --short , you don't know what changed. If the four sections you specified in the task file (Summary, Files Changed, Validation, Remaining Risks) aren't there, you can't verify it. Files don't lie. An AI under pressure will insist "I did it," but the output of cat status-file can't be forged. Pushing state management down into the filesystem is what makes it possible for a human to cross-check it in a shell . That's the essence of this design. The other important piece is separation of concerns . orchestrate-codex-worker.sh takes three arguments up front. bash scripts/orchestrate-codex-worker.sh <task-file> <handoff-file> <status-file> Each of these three files has a clear role. task-file : The work order for Codex. It contains only "what to do." handoff-file : The handoff note after Codex finishes. Wr

On 2026-08-25 at 21:27 EDT I pushed this to self-correcting-integration-maintainer: fix: repair...

If you have ever built a health check, you have probably written something close to this: const res = await fetch ( url , { method : ' GET ' , signal : AbortSignal . timeout ( 10000 ) }); const isUp = res . status === 200 ; I ran a version of that for a while. It is wrong in at least five ways, and every one of them bit me while building an outage tracker for Indian services. This is a write-up of what actually breaks, because most monitoring tutorials stop at the snippet above. 1. The server answers, the service is dead The single biggest gap. 200 OK tells you a server returned a response. It tells you nothing about whether the thing a user came to do still works. A bank homepage can render in 400ms while UPI payments from that same bank are failing at the switch. Different systems, different teams, different failure modes. Your check is green and the feature is on fire. You cannot fully solve this from outside. What you can do is stop treating a 200 as proof of health, and stop displaying it as one. 2. 403 is not down Plenty of sites block automated requests deliberately. Bot protection, WAF rules, rate limits, geo rules. In India this is common on high-value government and travel portals. IRCTC is the obvious example. A naive checker marks these down permanently. Users learn to ignore your tool inside a week. 403 means the server is alive and refusing your specific request. That is different information from 500 , and treating them the same throws away the distinction that matters most: Code Server state What it tells a user 200 Alive, responded Little. The feature may still be broken. 401 / 403 Alive, refusing this request Usually nothing about the outage. Often your check being blocked. 404 Alive The path is wrong, not the service 429 Alive, rate limiting you You are the problem, back off 500 / 502 / 503 Broken, overloaded, or in maintenance Genuine signal 504 Something upstream did not answer Genuine signal, usually a dependency Timeout / DNS failure Unknown A

Sometimes, a change that looks simple on the surface is not actually that simple. Imagine that you need to replace the source table feeding a refined or trusted table in a data pipeline. At first, it might look like a one-line change: update the table name, deploy the code, and move on. But in a real data platform, there is usually much more behind that change. There are dependencies, scheduling rules, upstream and downstream processes, resource consumption, concurrency, data lineage, and, sometimes, assumptions that were not immediately obvious when the pipeline was first created. I recently had to look into exactly this kind of situation in an Apache Airflow project, and one of the questions that came up was: Should this DAG be scheduled using a cron expression, or should it be triggered based on an Asset? The answer, as usual in software engineering, is: it depends. And understanding why it depends is much more important than simply knowing how to configure either option. Cron: the familiar way of scheduling a DAG Let's start with the simplest and most familiar option: a time-based schedule. With Airflow, we can define a DAG to run according to a cron expression: with DAG ( dag_id = " my_pipeline " , schedule = " 0 13 * * 0 " , catchup = False , ): ... In this example, the DAG is scheduled to run every Sunday at 1 PM. In a real environment, we might have different schedules for different environments. For example: Environment Schedule Development Saturday at 1 PM Homologation Sunday at 1 PM Production Monday–Friday at 1 PM The important characteristic here is that the schedule is based on time . If the DAG is configured to run at 1 PM every Sunday, Airflow will try to run it at that time, regardless of whether the data it depends on has actually changed. This is not necessarily a bad thing. In fact, sometimes this is exactly what we want. But there is another approach. When data becomes part of the schedule Modern data pipelines often have dependencies that are b

A little over two months ago, I registered a new domain for personal use. The idea was simple. I wanted a permanent, professional email address based on my last name, something like first@lastname.me . I registered the domain for ten years because I wasn’t building a disposable project, launching a marketing funnel, or testing some short-lived startup idea. I wanted an email identity I could keep for the long haul. I configured the domain properly. It has valid DNS. SPF is enabled. DMARC is enabled. It isn’t parked for sale. It isn’t sending spam. It isn’t distributing malware. It isn’t impersonating a bank, crypto exchange, social network, government agency, or anyone else. Then I checked it with IPQualityScore, also known as IPQS. The result was absurd: Phishing: true Suspicious: true Risk score: 95 Spamming: false Malware: false SPF enabled: true DMARC enabled: true DNS valid: true Parked domain: false Hosted content: false Category: N/A Domain rank: 0 Risky TLD: true In other words, IPQS acknowledged that the domain had valid DNS and email authentication, found no spam, found no malware, found no hosted content, assigned it no content category, and still labeled it as phishing with a risk score of 95 out of 100. I submitted a correction request about a month ago. I received no explanation. No evidence. No request for verification. No ticket update. No human response. As of August 29, 2026, the status is still unchanged. That isn’t a harmless technical oddity. IPQualityScore sells reputation and fraud-risk data that businesses can use to block users, reject signups, review transactions, investigate security alerts, and decide whether a domain, email address, IP address, phone number, or device should be trusted. If you’re going to sell suspicion as a service, you need to be accountable when your suspicion is wrong. IPQS, in my case, has been neither accurate nor accountable. A score of 95 is not a gentle warning IPQualityScore’s documentation describes its URL ri

I keep finding git behaviours the same way: set up the case, run the command, then check the state I...

Line 267 of a 427-line Terraform plan: # aws_rds_cluster.reporting must be replaced - /+ resource "aws_rds_cluster" "reporting" { ~ arn = "arn:aws:rds:us-east-1:842910557412:cluster:reporting" - > ( known after apply ) ~ cluster_resource_id = "cluster-D85642F9611A" - > ( known after apply ) ~ engine_version = "14.9" - > "15.4" ~ id = "reporting" - > ( known after apply ) ~ storage_encrypted = false - > true # forces replacement # (29 unchanged attributes hidden) } The merge request says "bump reporting Postgres to 15.4." The plan does exactly that. It also destroys the reporting database and creates an empty one in its place. Underneath the known-after-apply churn, two attributes are changing. One is the version bump, the thing your MR is about. The other is storage_encrypted flipping from false to true , and it isn't yours. Someone on another team that shares this repo merged it earlier in the week. You're just the one deploying. You review other people's Terraform MRs and have a feel for what each stack normally does; most weeks someone else shepherds the deploy. Today it's you. Your change goes out next, so you're carrying everything merged since the last deploy, including work you never reviewed and had no reason to know about. Nobody was negligent. The queue simply had someone else's change in it. It's a good change, by the way. You want encrypted storage. But there's no in-place path from unencrypted to encrypted on an RDS cluster. Terraform's only move is destroy and create. That's what -/+ means, and the comment at the end of the line says it in plain English: forces replacement . And the version bump alone would have failed. Going from 14 to 15 is a major version upgrade, and Aurora refuses those unless the config sets allow_major_version_upgrade = true . This one doesn't. That MR by itself would have died at apply, loudly, with an error naming the exact problem. A replacement doesn't upgrade anything. It creates a new cluster at 15.4 from scratch, so the f

The problem I run Hermes, an open-source agent with tools, memory, and cron built in. Before running my own managed service SaaS, I used various competitors to deploy on VPS. This method has a lot of downsides because you are often SSH'ing in and managing secrets directly in a .env file, which can leave you exposed if your box is compromised. It is also very cumbersome, especially for agencies to manage these "alway-on agents" for clients on VPS. Luckily, these are just hosting problems, so I built SEAOTTER to fix it for myself, and then realized other people probably have the same problem. * What it does * SEAOTTER is a managed control plane for Hermes Agent: Per-agent isolation - each agent runs in its own namespace with a gVisor sandbox, so one client's agent can't see or touch another's. Operate without SSH — pause, restart, restore, and read logs through an API instead of a terminal. MCP-native — talk to a hosted agent from Claude, Cursor, or Codex. Secrets handled for you — backed by Google Secret Manager instead of a .env file you have to remember exists. The rough idea POST /api/v1/agents or on "Create Agent", and it provisions a namespace, installs Hermes via Helm, brings up the sandbox, wires DNS/TLS, and gives you a reachable dashboard, typically in under five minutes. Who it's actually for Agencies running one isolated agent per client without spinning up a VPS per client Hermes power users who want lifecycle control (pause/restart/restore) without maintaining SSH access Hobbyists who want a standing assistant without becoming an ops person Try it There's a 14-day free trial on the Hobby plan. Worth being upfront: it currently asks for a card at checkout, which I know is friction — I'm working on a no-card way to try it. In the meantime, the docs walk through the API and dashboard in detail if you want to look before you sign up. What I'd love feedback on If you're currently self-hosting Hermes on a VPS: what would actually get you to switch, or keep you