DEV Community: binadit

Staying on Microsoft 365 vs moving off it: the CLOUD Act law firms and accountants need to weigh

binadit — Wed, 11 Nov 2026 08:33:27 +0000

The CLOUD Act doesn't care which EU region you picked

Here's an uncomfortable fact for anyone running IT at a law firm or accountancy practice: choosing the EU data region in Microsoft 365 or Google Workspace does not change which country's courts can compel disclosure of your data. That's not a config setting you can fix. It's jurisdiction, and it follows the company, not the server rack.

If you're the person who gets asked "where does our data actually sit, and under which law" by a partner or a client's privacy officer, this one's for you.

The problem: location vs jurisdiction

Microsoft Corporation and Google LLC are US entities. Doesn't matter if the disk is in Dublin or Frankfurt. Under the CLOUD Act (enacted 23 March 2018), a provider under US jurisdiction must disclose data in its "possession, custody, or control" when served valid US legal process, a warrant, subpoena, or court order, "regardless of whether such communication, record, or other information is located within or outside of the United States" (18 U.S.C. 2713).

So the EU data region setting controls data residency. It does nothing for jurisdiction. Two separate axes, often confused as one.

This matters more for legal and accounting workloads than most SaaS use cases because the data is frequently privileged: case strategy, undisclosed tax structuring, pre-signing M&A terms. A disclosure request doesn't even need to target your firm; it can be about a client or counterparty whose documents you're merely holding.

The underlying legal basis is also shaky

Separate from the CLOUD Act, there's a GDPR transfer problem sitting underneath. Chapter V requires an adequacy decision or safeguards (like SCCs) for data leaving the EEA, and Article 48 explicitly states a foreign court order alone doesn't make a transfer lawful.

The current transfer mechanism, the EU-US Data Privacy Framework (adopted 10 July 2023), is the third attempt after two predecessors got struck down by the CJEU:

Safe Harbor, struck down 2015 (Schrems I)
Privacy Shield, struck down July 2020 (Schrems II), specifically because FISA Section 702 left EU citizens with no effective remedy

And the current framework is under challenge right now: dismissed by the EU General Court on 3 September 2025, appealed on 31 October 2025, pending before the CJEU as of writing.

None of this makes today's setup illegal. But the pattern (replace, strike down, replace, challenge) is worth engineering around, not reacting to after a court decision lands on your desk.

Option A: stay put

Valid choice for a lot of shops. Strengths:

Mature integrations with practice management, e-signature, billing tools
Staff already trained, zero ramp-up
EU data region + signed DPA available
Security engineering budget a smaller vendor can't match

Reasonable if your client files rarely touch US persons, US litigation, or cross-border tax structuring.

Option B: move to a provider outside US jurisdiction

If the provider has no American parent and runs its own EU infrastructure, there's no US entity for a court order to reach. The CLOUD Act has nothing to attach to. The GDPR Chapter V question disappears too, since there's no third-country transfer to evaluate in the first place.

Trade-offs to budget for:

Smaller product catalogue; check your add-in and integration dependencies before committing
Migration project: mailboxes, calendars, shared drives, permissions, all need to move without losing version history or breaking client-facing addresses
Fewer vendors in the market, so due diligence matters more. Get clear answers on who holds encryption keys and which law governs the provider, not marketing copy

Quick comparison

Factor                 | MS365/Workspace (EU region) | European provider
------------------------|------------------------------|--------------------
CLOUD Act reach         | Yes, provider itself          | No US entity in chain
GDPR transfer question  | Relies on DPF, under appeal    | No transfer to assess
Migration effort         | None                          | One-time project
Support model            | Ticket-based, tiered           | Direct contact

Decision framework

Run through this before your next partner meeting:

Low exposure: rarely handle US persons, US litigation, or cross-border tax work, and comfortable with DPF pending appeal? Staying put with EU region + DPA is defensible. Revisit when the CJEU rules.
High exposure: regularly hold privileged material for cross-border M&A, sanctions-adjacent sectors, HNWIs, or PEPs? The case for removing the jurisdiction question entirely gets stronger regardless of how the appeal goes.
Already asked: has a client, insurer, or regulator asked in writing where your data sits and under which law applies? That's your signal the question stopped being theoretical.

No universal right answer here. But "we picked the EU region" is not the same statement as "no foreign court can compel disclosure," and it's worth knowing which one you're actually telling your clients.

Full legal detail and the complete comparison table: original article

Originally published on binadit.com

How a SaaS platform cut infrastructure costs 46% by moving off Kubernetes

binadit — Fri, 06 Nov 2026 08:20:00 +0000

When Kubernetes becomes the problem it was supposed to solve

Here's a question worth asking before you adopt Kubernetes: do you actually have the problem it solves? A six-person SaaS team didn't, and it took them two years and EUR 14,200 a month to notice.

This is a breakdown of how we helped them move off Kubernetes entirely and cut their infrastructure bill by 46%, with faster deploys and better uptime as a side effect.

The setup

The product: a B2B analytics platform built on Laravel, Vue, PostgreSQL (primary plus one replica), Redis, and a few background workers handling webhooks and scheduled reports.

The infrastructure: three managed Kubernetes clusters (production, staging, and an "experiments" cluster nobody could justify), each with its own node pools, ingress controller, cert-manager instance, and full Prometheus/Grafana stack.

The team had adopted Kubernetes two years earlier on a contractor's recommendation, during a growth phase. The contractor was long gone. Nobody had revisited whether the setup still made sense.

Symptoms:

Deploys took 8-12 minutes and often failed at the Helm chart stage with vague errors.
Only 2 of 6 engineers could confidently debug the manifests under pressure.
Autoscaling never behaved as expected, so the team hardcoded static replica counts, which quietly defeated the purpose of having autoscaling at all.
Nobody knew the recovery plan if the Kubernetes control plane went down.

No outages yet, but the team was burning roughly 15 hours a week just keeping the clusters alive. That's a real cost, even if it never shows up on an invoice.

What the audit found

Two weeks of pure observation before touching anything: resource requests vs. actual usage, node utilization across a full business cycle, and a full pass through the cloud bill.

Average CPU utilization across production nodes: 11%
Average memory utilization: 23%
Peak traffic over 90 days never came close to what a single well-sized server could handle
42 pods running across three clusters for what mapped out to exactly 6 logical services
Node pools sized for an 8x traffic spike projected 18 months earlier that never materialized

Also found: three separate managed load balancers, a duplicated logging pipeline shipping the same data to two destinations (leftover from an incomplete migration), and a staging cluster running 24/7 at near-production size for about six hours of actual weekly use.

None of this was negligence. It's what happens when infrastructure gets provisioned for a future that doesn't arrive, and nobody goes back to check.

Why we moved off Kubernetes instead of fixing it

Kubernetes earns its complexity when you need multi-team deployment isolation, workloads that scale from zero to hundreds of pods, or shared infra across many independently-owned services. This team had six services, six engineers, and two deploys a week. None of that applied.

We proposed a simpler stack: a small fleet of dedicated servers behind a load balancer, running the app via Docker Compose and systemd, with PostgreSQL and Redis managed directly instead of as in-cluster StatefulSets.

The reasoning:

Operational match. A team of six with two Kubernetes-literate engineers was running infra built for a team of thirty. Simplifying meant everyone could debug production, not just two people.
Cost shape. Control planes, redundant node pools, and managed add-ons carry fixed overhead no matter the load. At 11% utilization, that overhead buys nothing.
Reasoning about failure. Every engineer already understood "systemd restarts a crashed process." Nobody wanted to debug a CrashLoopBackOff caused by a readiness probe fighting an HPA.

To be clear: this isn't a "Kubernetes bad" take. If this team ran 20+ independently deployed services or needed to scale a component to hundreds of replicas during traffic spikes, we'd have kept Kubernetes and just fixed the sizing. The decision follows the workload, not a philosophy.

The migration, phase by phase

Zero-downtime migration over six weeks, not a cutover weekend.

Phase 1: right-size based on observed peak, not theoretical peak

2x app servers (8 vCPU, 16 GB RAM) behind HAProxy, running Docker Compose
1x PostgreSQL primary (8 vCPU, 32 GB RAM) with a streaming replica
1x Redis instance with persistence enabled
2x worker nodes, scaled by systemd timers and a basic job-count check instead of an HPA

That's roughly a third of the node count the Kubernetes setup needed, because there's no pod scheduling overhead, no duplicated system pods per node, and no headroom reserved for a scaling event that never happened.

Phase 2: deployment pipeline

Replaced the Helm-based CI/CD with build-and-rsync:

deploy:
  stage: deploy
  script:
    - docker build -t app:$CI_COMMIT_SHA .
    - docker save app:$CI_COMMIT_SHA | gzip | ssh deploy@app-01 'docker load'
    - ssh deploy@app-01 'docker compose up -d --no-deps app'
    - ./scripts/healthcheck.sh app-01
    - docker save app:$CI_COMMIT_SHA | gzip | ssh deploy@app-02 'docker load'
    - ssh deploy@app-02 'docker compose up -d --no-deps app'

HAProxy pulls each node out of rotation during its deploy window, so the API stays up throughout:

backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app-01 10.0.1.10:8080 check inter 2s fall 2 rise 3
    server app-02 10.0.1.11:8080 check inter 2s fall 2 rise 3

Phase 3: database and cache

PostgreSQL moved to dedicated hardware with tuned parameters (shared_buffers at 25% of RAM) and proper connection pooling via PgBouncer, which had been missing entirely in the cluster setup. Redis moved to a standalone instance with AOF persistence; previously it ran as an ephemeral pod that lost all queue state on every restart. That data loss bug had been open for four months before the audit.

Phase 4: monitoring and runbooks

Consolidated three separate Prometheus/Grafana stacks into one, and wrote runbooks for the five most common failure scenarios: database failover, worker backlog, disk pressure, certificate renewal, and application rollback.

Results, six months later

Metric	Before (K8s)	After (dedicated servers)
Monthly infra cost	EUR 14,200	EUR 7,650
Deploy time	8-12 min	90 sec
p95 API response time	410ms	190ms
Engineers who can debug production	2 of 6	6 of 6
Weekly ops time (team-wide)	~15 hours	~4 hours
Uptime (trailing 6 months)	99.91%	99.97%

Takeaway

Kubernetes isn't the villain here. The villain is infrastructure decisions that outlive the assumptions that justified them. If your cluster utilization is sitting in the teens and only two people on the team can debug a failed deploy, it might be worth asking whether you're solving a problem you actually have.

Full writeup with more context: binadit.com

Originally published on binadit.com

How to debug memory leaks in production without a zero downtime migration going sideways

binadit — Wed, 04 Nov 2026 08:34:30 +0000

Your memory leak fix can cause the outage your leak never did

Here's a scenario that plays out more often than anyone likes to admit: a service that ran fine at 400MB for months starts getting OOM-killed every day and a half, nobody can point to the deploy that caused it, and the on-call engineer's first instinct is to just restart things and ship a patch fast. That instinct is exactly how a slow leak turns into a self-inflicted outage. This is a process for finding the leak, proving the fix, and rolling it out without dropping a single request.

Full reference: debugging memory leaks in production without breaking your zero downtime migration

What you need before starting

Shell access to the host or container, with permission to attach a profiler to a live process
A load balancer or reverse proxy in front of the service (Nginx, HAProxy, cloud LB); without this, zero downtime isn't really on the table
Memory, CPU, and latency metrics scraped at 30 second intervals or tighter. No metrics, no trend, no debugging. Set up node_exporter or equivalent first.
The ability to spin up a second instance for canary testing

Examples below use Node.js and systemd, but the process transfers directly to Ruby, Python, Java, or Go. Only the tooling changes.

Step 1: Make sure it's actually a leak

Caches warming up look like leaks for the first hour. A real leak climbs indefinitely and correlates with uptime, not traffic volume.

watch -n 5 'ps -o pid,rss,etime,cmd -p 1234'

If RSS climbs linearly regardless of traffic and only drops on restart, that's a leak. If it climbs with traffic and then flattens, that's cache sizing, a different problem entirely.

Step 2: Pull evidence before you touch the process

Restarting first is the number one mistake here. You lose the exact evidence you need to diagnose anything.

Node.js, heap snapshot without stopping the process:

kill -USR2 1234   # if a SIGUSR2 handler is wired up to write snapshots
# or with --inspect already running:
ssh -L 9229:127.0.0.1:9229 user@server

Java:

jmap -dump:live,format=b,file=heap.bin 1234

Python, no process interruption:

py-spy dump --pid 1234
py-spy record -o profile.svg --pid 1234 --duration 60

Take two snapshots, 30 to 60 minutes apart, under normal load. The diff is the actual signal. The absolute numbers aren't.

Step 3: Read the diff

Load both snapshots into Chrome DevTools (Memory tab > Load) and use comparison view. Check for object counts that keep growing without a matching drop. Usual suspects:

Event listeners added without a matching removeListener
Unbounded Maps or caches with no TTL, no max size, often keyed by user or request ID
Closures holding onto large objects past the life of the request that created them
Connection pools that grow without a ceiling under retry logic

For Java, run the dump through Eclipse MAT's Leak Suspects report. For Python:

import tracemalloc
tracemalloc.start()
# ... later ...
snapshot1 = tracemalloc.take_snapshot()
# ... wait ...
snapshot2 = tracemalloc.take_snapshot()
top_stats = snapshot2.compare_to(snapshot1, 'lineno')
for stat in top_stats[:10]:
    print(stat)

Step 4: Reproduce it locally, don't just guess

Load test it:

autocannon -c 50 -d 300 http://localhost:3000/your-endpoint
# in another terminal
while true; do ps -o rss= -p $(pgrep -f server.js); sleep 10; done

If local memory climbs the same way production did, you've confirmed it, and you've got a repeatable test to validate the fix.

Step 5: Patch it, then re-run the exact same test

Add the TTL, remove the listener, cap the pool, whatever the fix is. Memory should plateau within a few minutes of steady load, not keep trending up.

Working locally proves the code is right. It says nothing about whether the rollout is safe. Don't skip the next part.

Step 6: Ship it as a zero downtime migration, not a restart

The instinct after finding a leak is to restart everything right now. Resist that. Treat it like any other production change.

Behind a load balancer with multiple instances:

ansible-playbook -i inventory deploy.yml --limit app-node-1

curl -X POST http://localhost:8080/-/drain   # app-specific drain endpoint
# or for Nginx: mark backend down, reload, then stop the old process
nginx -s reload

Single instance behind systemd, use blue-green on the same box:

# Start the patched version on a new port
PORT=3001 systemctl start app-patched.service

# Health check before switching traffic
curl -f http://localhost:3001/health || echo "not ready"

# Flip the upstream
sed -i 's/3000/3001/' /etc/nginx/conf.d/upstream.conf
nginx -s reload

# Only now stop the old process
systemctl stop app.service

Order matters: start new, verify healthy, switch traffic, stop old. Do it out of order and your memory leak fix becomes the outage.

On Kubernetes, same principle via rolling update:

kubectl set image deployment/app app=registry/app:patched
kubectl rollout status deployment/app

Make sure the readiness probe actually checks application health, not just that the port is listening. A pod that accepts connections before it's actually warmed up will drop requests mid-rollout, which defeats the point of doing this carefully.

How to know it actually worked

Don't close the ticket right after deploy. Watch it for a full business cycle, ideally 24-48 hours.

RSS trend: should plateau over 48 hours, not just slow its climb
Restart/OOM count: journalctl -u app.service | grep -i "oom" or kubectl get events --field-selector reason=OOMKilling
5xx rate during rollout: should stay at baseline; a spike means your drain or readiness logic has a gap
GC pause times (for GC'd runtimes): a healthier heap usually means shorter, more predictable p95 GC pauses

A reasonable target: RSS variance over 48 hours should stay within 10-15% of its post-restart baseline.

Originally published on binadit.com

How to ask your cloud act email provider the right questions, in writing

binadit — Fri, 23 Oct 2026 07:29:40 +0000

Your M365 contract won't save you from the CLOUD Act, but a paper trail might

Here's an uncomfortable fact most engineering teams don't think about until a client or auditor forces the issue: your company's email, calendar, and files probably live under US jurisdiction regardless of which Azure or GCP region you picked in the admin console. Region settings control where bytes sit on disk. They don't control which country's courts can compel the provider to hand them over.

Most teams never actually test this. They assume it, worry about it in a Slack thread, then move on. The fix is simpler than people expect: write down the right questions, send them to your provider in writing, and keep the answers on file.

This isn't about catching Microsoft or Google in some conspiracy. Their engineering and security teams are solid. The real issue is jurisdiction, not product quality, and jurisdiction is a documentation problem you can actually solve.

Before you send anything

Three things to nail down first:

Find your actual contracting entity. If you bought M365 through a reseller or MSP, your questions route through them first, not directly to Microsoft. Figure this out before drafting anything.
Scope the data type precisely. Mailbox content, Teams transcripts, OneDrive files, and metadata (sender/recipient lists) can fall under different policies inside the same provider. Don't ask a vague question and expect a precise answer.
Expect legally careful answers, not evasive ones. A US provider's legal team will answer using their own policy language. That's normal. Compare it against the actual law, not against what you hoped to hear.

For background on why this matters legally, see the earlier piece on GDPR compliance for email providers. This post assumes you already know roughly what the CLOUD Act is.

The questions to send (as a template)

Send these as a numbered RFI to your account manager, with a request to forward to legal/compliance. Written answers only, no calls. A call gives you a vibe; an email gives you evidence.

Subject: Written RFI - Data jurisdiction and disclosure questions

1. Which legal entity is our data processor, and in which country is it incorporated?
2. Does storing our data in an EU region change which country's law enforcement can compel disclosure?
3. Have you ever received a request for our data from a US authority, and could you tell us if you had?
4. Can you guarantee our data will never be disclosed to the US government without our consent or our national authorities' consent?
5. What is the current legal basis for transferring our personal data to the United States?
6. Is that legal basis currently being challenged, and what's the contingency if it's struck down?
7. Can a US court order override our European data processing agreement?
8. Who, specifically, can access our mailbox/file content, and under what process?

Why these eight, specifically

Q1 is the whole ballgame. The CLOUD Act applies based on where the company is incorporated, not where servers sit. If the answer names Microsoft Corporation or Google LLC as the controlling entity, you already have your answer regardless of what follows.

Q2 kills a common misconception. "EU data boundary" and "data residency in Europe" are storage-location features, not sovereignty guarantees. Same company, same keys, same exposure to a US court order. Get this distinction confirmed in writing.

Q3 exposes the gag-order problem. Many government data requests come with a legal bar on notifying the customer. A provider that can't promise notification isn't stonewalling you, they're describing the law. Still worth having on paper.

Q4 has already been answered publicly, which makes it a useful litmus test. On 10 June 2025, Microsoft France's director of public and legal affairs, Anton Carniaux, testified before a French Senate inquiry. Asked if he could guarantee UGAP-hosted data would never be handed to US authorities without explicit French agreement, he said: "Non, je ne peux pas le garantir," adding it hadn't happened so far. No guarantee, no known incident. If your provider's answer looks similar, that's consistent with the law, not a provider-specific red flag.

Q5 pins down the transfer mechanism. Under GDPR, personal data leaving the EEA needs an adequacy decision or safeguards like SCCs. For most US providers today, the answer is the EU-US Data Privacy Framework, adopted 10 July 2023.

Q6 is the real test. The DPF is the third attempt at an EU-US transfer deal. Safe Harbor died in 2015. Privacy Shield died in 2020 over inadequate remedies for EU citizens under US surveillance law. The DPF itself is mid-challenge right now: dismissed by the EU General Court on 3 September 2025, appealed on 31 October 2025, pending before the CJEU with no ruling yet. Ask for the concrete fallback plan, not a restatement that the current framework is valid today.

Q7 forces the conflict-of-laws admission. GDPR Article 48 says a foreign court order doesn't automatically make a transfer lawful. Ask the provider how they reconcile that with US legal obligations when the two clash. Most will answer carefully here, because there's a real, unresolved conflict.

Q8 is operational. Does access require a warrant/subpoena/court order with internal legal review, or is it closer to automatic compliance? This tells you whether anyone would push back on your behalf.

What to do with the answers

File all eight, in writing, with your data processing records. When a client or auditor asks "what happens if a US court comes knocking," you now have a documented position instead of a shrug.

Read the full original article on binadit.com

Originally published on binadit.com

Best practices for evaluating European alternatives to AWS, Azure and GCP

binadit — Wed, 21 Oct 2026 07:19:24 +0000

Someone asked you to evaluate EU cloud alternatives. Here's how not to waste three sprints on it

Your DPO, a customer, or procurement just asked whether you could run on European infrastructure instead of AWS, Azure or GCP. This isn't about picking a side in the sovereignty debate; it's about giving a straight technical answer. What actually breaks if you move, what's portable, and what needs real validation before anyone signs off.

This comes from running the same evaluation repeatedly for SaaS teams, agencies and e-commerce platforms going through procurement cycles or security questionnaires. None of it requires ditching Kubernetes, Terraform or your CI/CD setup.

Problem 1: "EU region" and "EU jurisdiction" get treated as the same thing

They're not. AWS, Azure and GCP all run EU data center regions, but the parent company is still bound by US law, CLOUD Act included, no matter where the bytes sit. If the actual requirement is jurisdictional separation, flipping a region dropdown on a hyperscaler doesn't solve it.

Fix: write this distinction into your evaluation criteria before comparing a single vendor. Otherwise you'll spend weeks comparing the wrong thing.

Problem 2: you're comparing brands instead of primitives

Most SaaS stacks need the same handful of things: compute, object storage, managed Postgres or MySQL, a load balancer, a CDN. List what you actually use, by capability, not by AWS product name.

# Example: workload inventory before evaluation
compute: 12 vCPU, autoscaling 2-8 nodes
object_storage: S3-compatible, 4TB, lifecycle rules
database: managed PostgreSQL 15, 200GB, daily PITR
cdn: edge caching, EU + UK pop coverage
queue: managed Redis, 2GB, persistence enabled

This turns a vague "can we replace AWS" into an answerable question: which EU providers offer S3-compatible storage, managed Postgres with PITR, and a comparable autoscaling setup.

Problem 3: assuming object storage means a rewrite

It usually doesn't. OVHcloud, Scaleway, Exoscale and Hetzner (via third-party gateways) all expose S3-compatible APIs. If your app talks to S3 through the standard SDK, repointing the endpoint and credentials is often enough.

aws s3 cp test.txt s3://my-bucket/test.txt \
  --endpoint-url https://s3.de.io.cloud.ovh.net \
  --profile eu-provider

Run this smoke test before you plan anything bigger.

Problem 4: the database layer is where things actually go wrong

Compute and object storage are portable. Managed databases are not, this is where EU providers diverge most: feature parity, replication tooling, backup retention defaults. Before committing to anything, run a full backup/restore cycle on the target provider and measure recovery time for real.

Problem 5: latency assumptions based on a data center brochure

Frankfurt or Amsterdam will serve EU traffic fine. If 20% of your users are in the UK, US or APAC, that's a different story. Run synthetic tests from multiple regions with mtr or a distributed probe service, and look at p50/p95, not averages.

Problem 6: CDN "EU" claims that don't match actual routing

Some EU-headquartered CDN resellers still route certain regions through non-EU origin infrastructure. If sovereignty is a real requirement, get a documented PoP list and trace actual request paths yourself:

curl -w "@curl-format.txt" -o /dev/null -s https://your-cdn-endpoint.com

Or a plain traceroute from your target markets.

Problem 7: certifications that apply to the reseller, not the facility

Ask for the ISO 27001 (and NEN 7510 where relevant) of the physical data center, not the managed service layered on top. A logo on a website isn't a certificate. Request the actual scope statement.

Problem 8: pricing only the compute line

European providers often look cheaper per vCPU hour, until you add egress, backup storage, IP allocation and support tiers. Build a like-for-like monthly cost model across at least three providers using your real usage pattern, not a generic instance size.

Problem 9: IaC that was never tested against the new provider

If your Terraform targets AWS-specific resources, you usually need a provider swap, not a rewrite, for standard compute and networking. Run terraform plan against a sandbox account early.

provider "openstack" {
  auth_url    = var.ovh_auth_url
  domain_name = "default"
  tenant_name = var.ovh_project_id
}

resource "openstack_compute_instance_v2" "app" {
  name            = "app-node-1"
  flavor_name     = "b2-15"
  image_name      = "Ubuntu 22.04"
  security_groups = ["default"]
}

This catches unsupported resource types (certain autoscaling policies, specific VPC peering models) before they block you mid-migration.

Problem 10: treating the cutover as a single switch

Run both environments in parallel with DNS-weighted traffic splitting. Validate error rates and latency at each traffic percentage. Keep the old environment warm through at least one full peak traffic cycle. This is standard practice for any zero-downtime migration, and it's what keeps a sovereignty decision from turning into an outage.

How to actually roll this out

Don't try to do all ten in one sprint.

Phase 1 (1-2 weeks): workload inventory and requirement separation. Pure documentation, gives procurement or legal something concrete to work with.
Phase 2 (2-4 weeks): sandbox validation against at least two candidate providers. Runs in parallel with production, costs a few hundred euros in test resources, produces real numbers instead of vendor claims.
Phase 3 (4-10 weeks): staged migration with IaC parity testing and a reversible cutover. Keep a rollback window of at least one full business cycle before decommissioning anything.

Assign one engineer as technical owner from day one. Splitting this across the team produces benchmarks that don't line up later.

None of this requires faith. It requires inventory, benchmarking and a staged rollout, the same discipline you'd apply to any infrastructure change.

Full version with more context here: Best practices for evaluating European alternatives to AWS, Azure and GCP

Originally published on binadit.com

Why cheap hosting becomes expensive, and how managed cloud infrastructure fixes the math

binadit — Fri, 16 Oct 2026 07:03:43 +0000

Your €30/month VPS is lying to you about its real cost

Every engineer who has run a Friday-afternoon incident on a budget VPS knows this story. The invoice says €30. The actual bill includes a 20-minute checkout outage, a Slack thread full of panic, and three hours of your time spent figuring out why MySQL is refusing connections. None of that shows up on the hosting receipt. It shows up in your sprint velocity.

This is the real pattern behind most migrations to managed infrastructure: the sticker price was never the full price. Let's break down why, and what actually fixes it.

Why cheap hosting is a cost-shifting machine, not a cost-saving one

Budget hosting plans work on oversubscription: sell the same CPU and memory pool to more tenants than could ever use it simultaneously. Fine, until your app actually needs what it was promised.

Three failure modes show up constantly:

Noisy neighbors. Shared I/O and CPU scheduling means someone else's batch job can wreck your p95 latency without you changing a single line of code.
No headroom for peaks. Plans are sized for average load. A 3x traffic spike from a launch or a viral post pushes memory past the limit, and the OOM killer starts picking off PHP-FPM workers or your database process.
Zero engineering time baked in. Nobody tunes innodb_buffer_pool_size, rotates logs before disk fills, or watches your TLS cert expiry. That work doesn't vanish, it just gets dumped on whoever's on call, mid-incident instead of before one.

The math, concretely

A €30/month plan versus a properly sized €200/month managed VPS looks like €2,040/year in savings. Now add two checkout outages a year at 25 minutes each, on a store doing €500/day: roughly €520 in lost sales. Add 4-6 engineering hours to diagnose and recover at a €75/hour loaded cost: another €300-450. The "cheap" plan is already more expensive before you count what that engineer could've shipped instead.

Where the cost actually hides

In migrations off budget hosting, the hidden cost clusters in three spots:

Database performance degrading silently until one slow query takes the whole site down.
No staging environment that resembles production, so customers find bugs before CI does.
Manual TLS renewal that gets missed once a year and kills the whole domain for hours.

None of these are exotic problems. They're recurring operational work that a €30/month plan was never designed to cover.

The fix: size for reality, automate the boring stuff, isolate the database

1. Size compute to peak, not average

Pull 90 days of CPU/memory metrics. No data? That's a signal on its own. Quick baseline on Linux:

vmstat 2 10
free -m
mpstat -P ALL 1 5

Target 60-70% utilization at peak, not 95%. If campaigns spike you 3x, provision for that or put autoscaling in front of it.

2. Separate the database from the app tier

On budget hosting, MySQL and your web server fight for the same resources. Splitting them onto two modest instances kills most noisy-neighbor issues. Baseline tuning for a dedicated MySQL 8 box with 8GB RAM:

[mysqld]
innodb_buffer_pool_size = 5G
innodb_log_file_size = 512M
max_connections = 150
innodb_flush_log_at_trx_commit = 1
query_cache_type = 0

Buffer pool at roughly 60-70% of RAM, leaving room for connections and OS cache. On a 2GB plan this is simply not possible, which is the actual reason your 40ms query takes 900ms on shared hosting.

3. Automate what fails silently

Cert expiry and disk-filling logs cause most "surprise" outages. Both fixable in under an hour:

# certbot auto-renewal via systemd timer, twice daily
certbot renew --quiet --deploy-hook "systemctl reload nginx"

4. Build staging that actually resembles production

If staging is a subdirectory with debug mode flipped on, it's not catching production-class bugs. Match PHP version, DB engine version, and resource ratios (smaller is fine, different is not). Skip this and every deploy becomes a gamble.

How to know it actually worked

Don't trust "it feels faster." Check numbers before and after:

Metric	Budget hosting	Right-sized managed infra
P95 response time	800-1500ms	150-300ms
DB query p95	300-900ms	20-60ms
Unplanned restarts/month	2-5	0-1
Memory headroom at peak	<10%	30-40%

Validation checklist:

mysqladmin status to confirm no connection queueing under load
Load test at 2-3x normal peak with k6, watch 5xx rates and latency trend, not just averages
free -m during peak, zero swap usage, any swap activity means you're still undersized
Measure TTFB separately from full page load, they diagnose different bottlenecks
If you have incident history, track MTTR before/after; properly managed infra tends to shift this from hours to minutes because failover and monitoring are built in

Keeping it fixed

Review capacity quarterly, not after an incident
Treat SSL renewal, backups, and patching as code, not a human's memory
Load test before big traffic events, not after an outage during one
Isolate the database tier early, it's the first and most common contention point
Keep staging close enough to production to catch real bugs

None of this needs exotic tooling. It needs someone accountable for checking it on a schedule. That's usually the actual gap.

Full writeup with more detail: Why cheap hosting becomes expensive, and how managed cloud infrastructure fixes the math

Originally published on binadit.com

A 12-question sovereignty audit every DPO should run

binadit — Wed, 14 Oct 2026 09:15:10 +0000

Your vendor says 'no US subprocessors.' Here's how to actually check

Your DPO just forwarded you another vendor questionnaire with a checked box next to "no US subprocessors." Before you forward it back with a thumbs up, know this: most of those boxes get checked optimistically, not accurately. If you're the engineer who ends up answering "where does our data actually live" during procurement calls, this list is for you.

The gap is rarely malicious. It's usually a monitoring tool that defaulted to a US region, a backup target nobody revisited after setup, or a subprocessor that's legally based in the EU but owned by a US parent. Sovereignty audits exist to find exactly that gap.

Why yes/no questionnaires fail

A vendor questionnaire asks "do you store data in the EU?" and gets a yes. It doesn't ask who holds the encryption keys, where support engineers sit, or whether the CDN in front of the app routes through a US edge network. Evidence beats assertions every time.

The checks that actually matter

Subprocessor list freshness. If a vendor's public subprocessor list hasn't changed in over a year despite shipping new features, it's probably stale, not accurate.

Parent company ownership, not just contracting entity. A subprocessor incorporated in Germany can still be a wholly owned US subsidiary, which pulls it under the CLOUD Act regardless of server location. Always ask for the ultimate parent, not the signing entity.

Support and escalation location. If a US-based support engineer can remote into production to debug something, that's a data access path your residency clause doesn't cover.

Monitoring and APM defaults. Sentry, Datadog, and New Relic all offer EU hosting, but it's opt-in. Primary infra can be EU-only while telemetry leaks through a third-party integration nobody checked.

CDN and DNS routing. A CDN is a subprocessor too. Origin in Frankfurt doesn't mean much if the CDN is a US hyperscaler's edge network. You can verify this yourself:

# Check which edge network is actually serving a domain
dig +short CNAME cdn.example.com

# Trace the resolved IP's registered location
whois $(dig +short cdn.example.com | tail -1)

This won't give you a legal answer, but it'll tell you fast whether the CDN claim matches DNS reality.

Backup and DR region. EU-only production paired with a US backup target is common, usually because backup tooling defaulted there during setup and nobody revisited it. Ask explicitly where backups, snapshots, and DR replicas live.

Who holds the encryption keys, and from where. Encryption at rest is table stakes. If a US entity or cloud provider holds the keys, EU residency doesn't block a lawful access request.

Legal basis for remaining transfers. If zero international transfers isn't achievable, find out if they're relying on SCCs, BCRs, or something else, and whether it's been tested against post-Schrems II expectations.

Documented incident response for law enforcement requests. Ask what happens procedurally if a non-EU authority requests data. If there's no written process, there's no real process.

Whether the infra partner's own tooling is sovereign. Some vendors sell you an EU-region sovereignty story while their own ticketing or remote access tooling runs on US SaaS.

Failover and migration behavior. Sovereignty guarantees are easiest to break during a DR drill or fast migration. Ask the vendor to walk through a specific failover scenario and confirm the DR target still meets the same residency commitments as production.

Direct technical contact. Can someone answer these questions in a conversation, or does everything route through a ticket queue with a copy-pasted compliance statement three days later? The former usually means they understand their own subprocessor chain.

Get the real subprocessor table, not a summary

Ask for the DPA's actual subprocessor annex. It should look like this:

Subprocessor      | Purpose              | Entity location    | Parent HQ
EU hosting partner| Infrastructure       | Netherlands        | Netherlands
EU email relay    | Transactional email  | Germany             | Germany
Monitoring vendor | APM / error tracking | EU region (opt-in)  | United States

That third row fails a strict no-US-subprocessor policy even though the data is technically hosted in the EU. The parent HQ column is the one most vendor tables conveniently leave out.

Rolling this out without reopening every contract at once

Most teams have ten to thirty vendors already under contract. Don't try to audit all of them simultaneously.

Tier vendors by how much regulated or personal data they touch
Run the full check against top-tier vendors first: core infra, email/identity, anything handling payment or health data
Bake the subprocessor table requirement into procurement for new vendors from day one

Full details and context: the original sovereignty audit checklist.

Originally published on binadit.com

How to automate SSL certificate renewal across a fleet of servers

binadit — Fri, 09 Oct 2026 07:44:08 +0000

Stop babysitting SSL certs: automate renewal across your whole fleet

If someone on your team still has a recurring calendar reminder to check certificate expiry dates, you have a problem worth fixing today. Not next quarter, today. Manual cert tracking across multiple hosts is the kind of low-grade recurring work that quietly eats hours every month and never shows up as a line item until something expires in production at 2am.

This guide walks through building fleet-wide automated renewal using Let's Encrypt, the ACME protocol, and a central orchestration pattern. It works whether you have 5 boxes or 500, behind a load balancer, as separate app nodes, or spread across regions.

Assumptions before you start

You control DNS (or can hit a DNS API) for Cloudflare, Route 53, DigitalOcean, etc.
Linux servers (Ubuntu 22.04/24.04 in examples, distro-agnostic approach)
SSH access across the fleet, ideally via Ansible or Salt, not manual loops
TLS termination happens at Nginx or HAProxy, not inside the app itself
You're fine with cron or systemd timers

We'll use certbot since it has the broadest plugin support, though acme.sh or lego work fine with the same architecture if you want something lighter.

Pick a validation method that actually scales

HTTP-01 validation needs port 80 reachable on the exact host being validated. That's fine for one server. It falls apart across a fleet behind a load balancer, where traffic for a domain doesn't predictably land on the same box twice.

DNS-01 is the better default. No inbound traffic required, supports wildcards, and lets you centralize issuance on one host even if the cert gets distributed everywhere else.

Cloudflare example:

apt install certbot python3-certbot-dns-cloudflare -y

cat > /etc/letsencrypt/cloudflare.ini << EOF
dns_cloudflare_api_token = YOUR_TOKEN
EOF

chmod 600 /etc/letsencrypt/cloudflare.ini

Centralize issuance, distribute the result

Don't run certbot independently on every server. That gives you inconsistent cert state across the fleet and more surfaces that can silently fail. Issue once, push everywhere.

Use a deploy hook to push the renewed cert out via your config management tool:

cp /etc/letsencrypt/live/example.com/fullchain.pem /etc/haproxy/certs/example.com.pem
systemctl reload haproxy

Keep that logic in one deploy hook script, not scattered across playbooks. One script, one source of truth for what happens post-renewal.

Don't forget the reload

Copying a new cert file does nothing if the service is still holding the old one in memory. Every distribution step needs a paired reload handler, Nginx or HAProxy, whichever terminates TLS.

Alert on failure, not just on success

A cron job that fails silently for a month isn't automation, it's a delayed incident waiting to happen. Wrap the renewal and check the exit code:

#!/bin/bash
if ! certbot renew --quiet; then
  curl -X POST https://hooks.slack.com/services/YOUR/WEBHOOK/URL \
    -d '{"text":"Certbot renewal failed on '"$(hostname)"'"}'
fi

Swap the webhook for whatever your team already uses, PagerDuty, Opsgenie, Slack. The point is a human sees the failure within a day, not when the cert is about to expire.

Verify it actually works

Don't trust the cron job exists and assume it's fine. Check end to end.

Dry run:

certbot renew --dry-run

Check expiry across the fleet:

for host in $(cat fleet_hosts.txt); do
  echo -n "$host: "
  echo | openssl s_client -connect $host:443 -servername $host 2>/dev/null \
    | openssl x509 -noout -enddate
done

Better yet, wire cert expiry into your existing monitoring. Prometheus blackbox exporter, Uptime Kuma, Zabbix all support it natively. Alert when probe_ssl_earliest_cert_expiry drops below 14 days, this is your independent confirmation layer outside certbot's own logs.

And confirm distribution reached every node, not just the one that ran certbot:

ansible web_fleet -m shell -a "openssl x509 -in /etc/ssl/certs/example.com.pem -noout -enddate"

A mismatched expiry date across hosts means distribution failed somewhere, which is a more common failure mode than renewal itself breaking.

Pitfalls worth avoiding

Hardcoding API tokens in playbooks instead of using a secrets manager
Forgetting the service reload after distribution
Hitting Let's Encrypt's rate limit (50 certs per registered domain per week), easy to hit if you're doing per-subdomain certs instead of a wildcard
Running certbot independently per server instead of centralizing
Shipping automation with zero failure alerting

Where this goes next

The same pattern, central issuance plus fleet-wide distribution via config management, extends naturally to SSH key rotation, firewall rule pushes, and post-migration config redeploys. If you're running this at scale, folding it into a GitOps pipeline means one less automation system to monitor separately from your app deployments.

Full original writeup with more detail: binadit.com

Originally published on binadit.com

Understanding what an Outlook alternative actually needs to do to keep mail in Europe

binadit — Wed, 07 Oct 2026 09:43:02 +0000

Switching your inbox region doesn't change who owns the data

If you've ever ticked "EU data region" in Microsoft 365 or Google Workspace and considered the jurisdiction problem solved, here's the uncomfortable part: it isn't. The US CLOUD Act (2018) says a provider under US jurisdiction must hand over data under its possession, custody or control when a US court orders it, regardless of which country the servers physically sit in. The law tracks the company, not the data centre. Let's get into why that matters for anyone planning a real outlook alternative, and what actually has to change under the hood.

The jurisdiction problem, in plain terms

Outlook is the client. Microsoft 365 is the service. For most orgs those have merged into one experience, but legally they're two different things, and the service is what matters here.

Microsoft Corporation: American company, subject to US law
Google LLC: American company, subject to US law
CLOUD Act: applies based on custody, not server location

Meanwhile GDPR Chapter V (Articles 44-50) restricts personal data leaving the EEA without an adequacy decision or safeguards like SCCs. Article 48 is the key detail most teams miss: a foreign court order doesn't automatically make a transfer lawful. Article 24 puts the compliance burden on you, the controller, not the vendor.

These two legal regimes don't reconcile cleanly, and the courts have said so three times:

Safe Harbor, struck down by the CJEU in 2015
Privacy Shield, struck down in Schrems II (July 2020), over FISA Section 702 giving EU citizens no real remedy against US government access
EU-US Data Privacy Framework, adopted 10 July 2023, currently in force, but under active challenge: dismissed by the EU General Court on 3 September 2025, appealed 31 October 2025, and now pending before the CJEU

If you want the sworn-testimony version of this: on 10 June 2025, Microsoft France's director of public and legal affairs, Anton Carniaux, was asked under oath before a French Senate inquiry whether he could guarantee French citizens' data would never be handed to the US government without French authorisation. His answer: "Non, je ne peux pas le garantir" ("No, I cannot guarantee that"), while noting it hadn't happened so far. No guarantee, no known incident. Both halves matter.

Where the exposure actually lives in the mail pipeline

When mail moves through Microsoft 365, it typically passes through multiple Microsoft-controlled systems, each one a separate copy:

Send -> Exchange Online mailbox
     -> Spam/malware filtering
     -> Journaling/compliance archive
     -> Legal hold / eDiscovery store (if applicable)

Every one of those is under Microsoft's custody regardless of region settings. Picking an EU data centre changes the postal address of the hardware. It does not change who has custody.

What a real migration actually requires

Say you're moving a 40-person org off Microsoft 365: Outlook, OneDrive, Teams, plus a shared info@ mailbox watched by three people. Here's the checklist, piece by piece:

Protocols the new provider must support:

IMAP / SMTP   -> mail
CalDAV        -> calendar
CardDAV       -> contacts

If the replacement is web-app-only with no protocol support, you've just swapped one lock-in for another.

Shared mailbox permissions: info@ needs multi-user access control without issuing separate logins per person.

DNS/auth records to rebuild:

SPF record  - sender authorization
DKIM record - message signing
DMARC record - policy enforcement

Get these wrong and your outgoing mail gets flagged as spam.

Client UX: People are used to the three-pane layout (folders / message list / reading pane). Force everyone into a browser tab and adoption drops, independent of how solid the backend is.

File sync: Needs to replicate "files on demand" behavior, files show as available without consuming local disk until opened.

Meetings: Guests need to join via browser link, no install required, since you can't mandate your internal tooling on every client or supplier.

How Binadit Workspace addresses this

Binadit Workspace covers that full checklist as one product, one login, on the customer's own domain:

Mail/calendar/contacts over IMAP, SMTP, CalDAV, CardDAV, and JMAP, so existing clients keep working
Shared mailboxes with per-colleague permissions
DNS records (MX, SPF, DKIM, DMARC, autoconfig) placed automatically via Binadit's own DNS tool
Northmail: free macOS/Windows mail client in the familiar three-pane layout, connects to Workspace, on-prem Exchange, and Gmail simultaneously, useful during phased migrations

Bottom line

An outlook alternative isn't about finding a nicer inbox UI. It's about finding a provider under a different legal jurisdiction, one that actually replaces the full protocol stack your org depends on, not just the icon on the desktop.

Full writeup with the legal citations: https://binadit.com/blog/outlook-alternative-keeps-mail-in-europe

Originally published on binadit.com

How to set up website server performance that holds under real traffic

binadit — Fri, 25 Sep 2026 07:53:52 +0000

Your server works fine until it doesn't

Every infrastructure engineer knows this moment: the server hums along fine in staging, then a traffic spike hits production and everything falls over. Requests queue, workers pin at max, response times spike from 200ms to 8 seconds. The usual reaction is to throw more CPU at it. That's rarely the actual problem.

Most servers that collapse under load aren't under-resourced, they're misconfigured. The default settings for PHP-FPM, Nginx, and your database connections were never meant for production traffic. Here's the exact sequence of changes that fixes this, in the order that actually matters.

Step 0: measure before you touch anything

You can't prove a fix worked without a baseline. Run this first:

ab -n 1000 -c 50 https://yourdomain.com/

Record requests per second, mean response time, and failed request count. Check uptime and vmstat 1 5 during the test too. Write it all down; you'll compare against it later.

Fix 1: PHP-FPM is probably misconfigured

The default pool config is not production-ready. Open it:

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

Size your workers based on actual memory usage, not guesswork. Check real footprint per worker with ps aux | grep php-fpm (typically 30-60MB for WordPress/Laravel), then divide available RAM by that number.

pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

pm.max_requests is underrated. It recycles workers periodically, which stops slow memory leaks from degrading your server over hours of uptime.

Fix 2: Nginx is dropping connections it doesn't need to

Reduce TCP handshake overhead with proper keepalive and connection settings:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

If you're proxying to PHP-FPM over a Unix socket, bump the backlog to match expected concurrency:

listen = /run/php/php8.3-fpm.sock
listen.backlog = 1024

Fix 3: your database connections are too expensive

Each unpooled connection costs a handshake, auth round trip, and memory allocation. At scale, this is a silent killer. For Postgres, PgBouncer is the standard fix:

sudo apt install pgbouncer

[databases]
yourapp = host=127.0.0.1 port=5432 dbname=yourapp

[pgbouncer]
listen_port = 6432
auth_type = md5
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25

Point your app at port 6432 instead of 5432. This typically cuts connection overhead by 60-80% under concurrent load. MySQL users: look at ProxySQL or mysqlnd_mux.

Fix 4: cache what shouldn't hit the database every time

Install Redis:

sudo apt install redis-server
sudo systemctl enable redis-server

Set eviction policy so it doesn't just run out of memory:

maxmemory 512mb
maxmemory-policy allkeys-lru

For custom apps, wrap expensive queries in a cache-aside pattern:

$cacheKey = "product:{$id}";
$product = $redis->get($cacheKey);
if (!$product) {
    $product = $db->query("SELECT * FROM products WHERE id = ?", [$id]);
    $redis->setex($cacheKey, 300, serialize($product));
}

Fix 5: stop static assets from hitting your app server

location ~* \.(jpg|jpeg|png|gif|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

If there's a CDN in front, confirm it respects your origin headers instead of overriding with its own default TTL.

Verifying it actually worked

Re-run the same load test, same concurrency:

ab -n 1000 -c 50 https://yourdomain.com/

Compare against baseline. RPS should climb, often 30-100%. Response time variance between p50 and p95 should tighten. Failed requests should hit zero at your target concurrency.

Watch PHP-FPM workers scale during load:

watch -n 1 'ps aux | grep php-fpm | wc -l'

Workers should scale up smoothly and settle, not spike immediately to max_children and stay there. If they pin instantly, either your sizing is wrong or a slow query is holding connections open too long.

Check PgBouncer is actually in the path:

psql -h 127.0.0.1 -p 6432 -U youruser yourapp -c "SHOW POOLS;"

And check Redis hit rate:

redis-cli info stats | grep keyspace

Healthy cache-aside logic should show above 80% hit ratio within minutes.

Mistakes that undo all of this

Oversizing max_children. More workers than RAM supports causes swapping, which is worse than queued requests.
Caching without invalidation. Stale cached data is a harder bug to catch than a slow endpoint. Always set a TTL or invalidate on write.
Pooling without adjusting app-level assumptions. Transaction-mode pooling breaks session-level features like advisory locks if your app still expects a persistent connection.
Skipping the baseline. No before/after numbers means no proof anything worked.

This isn't a full re-architecture. It's five configuration changes applied in order, with measurement at each step. That's usually enough to take a server from falling over at the first spike to handling concurrency predictably.

Full walkthrough with more context: How to set up website server performance that holds under real traffic

Originally published on binadit.com

Your email is GDPR-compliant today. Will it still be next year?

binadit — Sun, 20 Sep 2026 13:07:11 +0000

Your GDPR compliance depends on a court case you're not tracking

Here's an uncomfortable fact: the legal basis for your Google Workspace or Microsoft 365 email is a single framework that's currently being challenged in front of the same court that already killed its two predecessors. If you run infrastructure or make hosting decisions, this is worth ten minutes of your time.

Ask your IT partner if EU email in a US productivity suite is GDPR-compliant and you'll get a confident yes: both providers are certified under the EU-US Data Privacy Framework. Technically true. Also missing the point.

The legal stack, in short

Sending personal data to a US company is a "transfer" under GDPR Chapter V (Articles 44-50).
That's only lawful today because of the EU-US Data Privacy Framework (DPF), adopted July 2023.
Its two predecessors, Safe Harbor and Privacy Shield, were both struck down by the Court of Justice of the EU (CJEU).
The DPF is now under appeal at that same court.

Three attempts. Two collapses. One pending verdict. That's not a stable foundation to build a compliance program on.

"We use an EU data center" doesn't fix it

This is the part engineers get wrong most often. Region selection is not jurisdiction. Under the US CLOUD Act, a US company has to hand over data it controls when a US authority demands it, regardless of which data center it's sitting in. A Frankfurt or Amsterdam region owned by a US parent is still in scope.

Don't take my word for it. In June 2025, Microsoft France's director of legal affairs testified under oath before a French Senate inquiry. Asked directly if he could guarantee French citizens' data would never be handed to the US government without French authorization, his answer was: "No, I cannot guarantee that."

That's the provider, on the record, under oath.

Where things stand right now

A challenge to the DPF (Latombe v. Commission) was dismissed by the General Court in September 2025, but only on facts as they existed in 2023. Nothing since then was considered. It's now on appeal to the CJEU.
Microsoft was granted leave to intervene in that appeal. A company doesn't intervene in EU court proceedings unless it has serious skin in the game.
The US oversight board that underpins the DPF (PCLOB) has been without quorum since January 2025.
In June 2026, the US Supreme Court ruled FTC commissioners can be removed at will by the President. The FTC is the enforcement body for the DPF on the US side.
FISA Section 702, the surveillance law at the center of the original Schrems II ruling, lapsed in June 2026 after failed extensions. Collection continues under existing court certifications regardless.

None of this means the DPF will definitely fall. It means your compliance posture depends on a decision you don't control, on a timeline you can't predict. Last time this happened (Schrems II, July 2020), companies had zero notice and a three-year gap before a replacement existed.

The AI layer adds more surface area

Copilot and Gemini are now embedded directly in mail and file storage. That's more data flows to account for:

# Questions worth asking your provider contract, literally:
- Does input get used for model training? (check tier, not marketing page)
- Can you delete a specific individual's data from a trained model? (usually no)
- Do you know which model processed which record, in which region?

The EU AI Act's transparency rules are already active (since August 2026). The heavier documentation requirements for HR, credit, and access-to-services use cases were pushed to December 2027, but that's a delay, not a way out. If you can't answer the questions above today, you won't be able to answer them then either.

The actual fix

If email, calendar, and file storage sit with a provider incorporated and operating entirely in the EU, no CLOUD Act exposure exists because there's no US legal entity to compel. That's not a mitigation, it's the absence of the transfer problem entirely.

As a data point: a Dutch provider offering this setup starts at €1.99 per mailbox per month, often cheaper than what teams already pay for Workspace or M365 licensing.

Practical takeaway

Check who actually handles mail for your domain (MX records will tell you the provider, not the jurisdiction, but it's a start). Then ask your provider the same question the French Senate asked Microsoft: can you guarantee this data is never handed over without our government's consent? If the answer is "no, but it hasn't happened," that's not a compliance guarantee, that's a probability bet.

Full breakdown of the legal timeline and case law: Your email is GDPR-compliant today. Will it still be next year?

Originally published on binadit.com

Solving the deploy frequency wall: from weekly releases to multiple daily deploys without new incidents

binadit — Fri, 18 Sep 2026 07:59:30 +0000

Why your team keeps reverting to weekly deploys (and how to actually fix it)

Here's a pattern that shows up constantly in teams of 15-40 engineers: leadership pushes for faster releases, the team bumps deploy frequency up, and within a few weeks someone quietly walks it back to weekly. No mandate, no meeting. Just two or three rough releases in a row, and the team self-polices back to "safe" cadence.

It looks like a discipline problem. It isn't. It's an infrastructure problem, and it's fixable.

The real issue: your pipeline was built for a different era

When you deploy weekly, you can afford sloppiness because a human has time to babysit each release. Watch the error rate for 20 minutes, glance at a dashboard, ship it. Try that five times a day and the manual check either disappears or becomes theater nobody trusts.

Under the hood, this usually comes down to four coupled problems:

Deploys aren't atomic. Code, migrations, and config all ship in one shot. If the migration is slow, the code can't go out without it.
Rollback means redeploying. Reverting takes the same pipeline, the same time, the same risk as deploying forward.
Monitoring lags deploy speed. Alert thresholds and log delays were tuned for hourly checks, not minute-by-minute validation.
Blast radius is 100%. Every deploy hits the whole fleet at once, so any bad release is automatically a full incident.

None of this is about code quality or test coverage. It's about the deploy path, routing layer, and monitoring stack not being built for the frequency you're asking of them.

The fix: decouple, automate rollback, shrink the blast radius

1. Split schema changes from code deploys

Migrations are usually the biggest source of deploy anxiety. Use the expand/contract pattern so schema changes never ship in the same step as code:

-- Step 1: expand (safe, backward compatible)
ALTER TABLE orders ADD COLUMN shipping_method_v2 VARCHAR(50) NULL;

-- Step 2: dual-write in app code, backfill
UPDATE orders SET shipping_method_v2 = shipping_method WHERE shipping_method_v2 IS NULL;

-- Step 3: contract (separate deploy, days later)
ALTER TABLE orders DROP COLUMN shipping_method;

Code deploys stop waiting on migrations, and migrations stop blocking rollbacks.

2. Make rollback a routing flip, not a redeploy

If reverting means rerunning the pipeline backward, people will hesitate to ship under pressure. Rollback should be a traffic switch, done in seconds:

# Nginx upstream weight shift for canary rollback
upstream backend {
    server app-v124-1:8080 weight=0;   # new version, was live
    server app-v123-1:8080 weight=100; # previous stable, restored
}
# reload takes effect in under 1 second
nginx -s reload

Or on Kubernetes:

kubectl rollout undo deployment/checkout-api
kubectl rollout status deployment/checkout-api --timeout=30s

Ship to a small slice of instances first. Healthy? Shift more weight over. Not healthy? Shift back to zero. No twelve-minute rebuild required to recover.

3. Automate the canary check

A human staring at Grafana for 20 minutes works at weekly cadence. At five deploys a day, it's neither sustainable nor reliable, people get worse at spotting anomalies the more times they repeat the check.

canary:
  metrics:
    - name: error_rate
      threshold: baseline + 0.5%
      window: 5m
    - name: p95_latency
      threshold: baseline + 15%
      window: 5m
    - name: 5xx_count
      threshold: baseline + 10
      window: 5m
  action_on_fail: auto_rollback
  promotion_steps: [5%, 25%, 50%, 100%]
  step_duration: 5m

This is probably the single highest-leverage change for teams moving to daily deploys. It turns a subjective judgment call into a repeatable gate.

4. Shrink the blast radius with progressive rollout

Deploying to 100% of instances at once makes every release a full-fleet bet. Instead:

Ship to 5% of instances or one availability zone
Hold through a full traffic cycle, including cron jobs and batch work
Auto-promote on healthy metrics, auto-rollback on bad ones
Only reach 100% after clearing every stage

Same principle as safe database migrations: keep each irreversible step small.

How to know it actually worked

Don't just track "deploy success." Watch these specifically:

Change failure rate: percentage of deploys triggering a rollback or hotfix. Aim under 15% (DORA elite benchmark), trending down as frequency goes up.
MTTR: with automated rollback via traffic weight shift, this should drop under 5 minutes.
Rollback execution time: measure from "threshold breached" to "traffic fully reverted." Should be seconds to low minutes, not tied to build time.
Canary false negative rate: how often something bad slips past the gate and gets caught by users instead. If it happens more than once a quarter, retune thresholds, don't remove the gate.
Deploy frequency vs. incident count: these two lines should decouple. If incidents still climb with frequency, your canary metrics are probably missing a business signal like checkout completion or cart abandonment.

Give this at least four weeks at the new cadence before declaring victory. One good week proves nothing.

Keeping it from backsliding

Alert on deploy frequency itself. A quiet drop without an explicit decision usually means the pipeline is causing avoidance.
Treat canary thresholds as living config, not a one-time setup. Traffic patterns shift, thresholds need to shift with them.

Full technical breakdown, including the zero-downtime migration mechanics: read the original article

Originally published on binadit.com