DEV Community: George-Adaba

SwiftDeploy: Building a Self-Configuring DevOps Engine with Observability, Policy Enforcement & Auditing

George-Adaba — Wed, 06 May 2026 20:18:26 +0000

Introduction

This is not just a project—it’s a mini DevOps platform.
In this guide, you will build SwiftDeploy, a system that:

Generates its own infrastructure from a single file
Monitors itself using real-time metrics
Enforces deployment safety using policy-as-code
Logs and audits every decision

By the end, you will be able to replicate the entire system locally from scratch.

1. The Design: A Tool That Writes Its Own Infrastructure

Core Idea

Everything is driven by manifest.yaml
This is your single source of truth.

Instead of manually writing:

docker-compose.yml
nginx.conf

Your CLI (SwiftDeploy) generates them.

2. Prerequisites

Install:

Docker
Docker Compose
Git
Python or Go

3. Project Structure

swiftdeploy/
├── manifest.yaml
├── swiftdeploy
├── app/
├── templates/
├── policies/
├── history.jsonl
├── README.md

4. Example manifest.yaml

services:
  image: swift-deploy-1-node:latest
  port: 3000

nginx:
  image: nginx:latest
  port: 8080

network:
  name: swiftdeploy-net
  driver_type: bridge

This file controls everything.

5. Setup & Run (Step-by-Step)

git clone https://github.com/YOUR_USERNAME/swiftdeploy.git
cd swiftdeploy
swiftdeploy init
swiftdeploy validate
swiftdeploy deploy

Expected Output (Deploy)

Manifest valid
Docker image found
Nginx config valid
Services starting...
Health check passed
Deployment successful

6. Observability: Metrics (/metrics)

Your API exposes metrics in Prometheus format.
Access Metrics
http://localhost:8080/metrics

Example Metrics Output
http_requests_total{method="GET",path="/",status="200"} 120
http_requests_total{method="GET",path="/",status="500"} 5

http_request_duration_seconds_bucket{le="0.5"} 100
http_request_duration_seconds_bucket{le="1"} 110
http_request_duration_seconds_bucket{le="+Inf"} 125

app_uptime_seconds 360
app_mode 1
chaos_active 2

Metrics Interpretation
Total requests = 125
Errors = 5
Error rate = 5 / 125 = 4%

This feeds directly into policy decisions.

7. Policy Enforcement (OPA)

SwiftDeploy uses Open Policy Agent.

Policy Flow
CLI → Collect Data → Send to OPA → Receive Decision → Act

Example Input to OPA (Pre-Promote)
{
"error_rate": 0.04,
"p99_latency": 600,
"mode": "canary"
}

Example OPA Response
{
"allow": false,
"reason": "Error rate exceeds 1% threshold"
}

Policies Implemented

Infrastructure Policy
Block deploy if:
Disk < 10GB
CPU > 2.0

Canary Safety Policy
Block promote if:
Error rate > 1%
P99 latency > 500ms

8. Chaos Testing (Failure Simulation)

Trigger Chaos

Slow Mode

POST /chaos
{
  "mode": "slow",
  "duration": 3
}

Error Mode

POST /chaos
{
  "mode": "error",
  "rate": 0.5
}

Reproduce Failure Scenario

Deploy system
Trigger chaos
Run swiftdeploy status
Run swiftdeploy promote

Expected Result
DENIED: P99 latency exceeds 500ms

9. Live Dashboard (swiftdeploy status)

swiftdeploy status

Example Output
Mode: canary
Requests/sec: 15
P99 latency: 620ms
Error rate: 3%

Policy Status:

Infrastructure: PASS
Canary Safety: FAIL (latency too high)

10. Logging (history.jsonl)

Each snapshot is stored as:

{
"timestamp": "2026-05-06T12:00:00Z",
"mode": "canary",
"req_per_sec": 15,
"p99_latency": 620,
"error_rate": 0.03,
"policy": "FAIL"
}

11. Audit Report

Generate:
swiftdeploy audit

Example Output (audit_report.md)

## Timeline
12:00 - Mode switched to canary
12:02 - Chaos injected

## Violations
12:03 - Error rate exceeded threshold
12:04 - Promotion denied

12. Failure Testing

Test Disk Failure
Fill disk → run deploy
DENIED: Disk space below 10GB

Test Error Rate Failure
Inject chaos → run promote
DENIED: Error rate exceeds threshold

13. Security Requirement

OPA:
Must NOT be exposed via NGINX
Only accessible internally

14. Lessons Learned

1. Metrics Design is Critical
Bad metrics = wrong decisions

2. Policy Separation Improves Safety
OPA removes logic from the CLI.

3. Observability Enables Automation
No metrics → no intelligence

4. Failure Handling Matters
The system must never crash

5. Build Incrementally
Each layer depends on the previous

System Architecture

manifest.yaml
↓

swiftdeploy CLI
↓

Generated configs (Docker + Nginx)
↓

Containers (App + Nginx + OPA)
↓

Metrics → CLI → OPA → Decision
↓
history.jsonl → audit_report.md

Conclusion

SwiftDeploy is now a system that

Writes its own infrastructure
Observes its own behaviour.
Enforces its own safety
Records its own history

Final Thought

If your system can:

See itself
Evaluate itself
Protect itself

Then you’re not just deploying apps…
You’re building intelligent, resilient systems.

How I Built a Real-Time DDoS Detection System with Python, Docker, and Nginx (Beginner-Friendly Guide)

George-Adaba — Wed, 29 Apr 2026 21:14:23 +0000

Introduction

As a beginner stepping into DevOps and cybersecurity, I wanted to build something practical and impactful — not just theory.

So I built a real-time DDoS detection and mitigation system that:

Monitors live traffic from Nginx logs
Detects suspicious spikes using statistics
Automatically blocks attacking IPs
Sends alerts to Slack
Displays everything on a live dashboard

In this post, I’ll walk you through exactly how it works — in a simple, beginner-friendly way.

What Problem Am I Solving?

A DDoS (Distributed Denial of Service) attack happens when a server gets flooded with too many requests.

This can:

Slow down your app
Crash your server
Make your service unavailable

My solution:
Build a system that can detect abnormal traffic and stop it automatically

Project Architecture

Here’s what I used:
Nginx → Handles incoming traffic
Nextcloud → Sample app (target)
Python daemon → Detects attacks
Docker Compose → Runs everything
Slack Webhook → Sends alerts
Dashboard UI → Shows live metrics

Step 1: Monitoring Nginx Logs
Nginx logs every request like this:

127.0.0.1 - - [timestamp] "GET /index.html" 200
My system:

Reads logs in real-time
Extracts:
- IP address
- Timestamp
- Status code Here's the link to how I implemented that here

Step 2: Sliding Window (Core Idea)
To detect attacks, I track requests over time using a sliding window.

Think of it like this:
“How many requests happened in the last 60 seconds?”

I used Python’s deque to:

Add new requests
Remove old ones automatically

Step 3: Building a Baseline
Instead of guessing what’s “too much traffic”, I calculate a baseline:
Track requests per second over 30 minutes

Compute:
Mean (average traffic)
Standard deviation

This helps answer:
“What does normal traffic look like?”
Here is how i implemented that here

Step 4: Detecting Anomalies
I detect attacks using two methods:

Z-score
If traffic is far above normal:
z-score > 3
Spike detection
If traffic are:
> 5x the average

If either condition is true, it’s an attack
Here is how i implemented that here

Step 5: Blocking Attackers
When an IP is suspicious:
I block it using iptables

Example:

iptables -A INPUT -s <IP> -j DROP

Step 6: Auto-Unban System
Not every spike is an attack forever.
So I implemented a backoff unban system:

10 minutes
30 minutes
2 hours
Permanent (if repeated) Here is how I implemented that here

Step 7: Slack Alerts
I used Slack webhooks to send alerts like the following:

Global traffic spike
IP blocked
IP unbanned Here is how I implemented that here

Step 8: Live Dashboard
I built a simple dashboard that shows the following:

Global requests per second
Top 10 IPs
Banned IPs
CPU & memory usage
Baseline stats

It refreshes every 3 seconds.
Here is how I implemented that here

Step 9: Dockerizing Everything
I used Docker Compose to run the following:

Nginx
Nextcloud
Detector service

This made setup easy and reproducible.
Here is how i implemented that here

Challenges I Faced

Secrets in GitHub GitHub blocked my push because of a Slack webhook.

Fix: Moved webhook to environment variables

Container Not Starting My app kept crashing because of config. YAML was missing.

Fix: Added it to Docker image

No Slack Alerts The container couldn’t access environment variables.

Fix: Passed variables via docker-compose. yml

What I Learned

How real-time log monitoring works
How to detect anomalies using statistics
How to automate security responses
How to use Docker in real projects
Why never commit secrets

Final Thoughts

This project helped me move from the following:
“Just learning DevOps” → “Building real-world systems”

If you’re a beginner, I highly recommend building something like this.

Dashboard URL: http://52.203.164.199:5000/
GitHub Repo: https://github.com/George-Adaba/anomaly-detection-ddos.git