2025-12-10 00:03:05
This article is part of a larger editorial journey that blends myth, stewardship, and resilience. In the Myth‑Tech series, folklore becomes a lens for digital literacy—turning tricksters and archetypes into cues for safe behavior. In the Wisdom Circle, psalms and practical guidance empower elders with emotional and technical defenses. In the sector‑specific cyber playbooks, operators gain actionable escalation criteria and preparedness scaffolds for power and water utilities. EIOC Guard™ extends this legacy by introducing Emotional Indicators of Compromise—a framework that treats human emotions as exploitable vectors and equips employees with Stewardship Cues™ to resist manipulation in real time. Together, these artifacts form a continuum: mythic motifs, cultural resilience, and technical playbooks converging into a unified editorial legacy of empowerment.
Most security awareness training tells employees: “Don’t click suspicious links.” But attackers aren’t just exploiting technical flaws—they’re exploiting human emotions. Fear, urgency, trust, and authority can bypass rational defenses faster than any malware.
That’s where EIOC Guard™ comes in. Built and deployed via GitHub Pages, it reframes awareness training around Emotional Indicators of Compromise (EIOCs)—psychological signals that manipulation is in progress.
Just as technical Indicators of Compromise (IOCs) flag system intrusion, EIOCs flag emotional intrusion.
EIOC Guard™ provides:
| EIOC Category | Technical Mapping | Stewardship Cue™ |
|---|---|---|
| Prestige Mirage | Status-Based Exploit | "Signal is earned, not borrowed." |
| Familiarity Shortcut | Implicit Trust Injection | "Pause before you mirror." |
| Performance Reflex | Urgency Trigger Exploit | "Urgency is not a credential." |
| Empathic Camouflage | Affinity Bias Pretexting | "Familiar warmth may conceal cold intent." |
| Deference Drift | Authority Spoof Lever | "Stewardship honors questions." |
One of the most powerful aspects of this project is its open-source deployment pipeline:
README.md – Overview and training philosophy
IP-DOCUMENTATION.md – Intellectual property timeline and proof
eioc-guard-public.html – Assessment tool interface
linkedin-eioc-post-2025-10-09.png – Public disclosure artifact
This setup makes EIOC Guard™ accessible to SMBs, MSPs, and enterprise teams without requiring enterprise-scale infrastructure.
Security awareness must evolve. Attackers are no longer just exploiting code—they’re exploiting human psychology. By recognizing Emotional Indicators of Compromise, employees gain the literacy to defend themselves against manipulation in real time.
EIOC Guard™ is more than training—it’s a cultural shift toward resilience.
🔗 Try the assessment: EIOC Guard
📂 View the repo: GitHub
2025-12-10 00:02:06
You've built your Next.js application using the App Router, deployed it to production, and moved on to the next feature. Then December 4th happened. Public exploits dropped for React2Shell—a critical remote code execution vulnerability affecting React Server Components—and within hours, state-sponsored threat actors were actively targeting vulnerable applications. If your production Next.js app is running versions 15.0.0 through 16.0.6, you may already be compromised.
This isn't hyperbole. CVE-2025-55182 carries the maximum CVSS score of 10.0, requires no authentication, and can be triggered with a single HTTP request against default Next.js configurations. Security researchers report near-100% exploitation success rates, and cloud security vendors have observed cryptomining campaigns, credential harvesting, and persistent backdoors deployed through this vulnerability within days of public disclosure.
Let's walk through what's happening under the hood, how to determine if you're affected, and the immediate steps you need to take to secure your applications.
React Server Components introduced a communication protocol called "Flight" that handles serialization and deserialization between server and client. When your Next.js application processes form submissions or server function calls, it uses this protocol to decode incoming payloads. The vulnerability lies in how React's deserialization logic handles malformed payloads—specifically, how it traverses prototype chains when resolving references.
The technical mechanism involves manipulating special chunk references in multipart form data. React's Flight protocol uses $-prefixed strings to trigger specific behaviors and resolve references. By crafting payloads with carefully constructed __proto__, constructor, and prototype references, attackers can escape the intended object boundaries and execute arbitrary JavaScript on your server.
What makes this particularly severe is the default exposure. A standard project generated with create-next-app using the recommended settings enables the App Router, which includes React Server Components and exposes the vulnerable endpoints—even if your application doesn't explicitly use server functions. The mere presence of RSC support creates the attack surface.
Here's what the attack flow looks like:
Attacker crafts malicious multipart/form-data POST request
↓
Request reaches Next.js server with RSC-enabled route
↓
Flight protocol deserializes payload
↓
Prototype chain traversal triggers arbitrary code execution
↓
Attacker has server-side RCE with application privileges
From that initial foothold, attackers have been observed exfiltrating environment variables (including database credentials and API keys), dropping cryptominers, establishing reverse shells, and deploying persistent backdoors.
The vulnerability affects these specific packages and versions:
React packages (CVE-2025-55182):
react-server-dom-webpack: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0react-server-dom-parcel: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0react-server-dom-turbopack: versions 19.0.0, 19.1.0, 19.1.1, 19.2.0Next.js (tracked as GHSA-9qr9-h5gf-34mp):
Other affected frameworks using React Server Components:
react-router (with unstable RSC APIs)waku@parcel/rsc@vitejs/plugin-rscrwsdkTo quickly check your deployed version, open your browser's developer console on any page of your application and run:
// Returns your deployed Next.js version
next.version
Or check your package.json and lockfile:
# Check package.json
cat package.json | grep '"next"'
# Check actual resolved version in lockfile
npm ls next
# or
yarn why next
# or
pnpm why next
Vercel users should see a dashboard banner if production deployments are running vulnerable versions. However, don't rely solely on this—verify your versions directly.
Important: Applications are vulnerable even if they don't explicitly use server functions, as long as they support React Server Components. If your Next.js app uses the App Router (has an app/ directory), you should assume vulnerability unless you're running a patched version.
Reference this table to find your specific patched version:
| Currently Running | Upgrade To |
|---|---|
| Next.js 15.0.x | 15.0.5 |
| Next.js 15.1.x | 15.1.9 |
| Next.js 15.2.x | 15.2.6 |
| Next.js 15.3.x | 15.3.6 |
| Next.js 15.4.x | 15.4.8 |
| Next.js 15.5.x | 15.5.7 |
| Next.js 16.0.x | 16.0.7 |
| Next.js 14 canaries (≥14.3.0-canary.77) | Downgrade to 14.2.x stable |
| Next.js 15 canaries (<15.6.0-canary.58) | 15.6.0-canary.58 or later |
Vercel has released an automated fix utility. In your project root:
npx fix-react2shell-next
This scans your project for vulnerable packages and upgrades them to patched versions. For manual upgrades:
# Update package.json to patched version
npm install [email protected] # Replace with your target version
# Ensure lockfile is updated
npm install
# Verify the update
npm ls next
Critical: Always commit lockfile changes with package.json changes. Mismatched lockfiles are a common source of failed patches.
Once tested locally, deploy without delay:
# Vercel CLI
vercel --prod
# Or push to trigger CI/CD
git add package.json package-lock.json
git commit -m "fix: patch React2Shell vulnerability (CVE-2025-55182)"
git push origin main
This is the step teams often skip—don't. If your application was publicly accessible and unpatched as of December 4th, 2025 at 1:00 PM PT (when public exploits emerged), assume your environment variables have been compromised. Rotate in priority order:
For Vercel deployments, their documentation on rotating secrets provides a systematic approach. The process involves generating new credentials in each service, updating your Vercel environment variables, redeploying, and then invalidating the old credentials.
Determining whether your application was exploited isn't straightforward. However, several indicators warrant investigation:
Log analysis: Review application logs for unusual POST requests, particularly to routes you didn't explicitly configure. Look for:
Runtime anomalies:
Common post-exploitation behaviors observed in the wild:
systemd-devd)If you identify suspicious activity, treat it as a confirmed breach: isolate affected systems, preserve logs for forensic analysis, and engage your incident response procedures.
While patching is the only complete fix, layered defenses provide breathing room:
Web Application Firewall rules: Major WAF providers have deployed rules targeting known exploit patterns. Vercel applied WAF mitigations globally prior to public disclosure, AWS WAF's AWSManagedRulesKnownBadInputsRuleSet includes CVE-2025-55182 rules, and Cloudflare, Fastly, and other providers have similar protections. Note that WAF rules cannot guarantee protection against all variants—they're a stopgap, not a solution.
Deployment protection: Enable authentication for non-production deployments. In Vercel, Standard Protection prevents unauthorized access to preview deployments. Audit any shareable links that bypass deployment protection.
Network segmentation: Limit outbound connectivity from application containers where possible. This constrains an attacker's ability to exfiltrate data or establish command-and-control channels even if they achieve code execution.
Metadata service hardening: If running in cloud environments, restrict access to instance metadata services. Use IMDSv2 (AWS), or equivalent protections on other platforms.
This vulnerability reveals a fundamental challenge with server-side JavaScript deserialization. The Flight protocol's complexity created opportunities for prototype pollution attacks—a class of vulnerability that's notoriously difficult to eliminate entirely in JavaScript. The React team deserves credit for rapid response (patch within days of responsible disclosure), but this incident raises questions for teams evaluating RSC adoption.
For existing Next.js applications: the App Router and React Server Components remain powerful tools for building performant applications. The patched versions address the specific deserialization flaw. Continue using RSC with confidence once you've upgraded.
For teams evaluating new projects: this vulnerability shouldn't dissuade you from React Server Components, but it's a reminder that server-side rendering introduces server-side risks. Factor security monitoring and update procedures into your architecture planning.
For those still on Next.js 14 stable (Pages Router only): you're not affected by this specific vulnerability, but you're also not receiving active feature development. Plan your migration path deliberately rather than reactively.
fix-react2shell-next CLI toolImmediate (today): Verify all production Next.js applications are running patched versions. Deploy fixes for any that aren't.
This week: Rotate secrets for any application that may have been exposed. Review logs for indicators of compromise.
This month: Audit deployment protection settings. Ensure preview and staging environments aren't publicly accessible without authentication.
Ongoing: Establish a security update process. This won't be the last critical framework vulnerability, and response time matters.
The React and Vercel teams handled disclosure and patching responsibly, but the rapid weaponization—with state-sponsored actors exploiting the vulnerability within hours—demonstrates the compressed timelines security teams now face. Building security responsiveness into your development workflow isn't optional anymore.
2025-12-10 00:00:39
This is the second exercise in the "AWS CDK 100 Drill Exercises" series.
For more about AWS CDK 100 Drill Exercises, see this introduction article.
After learning S3 fundamentals in the first exercise, we now dive into AWS Identity and Access Management (IAM). IAM is the foundation of AWS security, controlling who can access your resources and what they can do with them.
📁 Code Repository: All code examples for this exercise are available on GitHub.
Here's what we'll build in this exercise:
We'll implement six different patterns across four constructs:
To follow along, you'll need:
npm install -g aws-cdk)iam-basics/
├── bin/
│ └── iam-basics.ts # Application entry point
├── lib/
│ ├── stacks/
│ │ └── iam-basics-stack.ts # Main stack definition
│ └── constructs/
│ ├── iam-user-with-password.ts # Patterns 2-3
│ ├── iam-user-with-group.ts # Pattern 4
│ └── iam-user-with-switch-role.ts # Pattern 5
├── test/
│ ├── compliance/
│ │ └── cdk-nag.test.ts # Testing (explained in later exercises)
│ ├── snapshot/
│ │ └── snapshot.test.ts # Testing (explained in later exercises)
│ └── unit/
│ └── iam-basics.test.ts # Testing (explained in later exercises)
├── cdk.json
├── package.json
└── tsconfig.json
Let's start with the simplest IAM user creation. This is all you need to create an IAM user.
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as iam from 'aws-cdk-lib/aws-iam';
export class IamBasicsStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Minimal IAM user configuration
const cdkDefaultUser = new iam.User(this, 'CDKDefaultUser', {});
}
}
Generated CloudFormation:
{
"Resources": {
"CDKDefaultUserF7AAA71A": {
"Type": "AWS::IAM::User",
"Metadata": {
"aws:cdk:path": "Dev/DrillexercisesIamBasics/CDKDefaultUser/Resource"
}
}
}
}
Let's examine what CDK automatically configures:
Until you explicitly grant permissions, this user cannot access anything.
⚠️ This pattern demonstrates what happens when you use it in production environments.
Note that "PasswordResetRequired": true is set, but the user cannot change the password because they lack permissions.
To allow password changes, you need the IAMUserChangePassword policy shown in [Pattern 2B].
Alternatively, you can configure your AWS account to allow all IAM users to change their own passwords. (See AWS Documentation)
const userWithPassword = new iam.User(this, 'PasswordUser', {
password: cdk.SecretValue.unsafePlainText('InitialPassword123!'),
passwordResetRequired: true,
});
Generated CloudFormation:
{
"UserWithPasswordPasswordUserA5E8EDB8": {
"Type": "AWS::IAM::User",
"Properties": {
"LoginProfile": {
"Password": "InitialPassword123!",
"PasswordResetRequired": true
}
}
}
}
Never use this pattern in production.
This is the secure way to manage IAM user passwords.
import * as secretsmanager from 'aws-cdk-lib/aws-secretsmanager';
const userName = 'SecretsPasswordUser';
// Create the secret with auto-generated password
const userSecret = new secretsmanager.Secret(this, 'UserSecret', {
generateSecretString: {
secretStringTemplate: JSON.stringify({ username: userName }),
generateStringKey: 'password',
excludePunctuation: true,
passwordLength: 16,
requireEachIncludedType: true,
},
});
// Create user with password from Secrets Manager
const user = new iam.User(this, 'SecretsPasswordUser', {
userName: userName,
password: userSecret.secretValueFromJson('password'),
passwordResetRequired: true,
});
// change password policy
userWithSecretsManager.addManagedPolicy(
iam.ManagedPolicy.fromAwsManagedPolicyName('IAMUserChangePassword')
);
// Grant the user permission to read their own password
userSecret.grantRead(user);
// Output the secret ARN for retrieval
new cdk.CfnOutput(this, 'SecretArn', {
value: userSecret.secretArn,
description: 'Retrieve password: aws secretsmanager get-secret-value --secret-id <this-arn>',
});
Generated CloudFormation:
{
"UserWithPasswordSecretsPasswordUserSecret32219BC7": {
"Type": "AWS::SecretsManager::Secret",
"Properties": {
"GenerateSecretString": {
"ExcludePunctuation": true,
"GenerateStringKey": "password",
"SecretStringTemplate": "{\"username\":\"SecretsPasswordUser\"}"
}
}
},
"UserWithPasswordSecretsPasswordUserCFEF7855": {
"Type": "AWS::IAM::User",
"Properties": {
"LoginProfile": {
"Password": {
"Fn::Join": [
"",
[
"{{resolve:secretsmanager:",
{"Ref": "UserWithPasswordSecretsPasswordUserSecret32219BC7"},
":SecretString:password::}}"
]
]
},
"PasswordResetRequired": true
},
"ManagedPolicyArns": [
{
"Fn::Join": [
"",
[
"arn:",
{
"Ref": "AWS::Partition"
},
":iam::aws:policy/IAMUserChangePassword"
]
]
}
],
"UserName": "SecretsPasswordUser"
}
},
"UserWithPasswordSecretsPasswordUserDefaultPolicy6A5FC9BF": {
"Type": "AWS::IAM::Policy",
"Properties": {
"PolicyDocument": {
"Statement": [
{
"Action": [
"secretsmanager:DescribeSecret",
"secretsmanager:GetSecretValue"
],
"Effect": "Allow",
"Resource": {
"Ref": "UserWithPasswordSecretsPasswordUserSecret32219BC7"
}
}
]
},
"Users": [
{"Ref": "UserWithPasswordSecretsPasswordUserCFEF7855"}
]
}
}
}
The most important part is this:
"Password": {
"Fn::Join": [
"",
[
"{{resolve:secretsmanager:",
{"Ref": "SecretId"},
":SecretString:password::}}"
]
]
}
CloudFormation uses {{resolve:secretsmanager:...}} to dynamically retrieve the password during stack deployment. The actual password never appears in the CloudFormation template.
generateSecretString: {
secretStringTemplate: JSON.stringify({ username: userName }),
generateStringKey: 'password',
excludePunctuation: true, // Avoid special characters that might cause issues
passwordLength: 16, // Strong password length
requireEachIncludedType: true, // Include uppercase, lowercase, numbers
}
userSecret.grantRead(user);
This grants only this specific user permission to read their own password secret. The generated policy includes:
secretsmanager:DescribeSecretsecretsmanager:GetSecretValueAfter deployment:
# Get the secret ARN from stack outputs
SECRET_ARN=$(aws cloudformation describe-stacks \
--stack-name YourStackName \
--query 'Stacks[0].Outputs[?OutputKey==`SecretArn`].OutputValue' \
--output text)
# Retrieve the password
aws secretsmanager get-secret-value --secret-id $SECRET_ARN \
--query SecretString --output text | jq -r '.password'
This pattern is implemented within the IAMUserWithPassword construct.
Two types of policies apply to users whose passwords are generated by Secrets Manager.
userWithPassword.addManagedPolicy(
iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess')
);
Generated CloudFormation:
{
"ManagedPolicyArns": [
{
"Fn::Join": [
"",
[
"arn:",
{"Ref": "AWS::Partition"},
":iam::aws:policy/ReadOnlyAccess"
]
]
}
]
}
Characteristics:
userWithPassword.addToPolicy(
new iam.PolicyStatement({
actions: ['s3:ListAllMyBuckets'],
resources: ['arn:aws:s3:::*'],
})
);
Generated CloudFormation:
{
"UserDefaultPolicy": {
"Type": "AWS::IAM::Policy",
"Properties": {
"PolicyDocument": {
"Statement": [
{
"Action": "s3:ListAllMyBuckets",
"Effect": "Allow",
"Resource": "arn:aws:s3:::*"
}
]
},
"Users": [
{"Ref": "User"}
]
}
}
}
Characteristics:
| Use Case | Managed Policy | Inline Policy |
|---|---|---|
| Common AWS permissions | ✅ | ❌ |
| Custom application-specific permissions | ❌ | ✅ |
| Shared across multiple entities | ✅ | ❌ |
| One-time, specific permissions | ❌ | ✅ |
| Frequently changing permissions | ❌ | ✅ |
Groups allow you to grant consistent permissions to multiple users.
This pattern is implemented in iam-user-with-group.ts.
// Create a group
const group = new iam.Group(this, 'IamGroup', {});
// Attach policy to group
group.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess'));
// Add user to group
user.addToGroup(group);
Generated CloudFormation:
{
"UserGroupIamGroupAB148728": {
"Type": "AWS::IAM::Group",
"Properties": {
"ManagedPolicyArns": [
{
"Fn::Join": [
"",
[
"arn:",
{
"Ref": "AWS::Partition"
},
":iam::aws:policy/ReadOnlyAccess"
]
]
}
]
},
"UserGroupUser5985318E": {
"Type": "AWS::IAM::User",
"Properties": {
"Groups": [
{
"Ref": "UserGroupIamGroupAB148728"
}
],
}
}
💡 Note: Advanced Pattern for Level 100
This pattern is implemented in iam-user-with-switch-role.ts.
This switch role pattern is slightly advanced for Level 100, but we include it here because:
This pattern implements a security best practice: requiring MFA for elevated permissions.
const accountId = cdk.Stack.of(this).account;
// Create IAM user
const switchRoleUser = new iam.User(this, 'SwitchRoleUser', {
userName: 'SwitchRoleUser',
password: userSecret.secretValueFromJson('password'),
passwordResetRequired: true,
});
// Create role with MFA requirement
const readOnlyRole = new iam.Role(this, 'ReadOnlyRole', {
assumedBy: new iam.PrincipalWithConditions(
new iam.AccountPrincipal(accountId),
{
Bool: { 'aws:MultiFactorAuthPresent': 'true' },
}
),
maxSessionDuration: cdk.Duration.hours(4),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess'),
],
});
// Create policy to allow assuming the role
const assumeRolePolicy = new iam.Policy(this, 'AssumeRolePolicy', {
statements: [
new iam.PolicyStatement({
actions: ['sts:AssumeRole'],
resources: [readOnlyRole.roleArn],
}),
],
});
// Create group and attach policy
const switchRoleGroup = new iam.Group(this, 'SwitchRoleGroup', {});
assumeRolePolicy.attachToGroup(switchRoleGroup);
// Add user to group
switchRoleUser.addToGroup(switchRoleGroup);
Generated CloudFormation:
{
"SwitchRoleUserReadOnlyRole660C7C3B": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [
{
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
},
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
}
}
]
},
"ManagedPolicyArns": [
{
"Fn::Join": [
"",
[
"arn:",
{"Ref": "AWS::Partition"},
":iam::aws:policy/ReadOnlyAccess"
]
]
}
],
"MaxSessionDuration": 14400
}
}
}
The key part is the condition:
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
This means:
AssumeRole API call will failsts:AssumeRole permission aws iam create-virtual-mfa-device \
--virtual-mfa-device-name SwitchRoleUser-MFA \
--outfile QRCode.png \
--bootstrap-method QRCodePNG
aws iam enable-mfa-device \
--user-name SwitchRoleUser \
--serial-number arn:aws:iam::123456789012:mfa/SwitchRoleUser-MFA \
--authentication-code1 123456 \
--authentication-code2 789012
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/ReadOnlyRole \
--role-session-name ReadOnlySession \
--serial-number arn:aws:iam::123456789012:mfa/SwitchRoleUser-MFA \
--token-code 123456
maxSessionDuration enforces automatic expiration# Check differences
cdk diff --project=sample --env=dev
# Deploy
cdk deploy "**" --project=sample --env=dev
# List all users
aws iam list-users
# Get specific user details
aws iam get-user --user-name SecretsPasswordUser
# List user policies
aws iam list-attached-user-policies --user-name PasswordUser
# List inline policies
aws iam list-user-policies --user-name PasswordUser
# Get secret value
aws secretsmanager get-secret-value \
--secret-id <secret-arn> \
--query SecretString \
--output text
# Assume role with MFA
aws sts assume-role \
--role-arn <role-arn> \
--role-session-name TestSession \
--serial-number <mfa-device-arn> \
--token-code <mfa-code>
# Delete stack
cdk destroy "**" --project=sample --env=dev
# Force deletion without confirmation
cdk destroy "**" --force --project=sample --env=dev
Important: IAM users and roles are retained by default. If you want to delete them, you need to manually remove them or set appropriate deletion policies.
In this exercise, we learned IAM fundamentals through AWS CDK.
{{resolve:secretsmanager:...}}
Next up: VPC Basics - Building secure network foundations!
Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!
2025-12-09 23:57:03
Welcome to this week's Top 7, where the DEV editorial team handpicks their favorite posts from the previous week.
Congrats to all the authors that made it onto the list 👏
@sylwia-lask challenges the myth of perfect codebases, arguing that messy production code is a shared reality rather than a personal failure. The author advocates for writing "survivable" code and prioritizing kindness to oneself over perfectionism.
@xwero explores the complexities of using non-English languages in programming, weighing the benefits of domain clarity against the friction of international collaboration. The post invites developers to consider when native language naming might actually improve code understanding for local teams.
@annu12340 details the process of recreating a MS Paint clone that integrates modern AI features like text-to-image generation. The author shares how an AI coding companion helped streamline the build, from retro UI design to implementing quirky "Clippy" personalities.
@nodefiend presents an architecture for financial reporting that forces Large Language Models to act as citation machines rather than calculators. By offloading all math to a deterministic server, the author demonstrates how to achieve 100% accuracy and eliminate numerical hallucinations.
@aaron_rose_0787cc8b4775a0 takes us on a deep dive into Python's super() function, revealing that it navigates the Method Resolution Order rather than just calling a parent class. Through clear examples, the author explains how to use cooperative multiple inheritance effectively while avoiding common pitfalls.
@shirmeirlador provides a comprehensive guide on fine-tuning the MedGemma model to classify medical images with high accuracy. The article covers essential technical details, such as using specific data types to prevent numerical instability during the training process.
@marcosomma questions the current hype around autonomous agents, arguing that prompt engineering alone is insufficient for reliable system control. The author proposes a more structured approach to AI orchestration that prioritizes explicit permissions and human oversight over blind trust.
And that's a wrap for this week's Top 7 roundup! 🎬 We hope you enjoyed this eclectic mix of insights, stories, and tips from our talented authors. Keep coding, keep learning, and stay tuned to DEV for more captivating content and make sure you’re opted in to our Weekly Newsletter 📩 for all the best articles, discussions, and updates.
2025-12-09 23:55:15
Designing a 911 dispatch and mass notification system is one of the most critical challenges in public safety technology. Lives depend on sub-second response times, accurate location data, and reliable communication across multiple channels. This comprehensive guide explores the architecture, technologies, and best practices for building a modern emergency dispatch system that can handle the demands of contemporary emergency response.
Unlike traditional notification systems, a 911 dispatch platform must integrate real-time mapping, unit tracking, critical infrastructure monitoring, and multi-agency coordination while maintaining absolute reliability.
Core Dispatch Capabilities:
Mass Notification Features:
Mapping & Location Intelligence:
Integration Requirements:
Performance:
Reliability:
Security & Compliance:
Latency Requirements:
┌─────────────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
├─────────────┬──────────────┬──────────────┬────────────────────┤
│ Dispatcher │ Mobile │ Citizen │ Admin │
│ Console │ Units │ Alert App │ Dashboard │
│ (Web) │ (iOS/And.) │ (Mobile) │ (Web) │
└──────┬──────┴──────┬───────┴──────┬───────┴─────┬──────────────┘
│ │ │ │
└─────────────┴──────────────┴─────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ API GATEWAY + LOAD BALANCER │
│ (Kong/AWS ALB with Auto-scaling) │
└──────────────────┬──────────────────────────┘
│
┌──────────────────┴───────────────────┐
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ CAD/DISPATCH │ │ NOTIFICATION │
│ SERVICE │ │ SERVICE │
│ │ │ │
│ - Incident Mgmt │ │ - Alert Creation │
│ - Unit Dispatch │ │ - Multi-channel │
│ - Status Updates │ │ - Targeting │
└────────┬─────────┘ └─────────┬────────┘
│ │
└──────────────┬──────────────────────┘
│
▼
┌─────────────────┐
│ EVENT STREAM │
│ (Kafka/AWS │
│ Kinesis) │
└────────┬────────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ MAPPING │ │ LOCATION │ │ WORKER │
│ SERVICE │ │ TRACKING │ │ POOL │
│ │ │ SERVICE │ │ │
│ - Real-time│ │ │ │ - Message │
│ layers │ │ - GPS │ │ Delivery │
│ - Routing │ │ - AVL │ │ - Retries │
│ - Geocode │ │ - Geofence │ │ - Status │
└────────────┘ └────────────┘ └────────────┘
│ │ │
└───────────────┼───────────────┘
│
┌───────────────┴───────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ DATABASES │ │ EXTERNAL │
│ │ │ SERVICES │
│ - PostgreSQL │ │ │
│ - TimescaleDB │ │ - Twilio (SMS) │
│ - MongoDB │ │ - SendGrid │
│ - Redis Cache │ │ - FCM/APNS │
│ │ │ - Mapbox/Esri │
└─────────────────┘ │ - Google Maps │
│ - Weather API │
└─────────────────┘
1. Esri ArcGIS for Public Safety
2. Mapbox
3. Google Maps Platform (Emergency Services)
// Real-time GPS position update flow
{
"unitId": "ENGINE-401",
"position": {
"lat": 41.8781,
"lng": -87.6298,
"accuracy": 5,
"heading": 175,
"speed": 35
},
"timestamp": "2024-12-09T14:23:45.123Z",
"status": "ENROUTE",
"incidentId": "INC-2024-123456",
"eta": 180 // seconds
}
Key Features to Implement:
Accurate address matching is life-critical in emergency services:
Best Practices:
Channel Priority Matrix:
| Alert Type | SMS | Voice | Push | Sirens | Digital Signs | |
|---|---|---|---|---|---|---|
| Tornado Warning | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| AMBER Alert | ✓ | ✗ | ✓ | ✓ | ✗ | ✓ |
| Evacuation Order | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Boil Water | ✓ | ✗ | ✓ | ✓ | ✗ | ✗ |
| Road Closure | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ |
// Example alert targeting configuration
{
"alertId": "ALERT-2024-789",
"type": "TORNADO_WARNING",
"priority": "CRITICAL",
"targeting": {
"method": "polygon",
"coordinates": [...], // GeoJSON polygon
"excludeZones": ["HOSPITAL-ZONE-1"], // Don't alert hospital patients
"includeTransient": true // Include people traveling through area
},
"channels": ["SMS", "VOICE", "PUSH", "SIRENS"],
"message": {
"en": "TORNADO WARNING: Take shelter immediately...",
"es": "ADVERTENCIA DE TORNADO: Busque refugio inmediatamente..."
},
"expiresAt": "2024-12-09T16:00:00Z"
}
Rate Limiting Strategy:
Provider Redundancy:
Primary SMS: Twilio
Failover SMS: Bandwidth
Emergency Backup: AWS SNS
Primary Voice: Twilio Voice
Failover: RingCentral Emergency
Primary Language: Java or Python
Alternative: Node.js with TypeScript
WebSockets: Socket.io or native WebSocket
Server-Sent Events (SSE): For one-way map updates
Apache Kafka: Best for high-throughput scenarios
RabbitMQ: Good for priority queuing
PostgreSQL with PostGIS:
TimescaleDB:
Redis:
MongoDB:
Multi-Region Setup:
Primary Region: us-east-1 (N. Virginia)
Secondary Region: us-west-2 (Oregon)
DR Region: eu-west-1 (Ireland)
Data Replication: Synchronous to secondary, Async to DR
Failover Time: < 5 seconds automated
Kubernetes for Container Orchestration:
✅ Advanced authentication (MFA required)
✅ Encryption at rest (AES-256)
✅ Encryption in transit (TLS 1.3)
✅ Audit logging of all access
✅ Physical security controls for data centers
✅ Background checks for personnel
✅ Annual security training
✅ Incident response plan
1. User enters credentials
2. LDAP/Active Directory authentication
3. MFA challenge (TOTP or hardware token)
4. Role-based access token issued (JWT)
5. Session monitoring for anomalous behavior
6. Auto-logout after 15 minutes inactivity
7. All actions logged with user ID and timestamp
System Health:
Business Metrics:
Alerting Thresholds:
critical:
- incident_creation_time > 1000ms for 1 minute
- alert_failure_rate > 5% for 2 minutes
- websocket_disconnections > 10 in 1 minute
- database_connection_errors > 0
warning:
- api_latency_p95 > 500ms for 5 minutes
- queue_depth > 10000 messages
- cache_hit_rate < 80%
┌─────────────────────────────────────┐
│ Load Balancer (Route 53) │
└───────┬────────────────┬────────────┘
│ │
▼ ▼
┌────────┐ ┌────────┐
│ BLUE │ │ GREEN │
│ (Live) │ │ (New) │
└────────┘ └────────┘
│ │
▼ ▼
[Testing] [Deploy New Version]
│ │
└────[Switch]────┘
Traffic
Scenario 1: Data Center Failure
Scenario 2: Critical Bug in Production
Scenario 3: Natural Disaster
Potential Applications:
⚠️ Critical Considerations on AI in Emergency Services
While AI shows promise in certain areas, I personally advocate for extreme caution when deploying AI in emergency response systems, particularly for call handling and automated message generation. Here's why:
Cons of AI Automation in Emergency Response:
Life-or-Death Decisions Require Human Judgment: Emergency calls often involve nuanced situations where context, emotion, and intuition are critical. AI cannot reliably assess panic in a caller's voice, understand cultural context, or make split-second ethical decisions.
No Room for Hallucinations: AI models can "hallucinate" or provide incorrect information. In emergencies, a single wrong address, misjudged priority level, or misunderstood instruction could be fatal.
Lack of Accountability: When AI makes a mistake in an emergency, who is responsible? The algorithm? The vendor? The dispatcher? This legal and ethical gray area is unacceptable when lives are at stake.
Loss of Human Connection: In crisis situations, people need empathy, reassurance, and the confidence that another human being understands their emergency and is taking action.
Adversarial Scenarios: Malicious actors could potentially manipulate AI systems through carefully crafted inputs, creating false emergencies or preventing real ones from being properly handled.
Technical Failures: AI systems require constant connectivity, computing resources, and maintenance. In disaster scenarios when systems are stressed or degraded, simple rule-based systems are more reliable than complex AI models.
My Recommendation: Human-in-the-Loop AI Only
AI should only be used in emergency services where:
Acceptable AI Use Cases:
Unacceptable AI Use Cases:
The bottom line: In emergency services, AI should augment human decision-making, never replace it. The stakes are too high for anything less than human judgment, accountability, and compassion.
Building a 911 dispatch and mass notification system is one of the most challenging and rewarding engineering projects. The stakes are impossibly high—every millisecond matters, every notification delivered could save a life.
The key principles to remember are reliability over features, simplicity over cleverness, and human factors over technical elegance. Test relentlessly, monitor obsessively, and never stop improving. When your system works perfectly, you save lives. When it fails, the consequences are unthinkable.
Start with a solid foundation, build in redundancy at every layer, choose proven technologies over trendy ones, and always remember: you're building infrastructure that communities depend on in their darkest moments.
Standards & Specifications:
Open Source Projects:
Commercial Platforms:
APIs & Services:
Have you worked on emergency services systems? What challenges did you face? Share your experiences in the comments below!
If you found this helpful, follow me for more system design deep dives on critical infrastructure.
2025-12-09 23:54:05
Imagine you run two identical kitchens: Blue and Green. One serves customers, the other is warmed up and ready. If the active kitchen has trouble, you quietly switch orders to the standby and nobody notices. That’s Blue/Green. In this post we’ll build it ourselves, line by line, with Nginx doing the instant handoff—no prior code or prebuilt images required.
/healthz, /version, and chaos endpoints so we can test.Let’s start with nothing and build every file ourselves. Copy/paste is fine—understanding why each piece exists is the real goal.
This defines our minimal Node app and its dependencies.
cat > package.json <<'EOF'
{
"name": "blue-green-app",
"version": "1.0.0",
"main": "app.js",
"license": "MIT",
"scripts": {
"start": "node app.js"
},
"dependencies": {
"express": "^4.18.2"
}
}
EOF
This tiny server:
/healthz so Nginx can decide if we’re alive./version with headers that tell us which pool handled the request.cat > app.js <<'EOF'
const express = require('express');
const app = express();
const APP_POOL = process.env.APP_POOL || 'unknown';
const RELEASE_ID = process.env.RELEASE_ID || 'unknown';
const PORT = process.env.PORT || 3000;
let chaosMode = false;
let chaosType = 'error'; // 'error' or 'timeout'
// Add headers for tracing
app.use((req, res, next) => {
res.setHeader('X-App-Pool', APP_POOL);
res.setHeader('X-Release-Id', RELEASE_ID);
next();
});
app.get('/', (req, res) => {
res.json({
service: 'Blue/Green Demo',
pool: APP_POOL,
releaseId: RELEASE_ID,
status: chaosMode ? 'chaos' : 'healthy',
chaosMode,
chaosType: chaosMode ? chaosType : null,
timestamp: new Date().toISOString(),
endpoints: { version: '/version', health: '/healthz', chaos: '/chaos/start, /chaos/stop' }
});
});
app.get('/healthz', (req, res) => {
res.status(200).json({ status: 'healthy', pool: APP_POOL });
});
app.get('/version', (req, res) => {
if (chaosMode && chaosType === 'error') return res.status(500).json({ error: 'Chaos: server error' });
if (chaosMode && chaosType === 'timeout') return; // simulate hang
res.json({ version: '1.0.0', pool: APP_POOL, releaseId: RELEASE_ID, timestamp: new Date().toISOString() });
});
app.post('/chaos/start', (req, res) => {
const mode = req.query.mode || 'error';
chaosMode = true;
chaosType = mode;
res.json({ message: 'Chaos started', mode, pool: APP_POOL });
});
app.post('/chaos/stop', (req, res) => {
chaosMode = false;
chaosType = 'error';
res.json({ message: 'Chaos stopped', pool: APP_POOL });
});
app.listen(PORT, '0.0.0.0', () => {
console.log(`App (${APP_POOL}) listening on ${PORT}`);
console.log(`Release ID: ${RELEASE_ID}`);
});
EOF
We’ll build the same image for Blue and Green; only the environment variables differ.
cat > Dockerfile <<'EOF'
FROM node:18-alpine
WORKDIR /app
# Install dependencies
COPY package*.json ./
RUN npm install --only=production
# Copy app code
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
EOF
Nginx is our traffic director. We template it so a single env var (ACTIVE_POOL) chooses who is primary. Create nginx.conf.template:
cat > nginx.conf.template <<'EOF'
events {
worker_connections 1024;
}
http {
# Structured JSON access logs
log_format custom_json '{"time":"$time_iso8601"'
',"remote_addr":"$remote_addr"'
',"method":"$request_method"'
',"uri":"$request_uri"'
',"status":$status'
',"bytes_sent":$bytes_sent'
',"request_time":$request_time'
',"upstream_response_time":"$upstream_response_time"'
',"upstream_status":"$upstream_status"'
',"upstream_addr":"$upstream_addr"'
',"pool":"$sent_http_x_app_pool"'
',"release":"$sent_http_x_release_id"}';
upstream blue_pool {
server app-blue:3000 max_fails=1 fail_timeout=3s;
server app-green:3000 backup;
}
upstream green_pool {
server app-green:3000 max_fails=1 fail_timeout=3s;
server app-blue:3000 backup;
}
server {
listen 80;
server_name localhost;
# Write JSON logs (shared volume)
access_log /var/log/nginx/access.json custom_json;
# Health check for LB
location /healthz {
access_log off;
return 200 "healthy\n";
add_header Content-Type text/plain;
}
location / {
proxy_pass http://$UPSTREAM_POOL;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 1s;
proxy_send_timeout 3s;
proxy_read_timeout 3s;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_next_upstream_timeout 10s;
proxy_pass_request_headers on;
proxy_hide_header X-Powered-By;
}
}
}
EOF
Why these settings? (plain English)
max_fails=1 fail_timeout=3s: one bad request is enough to say “try the other one” for a few seconds.proxy_next_upstream + retries: if the main one errors or stalls, immediately try the backup within ~10s total.What just happened? Nginx knows who’s main, who’s backup, and to give up quickly on a slow/broken main.
Think of this as a friendly pager: it reads Nginx’s JSON logs and pings Slack when failover happens or errors spike. If you don’t want alerts, you can skip this section and remove the watcher service later.
requirements.txt:
cat > requirements.txt <<'EOF'
requests==2.32.3
EOF
watcher.py:
cat > watcher.py <<'EOF'
import json, os, time, requests
from collections import deque
from datetime import datetime, timezone
LOG_PATH = os.environ.get("NGINX_LOG_FILE", "/var/log/nginx/access.json")
SLACK_WEBHOOK_URL = os.environ.get("SLACK_WEBHOOK_URL", "")
SLACK_PREFIX = os.environ.get("SLACK_PREFIX", "from: @Watcher")
ACTIVE_POOL = os.environ.get("ACTIVE_POOL", "blue")
ERROR_RATE_THRESHOLD = float(os.environ.get("ERROR_RATE_THRESHOLD", "2"))
WINDOW_SIZE = int(os.environ.get("WINDOW_SIZE", "200"))
ALERT_COOLDOWN_SEC = int(os.environ.get("ALERT_COOLDOWN_SEC", "300"))
MAINTENANCE_MODE = os.environ.get("MAINTENANCE_MODE", "false").lower() == "true"
def now_iso(): return datetime.now(timezone.utc).isoformat()
def post_to_slack(text: str):
if not SLACK_WEBHOOK_URL:
return
try:
requests.post(SLACK_WEBHOOK_URL, json={"text": f"{SLACK_PREFIX} | {text}"}, timeout=5).raise_for_status()
except Exception:
pass
def parse(line: str):
try:
data = json.loads(line.strip())
return {
"pool": data.get("pool"),
"release": data.get("release"),
"status": int(data["status"]) if data.get("status") else None,
"upstream_status": str(data.get("upstream_status") or ""),
"upstream_addr": data.get("upstream_addr"),
}
except Exception:
return None
class AlertState:
def __init__(self):
self.last_pool = ACTIVE_POOL
self.window = deque(maxlen=WINDOW_SIZE)
self.cooldowns = {}
def cooldown_ok(self, key):
now = time.time()
last = self.cooldowns.get(key)
if last is None or (now - last) >= ALERT_COOLDOWN_SEC:
self.cooldowns[key] = now
return True
return False
def error_rate_pct(self):
if not self.window: return 0.0
err = 0
for evt in self.window:
if any(s.startswith("5") for s in evt.get("upstream_status","").split(",") if s):
err += 1
elif evt.get("status") and 500 <= int(evt["status"]) <= 599:
err += 1
return (err / len(self.window)) * 100.0
def handle(self, evt):
self.window.append(evt)
if MAINTENANCE_MODE:
return
pool = evt.get("pool")
if pool and self.last_pool and pool != self.last_pool:
if self.cooldown_ok(f"failover_to_{pool}"):
post_to_slack(f"*Failover Detected*: {self.last_pool} → {pool}\n• time: {now_iso()}\n• error_rate: {self.error_rate_pct():.2f}%\n• upstream: {evt.get('upstream_addr')}")
self.last_pool = pool
if len(self.window) >= max(10, int(WINDOW_SIZE * 0.5)):
rate = self.error_rate_pct()
if rate > ERROR_RATE_THRESHOLD and self.cooldown_ok(f"error_rate_{int(round(rate))}"):
post_to_slack(f"*High Error Rate*: {rate:.2f}% over last {len(self.window)} requests\n• time: {now_iso()}\n• active_pool: {pool or self.last_pool}")
def tail(path):
with open(path, "r") as f:
f.seek(0, os.SEEK_END)
while True:
line = f.readline()
if not line:
time.sleep(0.2)
continue
yield line
def main():
state = AlertState()
while not os.path.exists(LOG_PATH):
time.sleep(0.5)
for line in tail(LOG_PATH):
evt = parse(line)
if evt: state.handle(evt)
if __name__ == "__main__":
main()
EOF
Compose glues everything together: it builds the single app image, runs it twice (Blue/Green), starts Nginx, and (optionally) the Slack watcher. This is the “one file to rule them all.”
cat > docker-compose.yaml <<'EOF'
version: '3.8'
services:
app-blue:
build:
context: .
dockerfile: Dockerfile
container_name: blue-app
environment:
- APP_POOL=blue
- RELEASE_ID=${RELEASE_ID_BLUE}
- PORT=${PORT:-3000}
ports:
- "8081:3000"
healthcheck:
test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://127.0.0.1:3000/healthz || exit 1"]
interval: 5s
timeout: 3s
retries: 3
start_period: 10s
app-green:
build:
context: .
dockerfile: Dockerfile
container_name: green-app
environment:
- APP_POOL=green
- RELEASE_ID=${RELEASE_ID_GREEN}
- PORT=${PORT:-3000}
ports:
- "8082:3000"
healthcheck:
test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://127.0.0.1:3000/healthz || exit 1"]
interval: 5s
timeout: 3s
retries: 3
start_period: 10s
nginx:
image: nginx:alpine
container_name: nginx-lb
ports:
- "8080:80"
environment:
- ACTIVE_POOL=${ACTIVE_POOL}
- UPSTREAM_POOL=${ACTIVE_POOL}_pool
volumes:
- ./nginx.conf.template:/etc/nginx/nginx.conf.template:ro
- nginx_logs:/var/log/nginx
depends_on:
- app-blue
- app-green
command: >
sh -c "
envsubst '$$UPSTREAM_POOL' < /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf &&
nginx -g 'daemon off;'
"
alert_watcher:
image: python:3.11-slim
container_name: alert-watcher
depends_on:
- nginx
environment:
- SLACK_WEBHOOK_URL=${SLACK_WEBHOOK_URL}
- SLACK_PREFIX=${SLACK_PREFIX:-from: @Watcher}
- ACTIVE_POOL=${ACTIVE_POOL}
- ERROR_RATE_THRESHOLD=${ERROR_RATE_THRESHOLD:-2}
- WINDOW_SIZE=${WINDOW_SIZE:-200}
- ALERT_COOLDOWN_SEC=${ALERT_COOLDOWN_SEC:-300}
- MAINTENANCE_MODE=${MAINTENANCE_MODE:-false}
- NGINX_LOG_FILE=/var/log/nginx/access.json
volumes:
- nginx_logs:/var/log/nginx
- ./watcher.py:/opt/watcher/watcher.py:ro
- ./requirements.txt:/opt/watcher/requirements.txt:ro
command: >
sh -c "pip install --no-cache-dir -r /opt/watcher/requirements.txt && python /opt/watcher/watcher.py"
volumes:
nginx_logs:
EOF
Want it ultra-minimal? Comment out/remove
alert_watcherif you don’t need Slack alerts. The stack still works without it.What just happened? We wired four pieces: one shared app image, two containers (Blue/Green) with different env vars, Nginx in front, and an optional watcher that shares Nginx logs.
One place for all the knobs: which pool is primary, release labels, and alert thresholds. Changing ACTIVE_POOL later lets you flip who is “live” without touching code.
cat > .env <<'EOF'
# Which pool is primary (blue or green)
ACTIVE_POOL=blue
# Release IDs (just labels for observability)
RELEASE_ID_BLUE=release-v1.0.0-blue
RELEASE_ID_GREEN=release-v1.0.0-green
# App port inside the container
PORT=3000
# Optional Slack alerts
SLACK_WEBHOOK_URL=
SLACK_PREFIX=from: @YourName
ERROR_RATE_THRESHOLD=2
WINDOW_SIZE=200
ALERT_COOLDOWN_SEC=300
MAINTENANCE_MODE=false
EOF
Bring the whole stack up. Compose will build the image once and reuse it for both Blue and Green, then start Nginx and the watcher.
docker compose up -d
docker compose ps
You should see containers for blue, green, nginx, and (optionally) alert-watcher.
These calls prove traffic flows and headers are set so you can tell which pool responded.
# Through Nginx (main entry)
curl http://localhost:8080/version
# Direct to Blue
curl http://localhost:8081/version
# Direct to Green
curl http://localhost:8082/version
You should see JSON with pool and releaseId. By default, Blue is
active.
Time to break things on purpose. We’ll poison Blue and watch Nginx slide traffic to Green without customers seeing errors.
1) Baseline (Blue active):
curl http://localhost:8080/version
# Expect X-App-Pool: blue
2) Break Blue:
curl -X POST http://localhost:8081/chaos/start?mode=error
3) Check via Nginx:
curl http://localhost:8080/version
# Expect X-App-Pool: green (failover)
4) Heal Blue:
curl -X POST http://localhost:8081/chaos/stop
5) Try timeout chaos:
curl -X POST http://localhost:8081/chaos/start?mode=timeout
6) Light load test (should stay 200s, most from active pool):
for i in {1..50}; do curl -s http://localhost:8080/version >/dev/null; done
What just happened? We proved failover under two kinds of pain: errors and timeouts. Nginx noticed, retried, and shifted traffic to keep responses healthy.
Edit .env:
ACTIVE_POOL=green
Restart:
docker compose down
docker compose up -d
Nginx will now route to Green as primary, Blue as backup.
If you kept alert_watcher, set SLACK_WEBHOOK_URL in .env, then:
docker compose up -d
Trigger chaos on Blue:
curl -X POST http://localhost:8081/chaos/start?mode=error
for i in {1..50}; do curl -s http://localhost:8080/version >/dev/null; done
curl -X POST http://localhost:8081/chaos/stop
You should see Slack messages for failover and (if errors > threshold) high error rate. Tune thresholds in .env.
What just happened? The watcher tailed Nginx’s JSON logs, spotted failover/high-error signals, and pinged Slack so humans know immediately.
docker compose down
# Full clean (images/volumes):
docker compose down -v --rmi all
What just happened? We shut down everything, and if you ran the full clean, you also removed images and volumes for a fresh slate next time.
/healthz), timeouts, and chaos mode.X-App-Pool/X-Release-Id and Nginx passes headers.proxy_connect_timeout, max_fails, fail_timeout).You just built Blue/Green with automatic failover, chaos testing, and optional Slack alerts — from scratch. Happy shipping! 🚀