DEV Community: binadit

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

How to stabilize a system while it is actively failing

binadit — Wed, 16 Sep 2026 07:32:01 +0000

Stop diagnosing, start stabilizing: a field guide for live incidents

Your error rate just spiked. Someone is already asking "what changed?" in Slack. Here's the uncomfortable truth: the fastest way to make an incident worse is to start debugging the root cause before you've stopped the bleeding. This is the sequence we use to stabilize production systems first and investigate second, whether that's a single Node server or a full multi-node setup behind a load balancer.

The two mistakes that make incidents worse

Under pressure, teams almost always do one of these:

Change too many things at once, so nobody can tell what fixed (or broke) what
Start root-causing before the system is even stable

Everything below exists to prevent those two mistakes.

What you need before an incident happens

You can't stabilize what you can't see or touch. Minimum bar:

Shell access to affected hosts (SSH or a bastion)
Basic monitoring: CPU, memory, disk I/O, error rates (Prometheus, Datadog, or even htop plus logs)
A load balancer or reverse proxy in front of the app (Nginx, HAProxy, cloud LB)
A known, tested rollback procedure
A second person to sanity-check decisions, even just in a Slack thread

If you're missing any of this, that's your next project, not something to build mid-incident.

Step 1: freeze all changes

This isn't technical, it's procedural. Post this immediately:

INCIDENT: elevated error rate on checkout-api since 14:32 UTC.
No deploys, no config changes, no manual DB edits until stabilized.
Incident channel: #inc-2024-checkout

This stops the classic "quick fix" from a well-meaning teammate that stacks a second problem on top of the first one you haven't diagnosed yet.

Step 2: check what changed in the last 24 hours

Most live failures trace back to something recent: a deploy, a config edit, a traffic spike, or an upstream update.

# Recent deploys
git log --since="24 hours ago" --oneline

# Recent config changes (if infra is version controlled)
git -C /etc/nginx log --since="24 hours ago"

# System-level changes
last -x | head -20
cat /var/log/dpkg.log | grep "$(date +%Y-%m-%d)"

If timing lines up, roll back before you dig further:

# Tagged release rollback
git checkout tags/v2.14.1
./deploy.sh production

# Kubernetes rollback
kubectl rollout undo deployment/checkout-api

Step 3: shed load before you preserve correctness

No obvious recent change, or the rollback didn't help? Reduce load on the failing component. You're trading functionality for stability, temporarily.

Ordered roughly by disruption:

Rate limit at the edge (per IP or per token)
Kill non-critical endpoints: recommendations, analytics beacons, background reports
Maintenance page for non-essential routes, keep checkout/login alive
Scale horizontally if the bottleneck is compute, not a shared resource

Emergency Nginx rate limit:

limit_req_zone $binary_remote_addr zone=emergency:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=emergency burst=10 nodelay;
        limit_req_status 503;
        proxy_pass http://backend;
    }
}

nginx -t && nginx -s reload

Step 4: the database goes first

Databases usually fail last and recover slowest. A saturated DB will keep everything else unstable no matter what you fix upstream.

-- Connections vs max
psql -c "SELECT count(*) FROM pg_stat_activity;"
psql -c "SHOW max_connections;"

-- Long-running queries
psql -c "SELECT pid, now() - query_start AS duration, query
         FROM pg_stat_activity
         WHERE state = 'active'
         ORDER BY duration DESC LIMIT 10;"

Kill runaway queries holding locks:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid = 14832;

If connection exhaustion is the pattern, PgBouncer fixes this without touching app code. No pooler running? That's your action item once the fire's out.

Step 5: fail over instead of fighting a bad node

Disk pressure, memory leak, bad kernel state on one box: pull it from rotation instead of debugging it live.

# HAProxy
echo "disable server backend/web03" | socat stdio /var/run/haproxy.sock

# Kubernetes
kubectl cordon node-3
kubectl drain node-3 --ignore-daemonsets --delete-emptydir-data

Once it's out of rotation, it's a forensic artifact you can inspect at your own pace, not a liability sitting in the traffic path.

Step 6: communicate facts, not guesses

STATUS 15:10 UTC: error rate back to baseline (0.2%) after rolling back
deploy v2.14.2 and draining node-3. Root cause under investigation.
Next update in 30 min or on change.

Don't close the incident the second the dashboard looks calm.

How to actually verify stability

One green graph isn't proof. Hold these steady for 30 to 60 minutes at real traffic:

Error rate: back to baseline, checked in 5-minute buckets, not instant values
Latency: p50, p95, and p99 all recovered, a good average can hide a bad p99
Resource headroom: CPU, memory, connection pools have actual margin
Queue depth: backlogs draining, not just growing slower

# Nginx status code breakdown
tail -n 5000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c

# Live connection stats
watch -n 2 "ss -s"

# DB connection headroom
psql -c "SELECT count(*), max_conn FROM pg_stat_activity, (SELECT setting::int AS max_conn FROM pg_settings WHERE name='max_connections') s GROUP BY max_conn;"

Compare current traffic-normalized error rate to the same time last week, not to five minutes ago. Post-load-shedding quiet periods lie.

Pitfalls to avoid

Root-causing mid-incident: adds risk, rarely speeds recovery
Rolling back and rolling forward in the same window: give one change time to prove itself
Declaring victory too early: five calm minutes isn't a stable system
Skipping the change freeze: uncoordinated fixes are how you get two incidents instead of one

Stabilize first. Root-cause after. Every time.

Full original write-up with more context: binadit.com

Originally published on binadit.com

From 4.2s to 380ms: debugging latency in a high availability infrastructure setup

binadit — Fri, 11 Sep 2026 07:05:45 +0000

Five silent bottlenecks that turned a 400ms API into a 4.2s crawl

No deploys. No schema changes. No new integrations. Just a scheduling and resource-planning SaaS with 40k users watching its p95 response time climb from 400ms to 4.2 seconds over six months. Nobody could point to a cause, because there wasn't one big cause, there were five small ones stacked on top of each other.

This is the writeup of how we found and fixed them, without a rearchitecture.

The symptoms before the numbers existed

Support tickets called the dashboard "laggy" long before anyone had hard metrics. By the time it got measured:

p95 latency: 400ms to 4.2s over ~6 months
Trial-to-paid conversion down 11% in the same window
Sales getting asked about performance during renewals

The team had already tried the usual moves: bigger instances, a read replica, scheduled restarts. None of it held. When scaling vertically twice does nothing, that's a strong signal the problem is architectural, not capacity.

Step one: measure before touching anything

We spent the first week purely on instrumentation, tracing requests across the API gateway, app servers, database, and cache layer under normal load. No fixes yet. Changing the system while you're trying to measure it just adds noise.

Five issues surfaced. None of them alone explained 4.2 seconds, but together they did.

The five issues

1. N+1 queries in a hot path

A dashboard endpoint fetched a customer's project list, then hit the DB once per project for status. 40 projects meant 41 round trips for one page load.

2. Connection pool exhaustion

8 app servers x 20 connections each = 160 possible connections, against a Postgres max_connections of 100. At peak, requests queued for a connection slot before a query even ran.

3. Cache invalidation nuking whole namespaces

Redis had a 30s TTL on project status, reasonable on paper. But a background job flushed entire cache namespaces on any write, including unrelated ones. Actual hit ratio: 34%.

4. Cross-AZ chatter

App tier and Redis cluster weren't pinned to the same AZ. ~40% of Redis calls crossed zones, adding 2 to 4ms each. At volume, that's hundreds of milliseconds per request.

5. A synchronous third-party call in the request path

A usage-tracking webhook to an external analytics provider ran synchronously inside the request cycle. On a bad day that provider took 800ms to 1.5s, and every request waited on it.

How we prioritized fixes

Impact vs. risk, not ease of implementation:

Sync third-party call, high impact, low risk
N+1 queries, high impact, low risk
Connection pool exhaustion, high impact, medium risk
Cache invalidation, medium impact, medium risk
Cross-AZ placement, medium impact, low risk

We explicitly skipped touching instance sizes again. Two rounds of vertical scaling with zero improvement was itself the data point: the bottleneck was I/O and architecture, not compute.

We also shipped fixes one at a time, measuring after each. Bundling everything into one release makes it impossible to know what actually helped, or what quietly broke something else.

The fixes

Move the analytics call off the request path

// before: synchronous call blocking the response
await analyticsClient.track(event); // 800ms-1.5s on slow days
return response;

// after: fire-and-forget via queue
await queue.push('analytics.track', event); // ~2ms
return response;

Used the existing Redis infra as the queue backend, no new dependency. A worker process handles delivery with retries and a dead-letter queue. This alone cut 800ms to 1.5s off the median request on affected endpoints, and when the analytics provider had two outages during the engagement, users never noticed.

Kill the N+1

-- before
SELECT * FROM projects WHERE account_id = $1;
-- then per project:
SELECT * FROM project_status WHERE project_id = $1;

-- after
SELECT p.*, s.status, s.updated_at
FROM projects p
JOIN project_status s ON s.project_id = p.id
WHERE p.account_id = $1;

41 round trips became 1. Query time for that endpoint went from ~620ms to ~45ms average.

Retune the connection pool

Dropped per-server pool size from 20 to 12 (8 x 12 = 96, under the 100 limit) and added PgBouncer in transaction pooling mode:

[databases]
app_db = host=127.0.0.1 port=5432 dbname=app_production

[pgbouncer]
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25
reserve_pool_size = 5
reserve_pool_timeout = 3

Connection wait time went from ~180ms average at peak to under 5ms.

Fix cache invalidation

Switched from namespace-wide flushes on any write to key-level invalidation tied to the specific project changed. Kept the 30s TTL as a safety net, but it stopped being the primary mechanism.

Cache hit ratio: 34% to 91% within a week. Small diff, outsized effect on database load.

Takeaway

None of these fixes were exotic. This is what accumulated technical debt looks like in a system that grew for a few years without a dedicated performance pass. If your latency crept up gradually with no single obvious cause, look for a stack of small architectural issues before you reach for bigger hardware.

Full writeup with more detail: Debugging latency in a high availability infrastructure setup

Originally published on binadit.com

How Docker networking broke checkout under load: a container ecommerce infrastructure case study

binadit — Wed, 09 Sep 2026 07:02:54 +0000

Checkout was timing out at 900 req/s, and it had nothing to do with CPU

A marketplace client came to us with a scary but familiar symptom: checkout p95 latency jumping from 280ms to over 2.1 seconds during traffic spikes. Their instinct was to throw more containers at it. That made things worse. Here's what was actually going on, and how we fixed it without touching a line of application code.

Link to the full writeup: Docker networking broke checkout under load

The setup

PHP monolith, containerized about a year prior, running on a single host via Docker Compose: app containers, Redis, a worker queue, behind a managed load balancer. 40k DAU, peak ~900 req/s. It ran fine for six months. Then flash sales started producing "the site is freezing" tickets.

The team's first move was scaling app containers, assuming CPU/memory pressure. Query times on Postgres stayed stable at 8-14ms the whole time, so the database wasn't the culprit either. The bottleneck was hiding in the network layer between containers, a place default tooling barely gives you visibility into.

What the audit found

Three compounding issues, none fatal alone:

1. Default bridge network overhead. Every inter-container hop (app to Redis, app to Postgres, app to search) was going through userland proxying on the default bridge. We measured ~1.8ms added latency per hop. At 900 req/s with 3-4 internal calls per request, that adds up fast.

2. Conntrack table exhaustion. nf_conntrack_max was still at the kernel default of 65,536. Short-lived Redis/Postgres connections churned through the table during spikes, filled it, and the kernel silently started dropping packets. Nobody noticed because syslog wasn't shipped anywhere useful.

3. DNS resolution overhead. Docker's embedded DNS (127.0.0.11) was resolving service names on every new connection instead of the app caching results. Under load, with connection churn, lookups started queuing behind each other.

None of these show up with 10 test users in staging. All three show up hard with 900 real ones under concurrent load.

What we didn't do

We ruled out "just move to Kubernetes." It wouldn't have fixed anything here; K8s has its own version of the same problems (CNI choice, kube-proxy mode, CoreDNS caching). Swapping orchestrators without fixing the root cause just relocates it.

We also ruled out rewriting the app to reduce internal calls. The call pattern was normal. The network layer needed to handle it efficiently, not the other way around.

The fix, in four layers

Kernel tuning for conntrack:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 4096

Applied via /etc/sysctl.d/99-docker-network.conf and sysctl --system. We also started monitoring conntrack table utilization going forward, since a full table fails silently.

Moved internal traffic off the default bridge:

docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_icc=true \
  --opt com.docker.network.driver.mtu=9000 \
  --subnet 172.28.0.0/16 \
  internal-services

App containers, Redis, and the search sidecar moved onto this network, keeping east-west traffic off Docker's default NAT path. The public-facing load balancer stayed on a separate network; no change to external attack surface.

Local DNS caching with dnsmasq as a sidecar:

# dnsmasq.conf
no-resolv
server=127.0.0.11
cache-size=1000
local-ttl=10
neg-ttl=5

A 10-second TTL absorbed connection churn during spikes without causing stale resolution issues when containers got replaced on deploy. We specifically tested that a container restart got picked up within one TTL window.

PgBouncer for connection pooling:

[databases]
marketplace = host=postgres-primary port=5432 dbname=marketplace

[pgbouncer]
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 50

This was sequenced last on purpose. Fewer short-lived connections means fewer conntrack entries and fewer DNS lookups, so it made everything upstream easier once the network layer was already sound.

Takeaway

If your containerized app slows down only under load and CPU/memory graphs look fine, stop scaling containers and go look at conntrack, your bridge driver, and DNS resolution behavior. That's usually where it's actually hiding.

Originally published on binadit.com

Solving the real ROI question behind moving off US hyperscalers

binadit — Wed, 02 Sep 2026 07:23:04 +0000

Why your hyperscaler exit math keeps failing finance review

You run the numbers on leaving AWS. Compute is cheaper elsewhere. Storage is cheaper elsewhere. Then finance asks about egress fees, migration hours, and cutover risk, and the whole business case falls apart. Sound familiar? This isn't a bad migration plan, it's a broken cost model.

Most engineers comparing hyperscaler costs against alternatives only look at list prices for compute and storage. That's maybe 40% of the real picture. Here's the rest of it, and a framework to fix your ROI math.

Why the comparison breaks down

Hyperscalers don't really compete on compute price. They compete on making it painful to leave. That's baked into the architecture, not just the contract.

Egress fees are the real anchor. AWS charges roughly $0.09/GB after the first GB out. For a platform pushing 50TB/month (video, API responses, backups, CDN pulls), that's about $4,500/month just to move data, before touching anything else. This fee isn't about bandwidth cost, bandwidth is cheap. It's a moat.

Managed services lock you in harder than compute does. If you're on RDS, DynamoDB, SQS, and Lambda, you're not renting VMs, you're depending on proprietary APIs. Migrating off means rewriting your data access layer, not just moving instances. This is the line item most spreadsheets underestimate by 3-5x.

Reserved instance pricing hides a bad assumption. Finance often compares a competitor's list price to a hyperscaler's 3-year reserved rate and calls it a win for the hyperscaler. But that rate assumes flat usage for 36 months. Most SaaS workloads have seasonal spikes and growth curves. A 3-year commitment is a liability wearing a discount's clothes.

Support cost is invisible until you actually need it. A named TAM tier starts around $15,000/month, and you're still in a ticket queue for anything real. Compare that to a partner where a senior engineer just picks up.

The fix: five cost categories, not one

1. Baseline 12 months of actual spend, not one month

aws ce get-cost-and-usage \
  --time-period Start=2024-11-01,End=2025-11-01 \
  --granularity MONTHLY \
  --metrics 'UnblendedCost' \
  --group-by Type=DIMENSION,Key=SERVICE

Break it into compute, storage, egress, managed services, support, and RI amortization. Egress alone is usually 8-15% of total spend for content-heavy platforms, and it almost never makes the first draft of a migration business case.

2. Model the actual migration cost

This means:

Engineering hours to replace managed-service dependencies (DynamoDB to Postgres, Lambda to containers, SQS to self-hosted queues)
One-time data transfer cost to move the dataset out
Parallel-run cost during validation (typically 4-8 weeks)
A downtime contingency line, even with a zero-downtime plan

For a mid-sized SaaS app with a 2TB database and 15 microservices, expect 200-450 engineering hours. At 80 euros/hour loaded cost, that's 16,000-36,000 euros, upfront. Put it in the model.

3. Recalculate egress under the new architecture

# AWS us-east-1 to internet: $0.09/GB after first 1GB free
# EU provider with peering to major IXPs: $0.01-0.02/GB typical

# 50TB/month egress:
# AWS: 50,000GB * $0.09 = $4,500/month
# EU provider: 50,000GB * $0.015 = $750/month
# Annual difference: $45,000

Colocate with your CDN's regional PoPs and egress typically drops 40-70%.

4. Swap proprietary APIs for open standards

This is the highest-leverage move in the whole exit. It's what makes the savings durable instead of a one-time discount you slowly erode by re-adopting vendor tooling:

DynamoDB → PostgreSQL or self-managed MongoDB
Lambda → containers on Kubernetes or Nomad
SQS/SNS → self-hosted RabbitMQ or Kafka
CloudWatch → Prometheus + Grafana

5. Cut over with zero downtime

Replicate continuously, run both environments in parallel, lower DNS TTL ahead of time, keep the old environment warm for at least one billing cycle.

# 48-72 hours before cutover
example.com.  300  IN  A  203.0.113.10

# Monitor both origins during cutover
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://old-origin.example.com/health
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://new-origin.example.com/health

For database-backed apps, run logical replication for days beforehand, not a single export/import window.

How to know it actually worked

Track these for at least two full billing cycles:

Total spend vs. your 12-month baseline, normalized for traffic growth
Egress as % of total spend (expect 8-15% → 2-4% with good peering)
p95/p99 latency on your top 10 endpoints, before and after
Error rate and uptime, 30 days before vs. 30 days after
Engineering hours on infra ops per month

One sanity check that matters: if spend drops 30% but p99 latency degrades 25%, you haven't won anything. You've just shifted cost into a metric that'll eventually cost you conversions.

Full framework and migration mechanics in the original piece: Solving the real ROI question behind moving off US hyperscalers

Originally published on binadit.com