标签：#DevOps

The AWS API has become infrastructure's common language, and a whole ecosystem has grown up around running it somewhere other than AWS. Some tools mock it for testing. Others implement it for real. Knowing which is which saves you from deploying a dev tool to production or wiring a production platform into your CI pipeline. Two categories The tools split into emulators and real cloud platforms. Emulators intercept AWS API calls and return plausible responses without provisioning real infrastructure, where state is usually ephemeral, VMs never boot, and the goal is behavioural approximation fast enough for a developer's inner loop. Real cloud platforms provision actual infrastructure where EC2 calls boot real virtual machines and block storage carries real persistence guarantees. Emulators Moto Moto ( github.com/getmoto/moto , Apache 2.0, 8,400+ stars) has been around since 2013, making it the oldest option here. It works differently from the rest because rather than running a local server, it patches boto3 calls in-process through a test decorator. A function wrapped in @mock_aws intercepts all AWS SDK calls and returns mock responses without any network traffic. This makes it fast and easy to drop into Python test suites, but it only works for Python. Teams using the AWS CLI, Terraform, or Go SDKs need a server-based option. LocalStack LocalStack ( github.com/localstack/localstack , 64,000+ stars) is the dominant name in local AWS development. It runs as a Docker container exposing the AWS API on localhost:4566 and covers over 120 services. In March 2026, LocalStack archived its Community Edition repository and moved core services behind a paid plan. A free tier remains for non-commercial use and open source projects, but the Base plan covering Cloud Pods persistent state costs $39 per month and the Ultimate plan runs $89 per month. Teams that depended on CE for commercial CI pipelines are now evaluating alternatives. Floci Floci ( floci.dev , github.com/floci-io/f

We’re a small team building Sealshot, a free and open-source screenshot app for macOS. We started working on it because screenshots often become disposable files. We use them for bug reports, QA, documentation, support, and security work, but later they can be hard to find or reuse. They can also accidentally contain sensitive information such as emails, API keys, tokens, internal URLs, or customer data. Sealshot is built around a simple idea: Treat screenshots more like documents than temporary images. It supports: region, window, and scrolling capture screen recording editable annotations OCR and searchable screenshot archives sensitive information detection before sharing encrypted local storage local metadata generation Everything is processed locally on the Mac. It’s open source and free, and we’re still actively improving it. We’d really appreciate feedback, especially from developers, QA engineers, support teams, and people working in security. Website: https://seal-shot.com/ GitHub: https://github.com/ldeng83/Sealshot

Last Tuesday, my free endpoint returned a valid JSON contract. The next call returned a summary. Same prompt. Same model label. No version bump. I almost merged code that expected a schema and instead got a paragraph. Free tiers are not the enemy. Silent drift is. When you wire a free AI server into your PR pipeline, you accept three facts: shared compute, changing model configs, and zero guarantee. So you need gates that fail closed. This is the checklist I now run before any AI-generated suggestion touches a merge branch. I built these gates against an open-source gateway called MonkeyCode. Why? It gives solo devs free model access and a free server for trial workloads. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Convenient, yes. Safe by default? No. So I test every claim. Gate 1: Pin the response contract Your prompt must define an exact shape. For a bug triage task, I require a JSON object with severity , summary , and file fields. If the response is not parseable JSON, the gate fails immediately. { "severity" : "high" , "summary" : "Null pointer on empty input" , "file" : "src/parse.ts" } No fallback. No partial acceptance. Gate 2: Snapshot a baseline Run the same prompt ten times. Record output length, hashes, and tokens per call. Store those as baseline.json . Later, compare every new response against that range. for i in $( seq 1 10 ) ; do curl -s your-monkeycode-endpoint -d '{"prompt":"triage this bug"}' \ | jq -r '.output' | sha256sum done If the hash variance crosses an evidence threshold, the gate flags it. Gate 3: Time-box and cost-cap Free servers queue. You need a timeout and a token budget. I use 8 seconds and a hard cap of 600 tokens. The gate reads usage metadata from the response and rejects when either limit is hit. if response . elapsed > 8 or response . usage . total_tokens > 600 : reject ( " over budget " ) Track this weekly. Drift often starts as a slow climb. Gate 4: Apply semantic checks Gates are not jus

HashiCorp is positioning HCP Terraform as the governance and control plane for a new generation of AI-driven infrastructure, arguing that the rapid adoption of coding agents is shifting the biggest infrastructure challenge from writing configuration to verifying and safely executing it. By Craig Risi

A syndication job noticed before I did A scheduled task publishes one blog post a day to a developer community. It fetches the article from my own site, converts it, and posts it. At 10:00 it failed four times with this: Server error '521 <none>' for url 'https://neuragrowth.co/blog/schema-grammar-ceiling/' 521 is Cloudflare saying the origin server did not answer. So the interesting failure was not in the syndication job at all. My whole site was down, and had been for over three hours by then. The server itself was fine: four days of uptime, load under 0.2, disk at eight percent. But systemctl is-active nginx said failed , and nothing was listening on 80 or 443. nginx resolves your upstreams before it starts The journal had the whole thing in three lines: 06:49:54 systemd[1]: Stopping nginx.service... 06:49:54 nginx[36027]: [emerg] host not found in upstream "example-backend.tld" in /etc/nginx/sites-enabled/site:104 06:49:54 nginx[36027]: nginx: configuration file test failed Line 104 was a small proxy I had added months earlier so the public site could forward one form endpoint to a backend on a different host without revealing its name: location = /api/lead-capture { proxy_pass https://example-backend.tld/api/lead-capture ; proxy_ssl_server_name on ; proxy_set_header Host example-backend.tld ; } When proxy_pass contains a literal hostname, nginx resolves it while parsing the configuration , and treats failure as a fatal config error. That resolution happens inside ExecStartPre=/usr/sbin/nginx -t , so a name it cannot look up means the unit never starts. The config was not wrong. It was valid before the restart and valid after, and nginx -t passed by hand seven hours later. It was invalid for about one second. Why DNS was gone for exactly that instant Ten seconds of journal, reconstructed: 06:49:44 apt-daily-upgrade.service starts 06:49:53 "Reexecution requested ... (unit apt-daily-upgrade.service)" 06:49:53 systemd reexecuting (it had just upgraded itself) 06:49

Disclosure: I work on Tessera, which is one of the tools in the gap I am describing. Ask a fifty-person engineering organisation how they control production access and you will hear the same answer with small variations: a bastion host, SSH keys distributed by configuration management, a shared kubeconfig somewhere, and a spreadsheet or a Notion page that is out of date. Nobody chose that. It is what remains after the alternatives were priced. How the category got shaped Privileged access management grew up serving banks, telcos and governments in the 2000s. Those buyers had specific characteristics: thousands of administrators, regulators with written opinions, dedicated security teams, and procurement processes measured in quarters. Products shaped themselves accordingly. Six-figure entry prices. Deployments measured in months with professional services attached. Feature sets covering every mainframe and network appliance in a bank's estate. Sales motions that start with a discovery call and a mutual NDA. That was a reasonable fit for those buyers. It is a terrible fit for a company with sixty engineers, no dedicated security team, one person who is security-adjacent, and a procurement process that consists of a founder approving a card payment. So the mid-market did what people do when a category prices them out: they built the minimum themselves. A bastion is a bastion because it was free and it was Tuesday. The problem this leaves The bastion answer works, up to a point, and it is worth being specific about where the point is. A bastion controls the door. It does not control the room. Once someone is through, there is no per-command record, no way to reduce their privileges while they are working, and no session replay. And keys still have to be distributed and revoked behind it, which means the original problem is intact — it just has a nicer front entrance. Three things then converge, usually in the same year: The first enterprise customer. Their security que

Disclosure: I work on an access tool (Tessera), mentioned once at the end. Everything before that is about evidence, and applies whatever you use. The most common surprise in a first SOC 2 or ISO 27001 audit is not that a control is missing. It is that a control exists, works, and cannot be evidenced — so it counts as absent. The distinction is worth stating precisely, because it is not obvious until it has cost you something. A control is a thing that is true about your system. Only authorised engineers can reach production. Evidence is an artefact, produced by a system rather than by a person, that demonstrates the control was operating throughout the audit period — not on the day someone checked. Most organisations have decent controls. Most cannot produce evidence, because their controls live in places that do not emit artefacts: a bastion's authorized_keys file, a spreadsheet, a Slack thread where someone approved something, and the collective memory of three engineers. What gets asked for Reconstructed from what people have told me, this is the shape of the questions: "Show me everyone who could access production on 14 March." Not today. A specific date in the past, usually chosen by the auditor. This is the one that catches people, because most systems can tell you the current state and cannot tell you a historical one. authorized_keys has no history. A spreadsheet has whatever history git gives it, if it is in git, which it usually is not. "Show me that this person's access ended when their employment ended." Both timestamps, from two systems, matched. HR has the first. The second is the problem. "Show me the approval for this elevated access." Not that a policy requires approval — the specific approval, for this specific grant, with who approved it and when. "Show me what was done in this session." Increasingly common where production access to customer data is involved. Not "we log commands", but the actual record for a named session. "Show me that these c

Disclosure: I work on Tessera, which is self-hosted. That is the position I am arguing from, and the costs of that position are in the last section. Security questionnaires ask where customer data is processed. Access-control tools tend to get a shallow answer to that question, because people think of them as gatekeepers rather than as data processors. They are both. Here is what a hosted access broker necessarily knows about you. Your infrastructure inventory. Every registered target: hostnames, addresses, cluster endpoints, database names, environment labels. That is a map of your estate, and it is the document an attacker would most like to read before deciding where to spend effort. Your organisational structure. Who has access to what, which teams exist, who approves for whom, who was granted production access at 2am during an incident. Org charts are inferable from access graphs with unpleasant accuracy. Your session content, if recording is on. Every command, every query, every screen of output. That includes whatever your engineers pasted into a terminal, which — be honest about your own estate here — includes secrets sometimes. Timing. When your incidents happen, how long they last, who gets pulled in. That is commercially sensitive on its own. None of that requires the vendor to hold your credentials. It is the metadata, and the metadata is the part that survives every architectural mitigation. Where this shows up GDPR and processor chains. Session recordings contain personal data — identified individuals performing identified actions at identified times. A hosted vendor is a processor, which means a DPA, transfer mechanisms if data leaves the EEA, and a sub-processor list you have to monitor. It also means their sub-processors become your problem, which is a chain you do not control and cannot easily audit. Sector rules. Financial services, healthcare and public sector procurement in most European jurisdictions have specific requirements about where data

Disclosure: I work on Tessera, which is on the buy side of this. I have tried to cost the build side properly, because a comparison where the build option looks stupid is a comparison nobody believes. Every engineering team that has this problem considers building it. That instinct is correct. SSH certificates are a well-understood, well-documented mechanism, everything you need ships with OpenSSH, and the first working version takes a competent engineer about a week. The week is not the cost. Here is what is. The build, honestly The CA itself. You generate a key pair, configure targets with TrustedUserCAKeys , and sign user keys with a short validity. This part genuinely is a week, and it works. Protecting the CA key. This is where the estimate starts moving. The CA private key can now grant access to every host in the fleet. On a laptop it is an incident waiting to happen. So you want it in an HSM or a KMS, which means an integration, which means the signing operation now has an availability dependency, which means a runbook for what happens when that dependency is down. Call it two to four weeks including the operational work. Issuance. Someone has to request a certificate and something has to decide whether to give them one. That means integrating with your identity provider, mapping groups to principals, building a request path, and building an approval path if you want anything time-boxed or justified. This is the real project, and it is measured in months rather than weeks, because it is where the requirements keep arriving. Rollout across the estate. Editing sshd_config on every production host. Technically trivial, organisationally not: change window, sign-off, rollback plan, and the discovery that four hosts are not in configuration management and one of them is important. Audit. Certificates tell you a session was authorised. They do not tell you what happened in it. If your requirement includes per-command history or session replay — and if you have audi

Disclosure: these are decisions from Tessera, which I work on. They are all small enough to copy into your own service, which is why they are worth writing up. Security feature lists are made of nouns: encryption, RBAC, SSO, audit. The things that actually decide whether a system holds up are smaller than that and never make the list. Here are four of ours, with the reasoning, including the case where we made the trade in the direction most people do not. 1. The login rate limit ignores X-Forwarded-For Rate limiting a login endpoint is table stakes. The question is what you count against. The natural implementation reads X-Forwarded-For , because your service is behind a load balancer and the real client address is in that header. Almost every tutorial does it this way. The problem: X-Forwarded-For is a request header. If your service trusts it, an attacker sets a different value on every request and each one gets its own bucket. You have not built a rate limit, you have built a counter that resets on demand, and the dashboards will look perfectly healthy while the endpoint is being brute-forced. We count against the real TCP connection address instead. That is the peer address of the socket, which an attacker cannot forge without actually controlling that address. The cost is real and worth naming. Behind a reverse proxy, every request arrives from the proxy's address, so the limit applies to the proxy as a whole rather than per client. That is a worse experience in some topologies, and people will file bugs about it. We took that trade because a rate limit that can be bypassed by setting a header is not a degraded rate limit, it is the absence of one — and the absence is worse than useless, because it looks like presence. If you do want per-client limits behind a proxy, the answer is an explicit allowlist of trusted proxy addresses whose forwarded headers you accept, not blanket trust of a header. 2. Target addresses are validated to prevent SSRF Our controller is

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