标签：#devops

Disclosure: the numbers below are from Tessera, which I work on. The reasoning applies to any proxy that sits in a session path. Every vendor page in this category says something like "scales to thousands of users". It is a useless number, because a user who is not connected costs nothing. What costs something is a session that is open right now. So here is the arithmetic instead, with the method, so you can check it against whatever you are evaluating. The unit The controller does not know how many engineers you employ and does not care how many targets are registered. It knows how many sessions are open. The planning rule that has held up for us: on a normal working day, 10–20% of a team is connected at once. A 200-person engineering organisation is 20–40 concurrent sessions, not Size for your own observed peak, but if you are estimating from scratch, start there. This matters because the difference between the two numbers is the difference between a 512 MB VM and an argument about whether you need a cluster. Memory A proxied session is mostly buffers. In our case: about 256 KB of copy buffers, plus 6 to 10 goroutines at roughly 8 KB of stack each. Call it 320 KB per session. The base Go process is about 30 MB. So 200 concurrent sessions is 200 × 320 KB ≈ 64 MB of live data, plus 30 MB base, ≈ 94 MB. Except that is not what RSS will show you, and this is the part people get wrong when they size Go services. Go does not hand memory back to the operating system promptly, and at the default GOGC=100 the collector lets the heap grow to roughly twice the live set before collecting. So resident memory settles at about double the arithmetic. Concurrent sessions vCPU Expected resident Provision up to 50 1 ~90 MB 512 MB 50–200 2 ~190 MB 1 GB 200+ 4 ~380 MB 2 GB The gap between the last two columns is headroom for spikes, not a hidden cost. A controller serving 200 sessions really does use a couple of hundred megabytes. Our Helm chart ships requests: 256Mi and limits: 1Gi ,

Disclosure: I work on Tessera, which is one of the proxy-shaped tools. Both shapes are legitimate and I try to be fair to the other one below. Most comparisons of access-control tools start with feature tables. That is the wrong end. The decision that actually determines whether a rollout finishes is the deployment shape, and there are only two. Shape one: agents and certificates You run an internal certificate authority. Hosts are configured to trust it. Users get certificates that expire in a few hours. For Kubernetes, an agent runs inside the cluster and brokers access from there. What this buys you is genuinely good. Expiry does revocation automatically, which removes the human step that fails. The credential on the user's laptop is worthless tomorrow. The model scales well because the CA does not sit in the data path — once the certificate is issued, the user talks to the target directly, so there is no proxy to size and no bandwidth to plan. What it costs is that you have to change production before you get anything. sshd_config gets rewritten across the estate to add TrustedUserCAKeys . An agent gets deployed into every cluster. In some setups the tool's binary is copied onto hosts. None of that is technically hard. It is organisationally hard. You need a change window, sign-off from whoever owns those hosts, and a rollback plan — for a project whose entire benefit is "nothing bad will happen later". That conversation is where access-control rollouts stall, and it stalls most reliably in exactly the organisations that need the tool most: the ones where nobody is quite sure who owns which box. The other cost is that the CA private key becomes the most sensitive object your company owns, and now you operate a CA. Shape two: a proxy The credential stays on a controller. The user authenticates to the controller. The controller opens its own connection to the target, authenticates with the real credential, and relays. The target sees a normal connection from a nor

Every infrastructure post-mortem contains the same paragraph, and it is never the one anyone expected to write. The initial access was not sophisticated. It was a credential that existed, that worked, and that nobody had a reason to look at — because it had been legitimately issued months earlier, for a reason that had since ended. That is standing access. It is not a vulnerability, so no scan finds it. It is not a misconfiguration, so no posture report flags it. It is the residue of a hundred reasonable decisions: a key added for a migration, a database password shared during an outage, a kubeconfig sent to a contractor who did good work and left on good terms. It stays invisible to the risk register because a risk register asks what could go wrong, and standing access is the record of things that already went right. The distribution problem The mechanism is worth being precise about, because it explains why the usual fixes only partly work. Infrastructure access is almost always handed out rather than granted . A key is copied to a host. A kubeconfig is copied to a laptop. A password is copied into a password manager and then, at two in the morning, into a chat window. Once a credential has been copied, the organisation has permanently lost the ability to list its copies. There is no query that returns the answer. Revocation stops being an operation and becomes an investigation — carried out by people, at the exact moment the person who knew where everything was has left. This is why the honest test of an offboarding process is not "did we remove their access". It is: can we show a third party, at any point in the future, that access ended when we say it ended? Most organisations that pass the first test fail the second, and usually find out during an audit or a due-diligence review, which are the two worst moments to find out. Why the obvious fixes fall short Configuration management as the source of truth is a real improvement. It makes access declarative and pu

To add the AWS AppConfig Agent Lambda extension to an AWS Lambda function, you can open the documentation, scroll through a table of ARNs, find the one that matches your AWS Region and architecture, copy it, and paste it into your template. However, a few months later, AWS publishes a new version and now your deployment is silently using an older one. There’s a better approach that uses public parameters in AWS Systems Manager Parameter Store (Parameter Store). What are public parameters in Parameter Store? Many AWS services use Parameter Store to publish read-only public parameters with names that start with aws/service/{service-name} . These public parameters contain up-to-date metadata about AWS services. You've probably seen them used for AMI lookups for fetching the latest Amazon Linux AMI ID without hardcoding it. The same mechanism is available for Lambda layer ARNs, ECS-optimized AMIs, and other resources that AWS updates regularly. The key idea is instead of looking up a value in documentation and pasting it into your code, you query Parameter Store at deploy time and get the current value. The only IAM permission that's required is ssm:GetParameter . The parameters are public and readable from any AWS account. The problem with hardcoded layer ARNs The AWS AppConfig Agent Lambda extension is distributed as a Lambda layer. To attach it, you need the layer's ARN, which includes a version number at the end: arn:aws:lambda:us-east-1:027255383542:layer:AWS-AppConfig-Extension:128 That version number changes every time AWS releases an update. If you hardcode it, you get a working deployment, but you also get silent drift. A few months from now, you'll be running an older version without realizing it. Imagine a team that's managing dozens of functions in multiple AWS Regions, and you can see how this can become a maintenance problem. Someone has to regularly check the documentation, update the ARN, and redeploy. It's not difficult work, but it's the kind of thing

Originally published on Medium It's 2:51am. The incident is resolved. Error rate is back to zero, the rollback worked, and your on-call pager has finally gone quiet. Now you have to write the postmortem. If you've been in SRE or DevOps for any length of time, you know this feeling. You're exhausted, your brain is running on adrenaline fumes, and somewhere in the back of your mind you know that what you write in the next hour is going to be read by engineers, product managers, and probably a VP or two. It needs to be clear, blameless, specific, and actionable. Most of us write it badly. Not because we're bad at our jobs — because we're human beings who just spent two hours firefighting and now we're staring at a blank document at 3am trying to remember the exact sequence of events. There's a better way. The Problem With How We Write Postmortems The standard postmortem template is a solved problem. Every company has one. Timeline, root cause, contributing factors, action items — we all know the structure. The hard part isn't the structure. It's the writing. Specifically: Reconstructing the timeline from a chaotic Slack thread where half the messages are noise Writing the root cause narrative in plain language when your brain is still in technical mode Generating action items that are actually specific and assignable instead of vague gestures toward improvement Translating all of it into an executive summary that a non-technical VP can understand without losing the technical accuracy Each of these is a hard writing task under normal circumstances. At 2am after an incident they're brutal. What Changed for Me I started treating postmortem writing like any other repetitive engineering task: I built a system for it. Specifically, I built a set of AI prompts designed for the exact scenarios SREs face. Not generic "write me a postmortem" prompts — structured prompts that work with the raw material you actually have in front of you at the end of an incident. The key insight w

Most teams don't notice their CI/CD pipeline is broken — they just notice that deploys "feel slow" and shrug it off as normal. It isn't. A pipeline that takes 25 minutes to ship a one-line copy change isn't a fact of life, it's a symptom. Here are the mistakes we see most often when reviewing pipelines — roughly in order of how much time they silently burn. 1. Running the full test suite on every single change If a developer fixes a typo in a README and the pipeline still runs the entire integration suite, database migrations, and end-to-end tests, you're paying full price for a change that touched nothing critical. Fix: split your pipeline into stages based on what actually changed. Path-based triggers (only run frontend tests if frontend files changed) and a fast "smoke test" tier before the full suite can cut average pipeline time dramatically without sacrificing safety. 2. No caching between builds Reinstalling every dependency from scratch on every run is one of the most common — and most fixable — sources of wasted time. Package managers, build artifacts, and Docker layers are all cacheable, and most CI platforms support this natively. Fix: cache dependency directories keyed by lockfile hash, and structure Dockerfiles so rarely-changing layers (base image, dependencies) come before frequently-changing ones (application code). 3. Sequential steps that don't need to be sequential Linting, unit tests, and security scans are often run one after another when they have no dependency on each other. That's pure wasted wall-clock time. Fix: parallelize independent jobs. Most CI systems support fan-out/fan-in patterns — run lint, test, and scan simultaneously, then gate the deploy on all three passing. 4. Environments that drift from production A pipeline that passes in staging and fails in production usually means the environments aren't actually equivalent — different env vars, different resource limits, different service versions. Teams respond by adding more manual

In mission-critical infrastructure, latency isn't just a metric—it's the difference between a resolved incident and a catastrophic outage. Whether you are managing an SRE team handling cluster failures or a teleassistance platform routing domestic SOS alerts, the core engineering challenge remains identical: getting a human's attention in milliseconds without administrative friction. This technical breakdown explores how we architected a high-availability voice routing engine using Cloudflare Workers and Twilio, bridging the gap between hardware teleassistance and DevOps incident workflows. The Dual-Use Architecture: From Teleassistance to SRE Paging Our platform core serves two distinct but structurally identical needs: Senior Safe: A Chilean domestic teleassistance product where an SOS trigger must reach a family guardian instantly. DevOps On-Call: An infrastructure alert triggered via Grafana or UptimeRobot webhooks that must wake up an engineer at 3 a.m. The blast radius differs (a household vs. a production database), but the technical path is identical. To solve this at scale without charging steep "per-seat" licensing models that penalize growing squads, we built the entire pipeline on serverless isolates. Bypassing Cold Starts with Edge Ingest When an emergency happens, you cannot afford to wait for a virtual machine or container to boot. The public ingest pipeline lives directly on Cloudflare Workers ( api.wakeupdev.com ). Because V8 isolates are kept warm globally across the edge network, there is zero Lambda-style cold start penalty on the first page. The ingest contract is minimal: Authentication: Handled via an x-api-key header. Payload: Raw text or JSON (capped at 4,000 characters). Execution: Credits are consumed atomically in a global Postgres layer before the voice cascade is scheduled. An HTTP 202 Accepted status code guarantees that the credit is validated and the call flow is in flight. Solving the Voicemail Problem: True Human Acknowledgement A

In eleven days, on 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying to anyone who puts a product with digital elements on the European market. Not the full regulation. Just the part where, if you find out an actively exploited vulnerability is in your product, you have 24 hours to tell ENISA about it. I have watched a lot of engineering teams meet this class of deadline for the first time. It usually goes the same way. Somebody in sales gets a security questionnaire. Somebody in engineering gets forwarded the questionnaire. Three weeks later there is a shared folder called evidence-final-v3 with 200 screenshots in it, and nobody can tell you which screenshot answers which question. I have spent the last several months building a tool whose entire job is that folder, so I read the instruments properly. This is what I found out. It is written for engineers, not for a compliance team, and I try to be specific about what the text says rather than what a vendor blog says it says. Where SOC 2 came from, and why that still shapes it SOC 2 exists because of a misuse. In 1992 the AICPA published SAS 70, an auditing standard for service organisations. Its purpose was narrow: if you outsourced your payroll, your auditor needed some assurance that your payroll provider's internal controls did not corrupt your financial statements. It was an accounting instrument, for accountants, about financial reporting. Then the industry outsourced everything else. By the mid-2000s companies were sending their customer data to service providers, and they wanted assurance about that , not about financial reporting. There was nothing designed for it, so they asked for the thing that existed. Vendors started waving SAS 70 reports around as proof they were secure. They were not proof of that. SAS 70 had no defined control set at all: the service organisation wrote its own control objectives, and the auditor tested against whatever had been written. Two S

Retour d’experience sur l’automatisation de déploiements avec un agent LLM et sur les gardes-fous qu’il a fallu inventer en cours de route L’idée est venue d’un frustration banale. Sur mon projet terraform , je passais beaucoup de temps à refaire la même chose : lire un plan qui échoue , comprendre pourquoi , corriger des lignes de configurations , toujours trop long. Un agent LLM sait faire ca , mais la question était se savoir s’il pouvait le faire sans supervision , dans un pipeline , sur une infrastructure qui coûte de l’argent réel. Trois mois plus tard , la réponse est oui , mais pas du tout dans le périmètre que j’imaginais au départ. Le Montage: Rien de complexe, un VPS à 12 euro par mois , la CLI de l’agent installée dessus , et un runner Gitlab qui l’invoque sur un déclencheur précis: quand un terraform plan échoue sur une MR. l’agent recoit trois choises: la sortie d’erreur , le diff de la MR, et un accès en lecture du dépôt.Il produit une proposition de correctif sous forme de patch, qu’il pousse sur une branche dédiée. Ce qui a bien marché: les erreurs de typage et de reference. Un var.instance_type mal orthographié, un output référencé qui n'existe plus après un refactor, un module dont la signature a changé. L'agent corrige ça avec un taux de réussite que j'estime autour de 85 %. Ce sont des erreurs mécaniques, à contexte local, exactement ce qu'un LLM traite bien. Les messages d’erreur opaques. C'est le gain que je n'avais pas anticipé. Certaines erreurs de provider AWS sont d'une inutilité remarquable , un InvalidRequestException sans description, par exemple. L'agent, lui, va lire le corps de la requête dans les logs de debug et repérer le paramètre malformé. Il ne « comprend » pas mieux que moi, mais il lit trois cents lignes de log en deux secondes sans se lasser. À 19h un vendredi , ma qualité de diagnostic s’effondre. Celle de l’agent, non. Ce qui a cassé Il a proposé de détruire une base de données. C'est l'incident qui a tout recadré. Un clus

Every self-hosted project I run starts the same way: a brand new VPS and about twenty minutes of setup before I install a single application. That twenty minutes is what separates "my server" from "someone else's crypto miner." A fresh box with a public IP starts getting probed within minutes, and the default configuration on most images is built for convenience, not safety. This is the secure baseline I set up on every new server, before Docker, before n8n, before anything else. It is also the starting point our production n8n guide assumes you already have. Every command below was checked against current Ubuntu LTS documentation, and I flag the parts that genuinely need a real server to verify. Key takeaways Never do daily work as root. Create a sudo user and log in as that instead. Use an SSH key and turn password login off, but only after you confirm the key works. Deny everything at the firewall by default, then open only the ports you actually use. Turn on automatic security updates so patches land while you sleep. If you plan to run Docker, remember that published ports skip UFW. Bind them to 127.0.0.1 . Prerequisites A VPS running a current Ubuntu LTS. Both 24.04 "Noble Numbat" and 26.04 "Resolute Raccoon" work well. I run long-lived boxes on Hostinger VPS hosting , which is also what powers the n8n guide. An SSH key pair on your own machine. If you do not have one yet, Step 3 creates it. A terminal, and a note of your provider's recovery console. Most hosts, Hostinger included, give you a browser based console in their control panel. That is your way back in if you ever lock yourself out, so find it before you start. Disclosure: some links in this guide, including the Hostinger link above, are referral or affiliate links. If you sign up through them we may earn account credit or a commission, at no extra cost to you. We only point at tools we actually run. Step 1: Log in and update the system Right after the server boots, log in with the credentials your pr

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