Forem: Sergio D. Rodríguez Inclán

DevSecOps Fundamentals Project

Sergio D. Rodríguez Inclán — Fri, 20 Feb 2026 14:42:43 +0000

Introduction

Every engineer has that one project — the one that starts as a simple idea and evolves into a full-blown learning laboratory. For me, that project is this Publisher Web App: a system designed to publish announcements across multiple social media channels simultaneously. The primary use case? The AWS Certification Announcer, a community tool where members submit their AWS certification achievements and the platform automatically publishes them to Facebook, Instagram, WhatsApp, LinkedIn, Email, etc.

What began as a practical need for the AWS User Group quickly became an exercise in applying every DevSecOps principle I wanted to put into practice, but couldn't until now. This article walks through the fundamentals of the project — the architecture, the security posture, the deployment strategy, and the lessons learned along the way.

The entire project is open source and available at github.com/Walsen/devsecops-poc.

The Vision: More Than Just Posting

The goal was never to build "yet another social media scheduler." The vision was to create a platform that could serve as a reference implementation for modern cloud-native development — one that demonstrates how to build software that is secure by design, portable across deployment models, and maintainable over time.

The platform needed to:

Publish to several channels: Facebook, Instagram, WhatsApp, LinkedIn, Email, and more
Support social authentication: Google, GitHub, LinkedIn, or email/password via Amazon Cognito
Schedule messages: Queue announcements for future delivery
Enforce role-based access: Admin and Community Manager roles with strict boundaries
Be secure from day one: Zero Trust networking, encrypted everything, WAF protection, and a hardened supply chain
Run in two deployment modes: Containers (ECS Fargate) or Serverless (Lambda + DynamoDB), switchable at deploy time

Hexagonal Architecture: The Foundation

If there is one architectural decision that made everything else possible, it is the adoption of hexagonal architecture (also known as Ports & Adapters).

This pattern separates the system into three concentric zones:

Zone	Responsibility	Dependencies
Driving Adapters	Receive external input (HTTP, Kinesis events, cron)	Depend on Inbound Ports
Application Core	Business logic, use cases, domain model	Zero external dependencies
Driven Adapters	Implement outbound integrations (DB, queues, APIs)	Implement Outbound Ports

The application core — domain entities, use cases, and port interfaces — has absolutely zero knowledge of the outside world. It doesn't know if it's running on ECS or Lambda. It doesn't know if the database is PostgreSQL or DynamoDB. It only knows about abstractions.

The Domain Model

The domain is built with pure Python dataclasses:

Entity / Value Object	Description
`Message` (Aggregate Root)	Tracks content, channels, schedule, status, and per-channel deliveries
`Certification` (Entity)	AWS certification achievement with member info and type
`ChannelType` (Value Object)	Enum: `facebook`, `instagram`, `linkedin`, `whatsapp`, `email`, `sms`
`MessageStatus` (Value Object)	Lifecycle: `DRAFT` → `SCHEDULED` → `PROCESSING` → `DELIVERED` / `FAILED`
`DeliveryResult` (Value Object)	Per-channel outcome with external ID or error

Ports and Adapters in Practice

The MessageRepository port is the same interface regardless of deployment mode. Only the adapter changes:

# Port (shared across both modes)
class MessageRepository(ABC):
    @abstractmethod
    async def get_by_id(self, id: UUID) -> Message | None: ...

    @abstractmethod
    async def save(self, message: Message) -> None: ...

# Container adapter
class PostgresMessageRepository(MessageRepository):
    def __init__(self, session: AsyncSession):
        self._session = session

# Serverless adapter
class DynamoMessageRepository(MessageRepository):
    def __init__(self, table_name: str):
        self._table = boto3.resource("dynamodb").Table(table_name)

This is the key enabler for the dual-mode deployment strategy. Business logic is completely decoupled from infrastructure.

Three Services, One Stream

The platform is composed of three microservices connected by Amazon Kinesis Data Streams:

API Service: Handles HTTP requests, authentication, and message scheduling. Implements the full hexagonal stack with FastAPI routes, middleware, and Cognito JWT validation.
Worker Service: Consumes messages from Kinesis and delivers them to the appropriate channels. Supports two publishing strategies — direct API calls or AI-powered content adaptation via Amazon Bedrock.
Scheduler Service: Polls the database for scheduled messages and publishes them to Kinesis when their delivery time arrives.

Each service has its own main.py that serves as the composition root — the only place where concrete implementations are imported and wired together. No other module imports from infrastructure/ directly.

Dual-Mode Deployment: Containers or Serverless

This is where hexagonal architecture pays off in a very tangible way. The platform supports two fully independent deployment modes, switchable at deploy time via a single CI/CD parameter:

	Containers (`infra/`)	Serverless (`infra-fs/`)
Compute	ECS Fargate	Lambda
Database	PostgreSQL (RDS)	DynamoDB (Single-Table)
API Gateway	ALB + CloudFront	API Gateway + CloudFront
Scheduler	ECS Service (APScheduler)	EventBridge + Lambda
Cost (low traffic)	~$180-200/mo	~$5-15/mo

Both modes share the same domain and application layers. Only the infrastructure adapters change. The deploy workflow selects the mode via infra_type input (containers or serverless), routing to the corresponding CDK project. Stack names are fully independent, so both can coexist in the same AWS account during migration.

Why This Matters

Different stages of a project have different needs:

Stage	Recommended Mode	Reason
Development / Prototyping	Serverless	Near-zero cost, instant deploys
Staging / QA	Either	Match production or save costs
Production (steady traffic)	Containers	Predictable latency, no cold starts
Production (variable traffic)	Serverless	Pay-per-use, auto-scaling

You can start cheap with serverless and migrate to containers when traffic justifies the fixed cost — or vice versa — without rewriting a single line of business logic.

Running Both Simultaneously

Since stack names are independent, you can run both modes in parallel during a migration window. This allows smoke testing against the new mode before cutting over, gradual traffic shifting using weighted DNS routing (Route 53), and instant rollback by switching DNS back.

Zero Trust Security: Trust Nothing, Verify Everything

Security is not a feature you bolt on at the end. It is a design principle that permeates every layer of the system. The platform implements a Zero Trust architecture based on three pillars:

Network Security

All traffic flows through multiple security layers:

The VPC is segmented into public, private, and isolated subnets. Security groups enforce micro-segmentation — the ALB can only talk to the API, the API can only talk to the Worker and the database, and the database accepts connections only from authorized services.

Authentication Flow

Every request is validated against Cognito JWTs with strict algorithm restriction (RS256 only), audience and issuer validation, and JWKS caching with TTL refresh. OAuth credentials for social providers are stored in AWS Secrets Manager.

API Security Middleware

The API service implements a comprehensive security middleware stack:

Concern	Implementation
Authentication	Cognito JWT validation with algorithm restriction
CSRF Protection	Double Submit Cookie with HMAC-signed tokens
Rate Limiting	Per-user sliding window (60 req/min)
Request Validation	1MB size limit, input sanitization, HTML escaping
Security Headers	CSP, HSTS, X-Frame-Options, Permissions-Policy
Content Filtering	Prompt injection detection + PII scanning
Idempotency	Hash-based dedup on message_id + channels

Data Protection

Encryption is applied at every layer:

In Transit: TLS 1.3 everywhere — CloudFront to ALB, ALB to ECS, ECS to RDS, ECS to Kinesis
At Rest: KMS encryption for S3, RDS, and Kinesis
In Use: No PII in logs, field-level encryption for sensitive data

Secure Supply Chain

The build pipeline is hardened against supply chain attacks with multiple security gates:

Defense in Depth: Multiple Scanners

No single scanner catches everything. The project uses six complementary tools:

Scanner	Type	Purpose
Semgrep	SAST	OWASP Top 10 patterns, custom rules
Bandit	SAST	Python-specific security issues
pip-audit	SCA	Python CVE database (PyPI Advisory)
Trivy	SCA	SBOM vulnerability scanning
Gitleaks	Secrets	Hardcoded secrets detection in git history
Checkov	IaC	AWS security misconfigurations in CDK/CloudFormation

Each tool covers blind spots the others miss. Semgrep catches SQL injection and XSS patterns. Bandit finds Python-specific issues like unsafe YAML loading. pip-audit and Trivy handle known CVEs. Gitleaks prevents credential leaks. Checkov ensures the infrastructure itself is secure — no public S3 buckets, no missing encryption, no overly permissive IAM.

Container Security

Production containers are built with security as a first-class concern:

Distroless base images: No shell, minimal attack surface
Non-root user: Containers run as nonroot by default
Read-only filesystem: No writes to the root filesystem
Pinned dependencies: Lock files with hashes for reproducibility
Resource limits: CPU and memory constraints to prevent abuse

CI/CD with GitHub Actions OIDC

The project uses GitHub Actions OIDC to assume AWS IAM roles without storing long-lived credentials. A CDK bootstrap stack (GitHubOIDCStack) creates the OIDC provider and two IAM roles:

Deploy Role (github-actions-deploy): For CDK deployments and ECR pushes
Security Scan Role (github-actions-security-scan): For Prowler audits with read-only access

No AWS access keys are stored in GitHub Secrets. Every deployment uses short-lived credentials (1 hour) obtained via OIDC federation.

The Golden Thread: Distributed Security Tracing

One of the most interesting aspects of the project is the Golden Thread — a distributed tracing exercise that demonstrates end-to-end request correlation across all infrastructure layers using a single correlation ID (X-Request-ID).

The correlation ID flows through:

Edge Layer: WAF logs (CloudFront + ALB)
Application Layer: API structured logs (structlog JSON)
Async Layer: Kinesis event → Worker logs
Database Layer: PostgreSQL audit logs (pgaudit) with SQL comments

/* correlation_id=golden-thread-test-1739... */ INSERT INTO messages (id, content_text, ...) VALUES (...)

All queryable from CloudWatch Logs Insights with a single filter:

fields @timestamp, service, event, correlation_id, method, path, status_code
| filter correlation_id = "YOUR_TRACE_ID"
| sort @timestamp asc

Attack Simulation Exercises

The project includes hands-on exercises that simulate real attacks and trace them across layers:

SQL Injection: Send a ' OR 1=1-- payload, verify WAF blocks it, confirm the request never reaches the application
XSS Attempts: Send <script>alert(1)</script>, trace the WAF block in CloudWatch
Brute Force Detection: Send 60 rapid requests, observe rate limiting kick in, check CloudWatch alarms
Full Pipeline Trace: Schedule a message with a known correlation ID, trace it from CloudFront WAF → ALB WAF → API → Kinesis → Worker → PostgreSQL

The documentation also includes exercises using professional penetration testing tools — nmap, nikto, sqlmap, ffuf, nuclei, and hydra — each with corresponding CloudWatch queries to trace the attack signatures across the infrastructure.

AI-Powered Content Adaptation

The Worker service supports two publishing strategies, selectable via configuration:

The AgentPublisher uses the Strands Agents SDK with Amazon Bedrock (Claude) to intelligently adapt content for each platform:

Platform	Adaptation
Facebook	Longer posts, emojis, hashtags at end
Instagram	Visual focus, heavy emojis, hashtags
LinkedIn	Professional tone, formal language
WhatsApp	Short, celebratory, personal

The agent reasons about which tools to call, executes them, observes results, and continues until the task is complete. Content filtering middleware protects against prompt injection and PII leakage in AI-generated output.

AI-Powered Security Testing Agent

Perhaps the most novel addition to the project is the Security Testing Agent — an AI-powered interactive penetration testing assistant built with the Strands Agents SDK and Amazon Bedrock. Instead of manually running security tests and interpreting results, you have a conversation with an agent that can run tests, diagnose failures, query AWS resources, and even auto-fix test code.

The interaction looks like this:

🔒 Penetration Testing Agent Ready!

You: Run all fast tests
Agent: I'll run the fast test suite in parallel, skipping slow scans...
       ✅ All tests passed in 8 seconds!

You: The TLS test is failing, can you debug it?
Agent: Let me run the TLS test and check the logs...
       [runs test, queries CloudFormation for endpoints, checks CloudWatch]
       The certificate for api.ugcbba.click expired. Here's what I found...

Strict Guardrails

The agent enforces strict security boundaries:

Can only run tests from a hardcoded allowlist — no arbitrary command execution
AWS access is read-only — cannot create, modify, or delete any resources
File access is sandboxed to the testing/ directory — path traversal is blocked
Refuses tasks unrelated to penetration testing

The Test Suite

The agent wraps a comprehensive pytest-based security test suite running inside a Kali Linux container:

Category	Tests	Duration
Fast (< 10s each)	Health, security headers, TLS, CORS, cookies, error disclosure, HTTP methods, origin access, SQLi, XSS	~10s total
Medium (15-30s)	Rate limiting, CSRF end-to-end, IDOR protection	~1 min
Slow (30s-10min)	nmap port scan, Nikto web scan, sqlmap automated injection	~15 min

The agent is smart about which tests to run — it prioritizes recently failed tests, skips slow scans unless explicitly requested, and caches successful results for 5 minutes to avoid redundant runs. Parallel execution via pytest-xdist makes the full fast suite complete in about 8 seconds.

Automated Penetration Testing Framework

Beyond the AI agent, the project includes a standalone automated penetration testing framework using Dockerized Kali Linux. This is the foundation that the agent builds on, but it can also be used independently in CI/CD pipelines.

# Build the Kali container
docker build -f testing/Dockerfile.kali -t pentest:latest testing/

# Quick smoke test
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest smoke

# Full test suite
docker run --rm -e TARGET_URL=http://your-alb.amazonaws.com pentest all

# Generate report
docker run --rm -v $(pwd):/tests -e TARGET_URL=$TARGET_URL pentest report

The framework integrates with GitHub Actions for scheduled weekly scans and on-demand testing, with results uploaded as workflow artifacts.

Threat Detection and Incident Response

The platform implements automated threat detection and response:

GuardDuty monitors for threats. When a finding with severity >= 4 is detected, an EventBridge rule triggers a Lambda function that automatically blocks the offending IP in the WAF IP set and sends a detailed alert to Slack. Security Hub aggregates findings from GuardDuty, CloudTrail, and AWS Config rules for a unified compliance view.

Security Observability

CloudWatch dashboards and alarms provide real-time visibility:

Metric	Threshold	Action
Auth failures (5min)	>= 20	Alarm + SNS
CSRF failures (5min)	>= 20	Alarm + SNS
Access denied (5min)	>= 30	Alarm + SNS
Rate limit hits (5min)	>= 100	Alarm + SNS
Error rate (5min)	>= 10	Alarm + SNS
Critical errors (1min)	>= 1	Alarm + SNS
API latency p95	> 1000ms	Alarm + SNS

The Developer Experience

A good DevSecOps project is not just about security and architecture — it is also about making the developer's life easier. The project uses Devbox for isolated development environments and Just as a task runner.

The justfile provides a comprehensive set of commands:

# Development
just dev          # Start local services and tail logs
just up           # Start PostgreSQL + LocalStack
just test         # Run all tests
just lint-local   # Lint all services locally

# Security
just security-scan    # SAST + SCA + Secrets scan
just trivy-scan       # Container vulnerability scan
just sbom-scan        # Generate and scan SBOMs
just iac-scan         # Infrastructure scan with Checkov
just pentest-full     # Run the full penetration test suite

# AWS Resource Management (Cost Saving)
just aws-up       # Scale up ECS services + start RDS
just aws-down     # Scale down to zero (save money)
just aws-status   # Check resource status

The aws-up and aws-down commands are particularly useful — they allow scaling the entire infrastructure to zero when not in use, saving significant costs during development.

Project Structure

The codebase is organized for clarity and separation of concerns:

.
├── api/                    # API service (FastAPI + hexagonal)
│   ├── src/
│   │   ├── domain/         # Business entities, value objects
│   │   ├── application/    # Use cases, ports, DTOs
│   │   ├── infrastructure/ # Adapters (DB, Kinesis, Secrets)
│   │   └── presentation/   # HTTP routes, middleware
│   └── tests/
│
├── worker/                 # Worker service (Kinesis consumer)
│   ├── src/
│   │   ├── domain/         # Ports for channels, publishers
│   │   ├── application/    # Delivery service
│   │   ├── infrastructure/ # Publisher adapters (Direct, AI Agent)
│   │   └── channels/       # Channel gateways (FB, IG, LI, Email, SMS)
│   └── tests/
│
├── scheduler/              # Scheduler service (cron + ECS)
├── api-lambda/             # API Lambda handler (serverless)
├── worker-lambda/          # Worker Lambda handler (serverless)
├── scheduler-lambda/       # Scheduler Lambda handler (serverless)
├── web/                    # Frontend (React + Vite + TypeScript)
│
├── testing/                # Penetration testing framework
│   ├── pentest_agent.py    # AI security testing agent (Strands SDK)
│   ├── test_pentest.py     # Security test cases (pytest)
│   ├── Dockerfile.kali     # Kali Linux container with tools
│   └── justfile            # Pentest task runner
│
├── infra/                  # CDK infrastructure (containers)
│   └── stacks/             # Network, Security, Auth, Data, Compute, Edge, Monitoring
│
├── infra-fs/               # CDK infrastructure (serverless)
│   └── stacks/             # Data, Auth, API, Worker, Scheduler, Security, Frontend
│
├── docs/                   # Comprehensive documentation
├── .github/workflows/      # CI/CD (deploy + security scan)
├── devbox.json             # Development environment
├── docker-compose.yml      # Local services
└── justfile                # Task runner

Lessons Learned

Building this project reinforced several convictions:

Hexagonal architecture is not academic overhead. It is the single decision that enabled dual-mode deployment, clean testing, and a codebase that remains navigable as it grows. The upfront investment in defining ports and adapters pays for itself many times over.

Security scanning must be layered. No single tool catches everything. The combination of SAST, SCA, secrets scanning, IaC scanning, and DAST provides genuine defense in depth. The key is making these scans fast and automatic — if they slow down the developer, they will be bypassed.

Correlation IDs are non-negotiable. The ability to trace a single request from CloudFront through the API, into Kinesis, through the Worker, and into the database is invaluable for debugging, incident response, and security forensics. Implement them from day one.

Cost management is a feature. The aws-up / aws-down pattern for scaling resources to zero when not in use is simple but effective. For a project like this, it is the difference between a $200/month bill and a $5/month bill during development.

AI agents need guardrails. The Strands Agents integration is powerful, but without content filtering, prompt injection detection, and output validation, it is a liability. The agent can only execute pre-approved operations through well-defined tool interfaces — never raw API calls. The same principle applies to the Security Testing Agent: it operates within a strict allowlist of tests and read-only AWS access, proving that AI-powered automation and security boundaries can coexist.

Conclusion

This project is a living laboratory. It is not finished, and it probably never will be — because the landscape of threats, tools, and best practices is always evolving. But it serves its purpose: a concrete, open-source reference for how to build modern cloud-native applications with security woven into every layer.

If you are starting a new project and wondering where to begin with DevSecOps, my advice is simple: start with the architecture. Get hexagonal architecture right, define your ports and adapters, and the rest — security, testing, deployment flexibility — becomes dramatically easier.

The code is open source. Fork it, break it, improve it. That is what it is there for.

An Incredible Operations Platform - Rundeck

Sergio D. Rodríguez Inclán — Sun, 01 Feb 2026 19:56:51 +0000

Introduction

There's a moment every operations engineer knows well: it's 2 AM, something's broken, and you're frantically SSH-ing into servers trying to remember the exact sequence of commands to fix it. You've done this before, but was it systemctl restart first or the config update? And which servers exactly?

This is the problem Rundeck solves. It's an open-source runbook automation platform that lets you define, schedule, and execute operational procedures across your entire infrastructure—with proper access control, audit trails, and the peace of mind that comes from knowing the procedure will run exactly the same way every time.

I've been using Rundeck for years, and recently I decided to contribute back to the ecosystem by creating three tools that solve specific pain points I encountered: a production-ready Docker image, a plugin for copying files between nodes, and a GitHub Action for seamless CI/CD integration. Let me walk you through all of them.

What Makes Rundeck Special

Rundeck occupies a unique space in the DevOps toolchain. It's not a configuration management tool like Ansible or Puppet—though it integrates beautifully with them. It's not a CI/CD platform like Jenkins—though it can trigger and be triggered by pipelines. Rundeck is specifically designed for operational workflows.

Core Capabilities

Job Definitions: Create multi-step workflows with conditionals, error handling, and node targeting
Node Management: Maintain a centralized inventory of your infrastructure with custom attributes
Access Control: Fine-grained RBAC so developers can restart their services without full SSH access
Key Storage: Secure credential management for SSH keys, passwords, and API tokens
Execution History: Complete audit trail of who ran what, when, and with what results
Scheduling: Cron-like scheduling for recurring maintenance tasks
REST API: Full API for integration with CI/CD pipelines, monitoring systems, and AI agents

Where It Shines

In my experience, Rundeck excels at:

Incident Response: Pre-built runbooks that on-call engineers can execute confidently
Self-Service Operations: Let developers restart services or clear caches without ops tickets
Coordinated Procedures: Multi-node operations that need to happen in a specific order
Compliance Tasks: Scheduled security scans, backup verifications, audit reports
Deployment Orchestration: Coordinate deployments across environments with approval gates

REST API: Automation Beyond the UI

One of Rundeck's most powerful features is its comprehensive REST API. Every action you can perform in the web interface is available programmatically, making Rundeck a perfect backend for automated operations.

API Capabilities

The API supports:

Job execution: Trigger jobs with custom parameters
Execution monitoring: Check status, stream logs, abort running jobs
Job management: Create, update, delete, import/export job definitions
Node inventory: Query and manage node sources
Key storage: Programmatic credential management
System info: Health checks, metrics, cluster status

Authentication

Rundeck supports multiple authentication methods for API access:

# Using API Token (recommended)
curl -H "X-Rundeck-Auth-Token: YOUR_TOKEN" \
  https://rundeck.example.com/api/41/projects

# Using session cookie
curl -c cookies.txt -b cookies.txt \
  -d "j_username=admin&j_password=admin" \
  https://rundeck.example.com/j_security_check

Triggering Jobs Programmatically

# Run a job by ID
curl -X POST \
  -H "X-Rundeck-Auth-Token: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"options": {"environment": "production", "version": "1.2.3"}}' \
  https://rundeck.example.com/api/41/job/JOB_ID/run

# Response includes execution ID for monitoring
{
  "id": 12345,
  "href": "https://rundeck.example.com/api/41/execution/12345",
  "status": "running"
}

Integration Scenarios

CI/CD Pipelines

Trigger deployment jobs from Jenkins, GitHub Actions, or GitLab CI. I created a dedicated GitHub Action to make this integration even easier: rundeck-github-action.

# Using the Rundeck GitHub Action
- name: Deploy via Rundeck
  uses: Walsen/rundeck-github-action@v1
  with:
    rundeck_url: https://rundeck.example.com
    rundeck_token: ${{ secrets.RUNDECK_TOKEN }}
    action: run_job
    job_id: ${{ vars.DEPLOY_JOB_ID }}
    job_options: '{"version": "${{ github.sha }}", "environment": "production"}'
    wait_for_completion: true
    timeout: 600

The action supports multiple operations:

Action	Description
`run_job`	Execute a Rundeck job with options
`get_job_info`	Get job details
`list_jobs`	List jobs in a project
`get_execution`	Get execution details
`list_executions`	List executions for a job or project
`abort_execution`	Abort a running execution

You can also wait for job completion and get the execution status:

- name: Run deployment and wait
  id: deploy
  uses: Walsen/rundeck-github-action@v1
  with:
    rundeck_url: https://rundeck.example.com
    rundeck_token: ${{ secrets.RUNDECK_TOKEN }}
    action: run_job
    job_id: ${{ vars.DEPLOY_JOB_ID }}
    wait_for_completion: true

- name: Check result
  run: |
    echo "Status: ${{ steps.deploy.outputs.execution_status }}"
    echo "URL: ${{ steps.deploy.outputs.execution_url }}"

Monitoring Integration

Have your monitoring system trigger remediation jobs automatically:

# PagerDuty webhook handler example
def handle_alert(alert):
    if alert['type'] == 'high_memory':
        requests.post(
            f"{RUNDECK_URL}/api/41/job/{CLEAR_CACHE_JOB}/run",
            headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN},
            json={"options": {"server": alert['hostname']}}
        )

AI Agents and LLM Integration

This is where things get interesting. Rundeck's API makes it an ideal execution backend for AI-powered operations. Using the Strands Agents SDK from AWS, you can build intelligent agents that leverage Rundeck as their operational backbone.

First, install the dependencies:

pip install strands-agents strands-agents-tools requests

Create a custom Rundeck tool for your agent:

from strands import Agent, tool
import requests

RUNDECK_URL = "https://rundeck.example.com"
RUNDECK_TOKEN = "your-api-token"

@tool
def list_rundeck_jobs(project: str) -> dict:
    """List available runbooks in a Rundeck project.

    Args:
        project: The Rundeck project name

    Returns:
        List of available jobs with their IDs and descriptions
    """
    response = requests.get(
        f"{RUNDECK_URL}/api/41/project/{project}/jobs",
        headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN}
    )
    return response.json()

@tool
def run_rundeck_job(job_id: str, options: dict = None) -> dict:
    """Execute a Rundeck job/runbook.

    Args:
        job_id: The UUID of the job to execute
        options: Optional parameters for the job

    Returns:
        Execution details including status and execution ID
    """
    response = requests.post(
        f"{RUNDECK_URL}/api/41/job/{job_id}/run",
        headers={
            "X-Rundeck-Auth-Token": RUNDECK_TOKEN,
            "Content-Type": "application/json"
        },
        json={"options": options or {}}
    )
    return response.json()

@tool
def get_execution_status(execution_id: int) -> dict:
    """Check the status of a Rundeck job execution.

    Args:
        execution_id: The execution ID to check

    Returns:
        Execution status and details
    """
    response = requests.get(
        f"{RUNDECK_URL}/api/41/execution/{execution_id}",
        headers={"X-Rundeck-Auth-Token": RUNDECK_TOKEN}
    )
    return response.json()

# Create the operations agent
ops_agent = Agent(
    system_prompt="""You are an operations assistant with access to Rundeck runbooks.
    When asked to perform operational tasks:
    1. List available jobs to find the appropriate runbook
    2. Execute the job with the correct parameters
    3. Monitor the execution and report the results
    Always confirm before executing destructive operations.""",
    tools=[list_rundeck_jobs, run_rundeck_job, get_execution_status]
)

# Example interaction
response = ops_agent("The app servers are running low on disk space. \
    Can you clear the log files on the production cluster?")
print(response)

This pattern keeps humans in control—the AI can only execute pre-approved runbooks with proper access controls and audit trails. It's autonomous operations with guardrails. The agent can reason about which runbook to use, execute it, and report back the results, all while respecting Rundeck's RBAC policies.

Low-Code Integration with n8n

If you prefer a visual approach to automation, n8n offers native Rundeck integration. You can build workflows that connect GitHub events to Rundeck job executions without writing code.

The n8n Rundeck node supports:

Execute: Trigger any Rundeck job with parameters
Get Metadata: Retrieve job definitions and status

Combined with n8n's 400+ integrations, you can create powerful automation chains—for example, triggering a deployment job when a GitHub release is published, then notifying your team on Slack when it completes.

Licensing: Open Source vs Enterprise

Rundeck follows an open-core model. The community edition is fully open source under the Apache 2.0 license, while PagerDuty (who acquired Rundeck) offers commercial versions with additional features.

Rundeck Community (Open Source)

Free forever, includes:

Workflow execution and job definitions
Node management and key storage
Access control (ACL-based)
Scheduling and job activity logs
Community plugins
REST API

This is what my Docker image uses—perfect for small to medium teams and learning environments.

PagerDuty Runbook Automation (Commercial)

The enterprise offerings add:

Feature	Description
High Availability	Clustered deployments with auto-takeover
SSO Integration	SAML, LDAP, OAuth support
Enterprise Plugins	ServiceNow, PagerDuty, Datadog, VMware integrations
Advanced Scheduling	Blackout calendars, schedule forecasting
Failed Job Resume	Resume from the failed step instead of restarting
Enterprise Support	SLA-backed support and account management

PagerDuty offers two commercial options:

Runbook Automation Self-Hosted: You manage the infrastructure, they provide the enterprise features
Runbook Automation (Cloud): Fully managed SaaS with 99.9% SLA

Which Should You Choose?

For most use cases, start with the open source version. It's production-ready and covers the core functionality. Consider upgrading when you need:

High availability for mission-critical operations
SSO integration with your identity provider
Enterprise integrations (ServiceNow tickets, PagerDuty incidents)
Professional support with SLAs

The open source version isn't a "lite" version—it's a complete operations platform that many organizations run successfully in production.

The Gap: Node-to-Node File Transfers

While building a configuration distribution workflow, I hit a limitation. Rundeck's built-in file copier moves files from the Rundeck server to target nodes. But I needed to copy files from one node to multiple other nodes—specifically, distributing generated configs from a central server to application nodes.

The workaround was clunky: download to Rundeck, then upload to each destination. For large files or many destinations, this becomes a bottleneck.

So I built a plugin.

Rundeck Node-to-Node Plugin

The rundeck-node-to-node plugin adds a workflow step that copies files and directories between nodes using SSH/SFTP, fully integrated with Rundeck's node definitions and key storage.

Features

Two Transfer Modes: Route through Rundeck (reliable) or direct node-to-node (fast)
Parallel Transfers: Copy to multiple destinations simultaneously
Directory Support: Recursive copy with preserved permissions and timestamps
Key Storage Integration: Uses Rundeck's secure credential management
Error Handling: Option to continue on partial failures

Transfer Modes Explained

Via-Rundeck (Default)

Files download to Rundeck once, then upload to all destinations. Works in any network topology.

Direct Mode

Source pushes directly to destinations via SCP. Faster, but requires source-to-destination SSH access.

Node Configuration

The plugin uses Rundeck's standard node attributes:

config-server:
  hostname: 10.0.1.10
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: config

app-server-01:
  hostname: 10.0.1.20
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: app,production

app-server-02:
  hostname: 10.0.1.21
  username: deploy
  ssh-key-storage-path: keys/project/deploy-key
  tags: app,production

Plugin Options

Option	Required	Default	Description
Source Node	Yes	-	Node name where files originate
Source Path	Yes	-	File or directory path on source
Destination Nodes	Yes	-	Comma-separated destination node names
Destination Path	Yes	-	Target path on destinations
Recursive Copy	No	true	Copy directories recursively
Preserve Attributes	No	true	Keep timestamps and permissions
Transfer Mode	No	via-rundeck	`via-rundeck` or `direct`
Parallel Transfers	No	true	Transfer to multiple nodes in parallel
Continue on Error	No	false	Don't fail if some destinations fail

Installation

Download the JAR from Releases
Copy to Rundeck's libext directory
Restart Rundeck (or wait for auto-reload)

The plugin appears as a new workflow step type: "Node to Node File Copy".

Production-Ready Docker Image

Installing Rundeck traditionally means dealing with Java, databases, reverse proxies, and process management. To streamline this, I created a Docker image that bundles everything for production use.

The rundeck-image provides:

Rundeck 5.18.0 (configurable version)
Nginx reverse proxy for proper HTTP handling
Supervisor for process management
PostgreSQL support for production databases
Node-to-Node plugin pre-installed

Architecture

Quick Start

docker run -d \
  -p 8080:8080 \
  -e RUNDECK_GRAILS_URL=http://localhost:8080 \
  ghcr.io/walsen/rundeck-image:latest

Access Rundeck at http://localhost:8080.

Production Setup with Docker Compose

version: '3.8'

services:
  rundeck:
    image: ghcr.io/walsen/rundeck-image:latest
    ports:
      - "8080:8080"
    environment:
      RUNDECK_GRAILS_URL: https://rundeck.example.com
      RUNDECK_DATABASE_URL: jdbc:postgresql://db:5432/rundeck
      RUNDECK_DATABASE_USERNAME: rundeck
      RUNDECK_DATABASE_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./config/realm.properties:/etc/rundeck/realm.properties
      - rundeck-data:/var/rundeck
    depends_on:
      - db

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: rundeck
      POSTGRES_USER: rundeck
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  rundeck-data:
  postgres-data:

Environment Variables

Variable	Default	Description
`RUNDECK_GRAILS_URL`	`http://localhost:8080`	External URL (must match your setup)
`RUNDECK_DATABASE_URL`	-	PostgreSQL JDBC connection string
`RUNDECK_DATABASE_USERNAME`	-	Database user
`RUNDECK_DATABASE_PASSWORD`	-	Database password

User Authentication

Mount a realm.properties file for basic authentication:

# username:password,role1,role2
admin:admin,user,admin
operator:operator123,user
readonly:viewer456,user

For production, integrate with LDAP or SSO—Rundeck supports both.

Custom Port Mapping

The image handles any external port. Just match RUNDECK_GRAILS_URL:

# Running on port 4440
docker run -d \
  -p 4440:8080 \
  -e RUNDECK_GRAILS_URL=http://localhost:4440 \
  ghcr.io/walsen/rundeck-image:latest

Practical Example: Config Distribution Workflow

Let me show how these tools work together in a real scenario.

The Setup:

1 config server generates environment-specific configuration files
5 application servers need these configs
Updates should happen without manual intervention

The Workflow:

Job Configuration:

Step	Node(s)	Action
1	config-server	`/opt/scripts/generate-config.sh`
2	config-server → app-01..05	Node-to-Node copy `/etc/myapp/config.yml`
3	app-01..05 (sequential)	`systemctl reload myapp`

The Result:

One-click config updates
Parallel distribution to all servers
Rolling reload to avoid downtime
Complete audit trail
Anyone with permissions can run it

Testing the Plugin

The plugin repository includes a Docker-based test environment:

cd test/
docker-compose up -d

This spins up:

A Rundeck instance with the plugin
Multiple test nodes for source/destination testing
Pre-configured SSH keys

See test/README.md for detailed testing instructions.

CI/CD Integration

Both repositories include GitHub Actions workflows:

rundeck-image:

Builds on every push to main
Publishes to GitHub Container Registry
Tags releases with version numbers

rundeck-node-to-node:

Builds and tests the plugin
Creates release artifacts
Publishes JAR files to GitHub Releases

Deploying Rundeck on AWS

If you're running on AWS, you have several options for deploying Rundeck. Here's my recommendation based on cost and operational effort:

Best Option: Amazon ECS on Fargate

For most teams, ECS Fargate hits the sweet spot between cost and operational simplicity:

Factor	ECS Fargate
Operational Effort	Low - no EC2 instances to manage
Cost	~$30-50/month for small workloads
Scaling	Easy horizontal scaling
Integration	Native ALB, Secrets Manager, CloudWatch
Persistence	EFS for Rundeck data, RDS for database

Budget Option: ECS with PostgreSQL Sidecar

For cost-conscious deployments, you can run PostgreSQL as a sidecar container instead of using RDS. This cuts costs significantly while maintaining a containerized approach:

Factor	With RDS	With PostgreSQL Sidecar
Monthly Cost	$50-80	$20-35
Database Backups	Automatic	Manual (EFS snapshots)
High Availability	RDS Multi-AZ option	Single container
Complexity	Two services	Single task

For most Rundeck deployments, the sidecar approach works great—Rundeck isn't a high-transaction workload, and EFS provides durability for your data.

Comparison of AWS Options

Option	Monthly Cost	Ops Effort	Best For
EC2 (t3.small)	$15-20	Medium	Budget-conscious, 24/7 workloads
EC2 Spot	$5-10	Medium	Dev/test, can tolerate interruptions
Lightsail	$5-20	Low	Learning, simple setups
ECS Fargate	$30-50	Low	Production, low maintenance
EKS	$100+	High	Already running Kubernetes

Why Not the Others?

EC2: More operational overhead (patching, monitoring), but cheaper for 24/7 workloads with Reserved Instances
EKS: Overkill unless you already have a Kubernetes cluster—adds complexity and ~$70/month just for the control plane
App Runner: Simpler but limited networking control, harder to reach private infrastructure
Lightsail: Cheapest option but limited VPC integration for node access

My Recommendations

Small team/learning: EC2 t3.small or Lightsail (~$10-20/month)
Production with low ops effort: ECS Fargate + RDS (~$50-80/month)
Enterprise/HA: ECS Fargate multi-task + RDS Multi-AZ (~$150+/month)

ECS Task Definition Example

{
  "family": "rundeck",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "rundeck",
      "image": "ghcr.io/walsen/rundeck-image:latest",
      "portMappings": [
        {"containerPort": 8080, "protocol": "tcp"}
      ],
      "environment": [
        {"name": "RUNDECK_GRAILS_URL", "value": "https://rundeck.example.com"}
      ],
      "secrets": [
        {"name": "RUNDECK_DATABASE_URL", "valueFrom": "arn:aws:secretsmanager:..."},
        {"name": "RUNDECK_DATABASE_PASSWORD", "valueFrom": "arn:aws:secretsmanager:..."}
      ],
      "mountPoints": [
        {"sourceVolume": "rundeck-data", "containerPath": "/var/rundeck"}
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/rundeck",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "rundeck-data",
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-xxxxxxxx",
        "transitEncryption": "ENABLED"
      }
    }
  ]
}

This setup gives you a production-ready Rundeck deployment with persistent storage, secrets management, and centralized logging—all with minimal operational overhead.

Conclusions

Rundeck transforms operational chaos into repeatable, auditable procedures. It's the tool I reach for when I need to bridge the gap between "we should automate this" and "we have time to build proper automation."

The Node-to-Node plugin fills a specific gap—efficient file distribution between nodes without routing everything through Rundeck. And the Docker image removes the friction of getting a production-ready Rundeck instance running.

If you're drowning in operational toil, give Rundeck a try. And if you need these specific capabilities, the tools are ready for you.

GitHub Action to Publish Hugo Posts to Dev.to

Sergio D. Rodríguez Inclán — Mon, 26 Jan 2026 04:01:50 +0000

Introduction

As developers who maintain technical blogs, we often face a common dilemma: should we publish exclusively on our own site, or should we cross-post to platforms like Dev.to, Medium, or Hashnode to reach a wider audience?

The answer is usually "both," but that creates a new problem: manual cross-posting is tedious, error-prone, and time-consuming. You write a post in Hugo, publish it to your site, then manually copy-paste the content to Dev.to, adjust the formatting, add tags, set the canonical URL, and hope you didn't miss anything.

I experienced this friction firsthand with my Hugo-powered blog at blog.walsen.website. After publishing several posts and manually cross-posting them to Dev.to, I realized this workflow was unsustainable. There had to be a better way.

That's when I decided to build hugo2devto: a GitHub Action that automatically publishes Hugo blog posts to Dev.to with full frontmatter support, canonical URLs, and zero manual intervention.

The Problem: Cross-Posting is Painful

Let me paint a picture of the traditional workflow:

Write your post in Hugo with YAML frontmatter
Build and deploy your Hugo site
Open Dev.to in your browser
Copy-paste your markdown content
Manually configure:
- Title
- Tags (max 4)
- Cover image
- Canonical URL
- Published/draft status
- Series information
Preview and publish
Repeat for every post update

This process has several problems:

Time-consuming: 10-15 minutes per post
Error-prone: Easy to forget canonical URLs or tags
Not scalable: Discourages cross-posting
No version control: Changes aren't tracked
Manual synchronization: Updates require repeating the entire process

The Solution: Automation Through GitHub Actions

The ideal solution would:

Detect when a Hugo post is created or updated
Automatically extract frontmatter metadata
Publish or update the post on Dev.to
Set the correct canonical URL
Handle tags, cover images, and series
Work seamlessly with existing Hugo workflows

This is exactly what hugo2devto does.

Building the Action: Technical Deep Dive

Architecture Overview

The action is built with TypeScript and runs on Node.js 20. Here's the high-level architecture:

Key Features

1. Full Hugo Frontmatter Support

The action understands Hugo's frontmatter format natively:

---
title: "My Awesome Post"
description: "A deep dive into something cool"
publishdate: 2026-01-25T22:23:37-04:00
draft: false
tags: ["hugo", "devto", "automation"]
series: "Hugo Automation"
eyecatch: "https://example.com/cover.png"
---

It automatically maps these fields to Dev.to's API format:

title → title
description → description
tags → tags (limited to 4)
series → series
eyecatch / cover_image → main_image
draft → published (inverted)

2. Automatic Canonical URL Generation

One of the most important SEO considerations when cross-posting is setting the canonical URL to point back to your original post. The action automatically generates this:

const canonicalUrl = `${baseUrl}/${language}/posts/${slug}/`

For example, a post at content/en/posts/my-post.md becomes:

https://blog.walsen.website/en/posts/my-post/

3. Multi-Language Support

The action detects the language from the file path:

content/en/posts/my-post.md  → English
content/es/posts/mi-post.md  → Spanish

This is crucial for Hugo sites with i18n support.

4. Mermaid Diagram Support (v1.1.0)

Hugo uses shortcodes for mermaid diagrams, but Dev.to doesn't support mermaid natively. The action automatically converts Hugo mermaid shortcodes to rendered PNG images using the mermaid.ink service:

<!-- Hugo format (in your source) -->
{{</* mermaid */>}}
flowchart TD
    A --> B
{{</* /mermaid */>}}

<!-- Converted to (on Dev.to) -->
![Mermaid Diagram](https://mermaid.ink/img/base64encodeddiagram)

This means your diagrams render beautifully on both platforms without any manual intervention.

5. Idempotent Updates

The action checks if an article already exists on Dev.to (by canonical URL) and updates it instead of creating a duplicate. This means you can run the action multiple times safely.

Implementation Highlights

Here's a simplified version of the core logic:

// Read and parse the markdown file
const fileContent = fs.readFileSync(filePath, 'utf-8');
const { data: frontmatter, content } = matter(fileContent);

// Extract metadata
const title = frontmatter.title;
const description = frontmatter.description || '';
const tags = (frontmatter.tags || []).slice(0, 4); // Dev.to limit
const published = !frontmatter.draft;

// Generate canonical URL
const slug = path.basename(filePath, '.md')
  .toLowerCase()
  .replace(/\s+/g, '-');
const language = filePath.includes('/en/') ? 'en' : 'es';
const canonicalUrl = `${baseUrl}/${language}/posts/${slug}/`;

// Prepare Dev.to article
const article = {
  title,
  body_markdown: content,
  published,
  tags,
  canonical_url: canonicalUrl,
  main_image: frontmatter.eyecatch || frontmatter.cover_image,
  series: frontmatter.series,
  description
};

// Check if article exists
const existingArticle = await findArticleByCanonicalUrl(canonicalUrl);

if (existingArticle) {
  // Update existing article
  await updateArticle(existingArticle.id, article);
} else {
  // Create new article
  await createArticle(article);
}

Using the Action: Practical Examples

Basic Setup

First, get your Dev.to API key from https://dev.to/settings/extensions and add it to your repository secrets as DEVTO_API_KEY.

Then create .github/workflows/publish-devto.yml:

name: Publish to Dev.to

on:
  push:
    branches: [main]
    paths:
      - 'content/*/posts/*.md'

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: 'content/en/posts/my-post.md'
          base-url: 'https://blog.walsen.website'

Advanced: Automatic Detection of Changed Posts

For my blog, I wanted the action to automatically detect which posts changed and publish only those:

name: Publish to Dev.to

on:
  push:
    branches: [main]
    paths:
      - 'content/*/posts/*.md'

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      posts: ${{ steps.changed-files.outputs.posts }}
      has-changes: ${{ steps.changed-files.outputs.has-changes }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2

      - name: Get changed files
        id: changed-files
        run: |
          CHANGED_FILES=$(git diff --name-only HEAD^ HEAD | grep -E 'content/en/posts/.*\.md' || echo "")

          if [ -n "$CHANGED_FILES" ]; then
            POSTS_JSON=$(echo "$CHANGED_FILES" | jq -R -s -c 'split("\n") | map(select(length > 0))')
            echo "posts=$POSTS_JSON" >> $GITHUB_OUTPUT
            echo "has-changes=true" >> $GITHUB_OUTPUT
          else
            echo "posts=[]" >> $GITHUB_OUTPUT
            echo "has-changes=false" >> $GITHUB_OUTPUT
          fi

  publish-changed:
    if: needs.detect-changes.outputs.has-changes == 'true'
    needs: detect-changes
    runs-on: ubuntu-latest
    strategy:
      matrix:
        post: ${{ fromJson(needs.detect-changes.outputs.posts) }}
      fail-fast: false
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: ${{ matrix.post }}
          base-url: 'https://blog.walsen.website'

This workflow:

Detects which markdown files changed in the last commit
Converts them to a JSON array
Uses a matrix strategy to publish multiple posts in parallel
Sets fail-fast: false so one failure doesn't stop others

Manual Trigger

You can also trigger publishing manually:

on:
  workflow_dispatch:
    inputs:
      post_path:
        description: 'Path to the post'
        required: true
        type: string

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Publish to Dev.to
        uses: Walsen/hugo2devto@v1
        with:
          api-key: ${{ secrets.DEVTO_API_KEY }}
          file-path: ${{ github.event.inputs.post_path }}
          base-url: 'https://blog.walsen.website'

Real-World Results

Since implementing this action on my blog, the results have been transformative:

Before:

⏱️ 15 minutes per post to cross-post manually
🐛 Frequent mistakes (forgotten canonical URLs, wrong tags)
😓 Discouraged from updating posts on Dev.to
📉 Inconsistent presence on Dev.to

After:

⚡ Automatic publishing in ~30 seconds
✅ Zero manual intervention required
🔄 Updates synchronized automatically
📈 Consistent cross-posting to Dev.to
🎯 More time for writing, less for publishing

Lessons Learned

Building this action taught me several valuable lessons:

1. Start with a Script, Then Package It

I initially built a TypeScript script (publish-to-devto.ts) that worked locally. Once it was stable, I packaged it as a GitHub Action. This iterative approach made debugging much easier.

2. Frontmatter Mapping is Tricky

Hugo and Dev.to use different field names and formats. Creating a robust mapping layer required careful testing with various post formats.

3. Idempotency Matters

The action needed to handle both new posts and updates gracefully. Checking for existing articles by canonical URL was crucial.

4. Documentation is Key

I created multiple documentation files:

README.md - Overview and quick start
GETTING_STARTED.md - 5-minute setup guide
SETUP.md - Comprehensive instructions
HUGO_COMPATIBILITY.md - Hugo-specific details
API_KEY_SETUP.md - Security best practices

This made the action accessible to users with different needs.

5. Community Feedback is Invaluable

Publishing the action to the GitHub Marketplace exposed it to real-world use cases I hadn't considered. User feedback helped improve error handling and edge cases.

Future Enhancements

While the action works great, there's always room for improvement:

Batch Publishing: Support publishing multiple posts in a single action invocation
Dry Run Mode: Preview what would be published without actually doing it
Custom Field Mapping: Allow users to configure their own frontmatter mappings
Image Upload: Automatically upload local images to Dev.to
Analytics Integration: Track publishing metrics
Multi-Platform Support: Extend to Medium, Hashnode, etc.
Additional Shortcode Support: Transform other Hugo shortcodes (YouTube, Twitter embeds, etc.)

Conclusion

Building hugo2devto solved a real problem I faced as a technical blogger: the friction of cross-posting content. By automating the process through GitHub Actions, I eliminated manual work, reduced errors, and made it effortless to maintain a presence on Dev.to.

The action is open source and available for anyone to use. Whether you're running a Hugo blog, a Jekyll site, or any markdown-based platform, the core concepts apply: automate the boring stuff so you can focus on writing great content.

If you're interested in trying it out or contributing, check out the repository:

Repository: https://github.com/Walsen/hugo2devto

GitHub Marketplace: https://github.com/marketplace/actions/hugo-to-dev-to-publisher

The future of technical blogging is automated, and I'm excited to see where this journey leads. Happy blogging!

A Wild Ride Into Vibe Coding

Sergio D. Rodríguez Inclán — Fri, 23 Jan 2026 11:32:21 +0000

¡Versión en español aquí!

Introduction

Since I was a child, computers have held a magnetic fascination for me. I vividly remember the first time I saw one in my mother’s office at the age of eleven; in that exact moment, I knew precisely what I wanted to do with my life.

Although destiny led me down the path of infrastructure, I never truly abandoned the dream of developing applications. While I have a solid foundation in programming and can hold my own in the terminal, a lack of daily practice and the time required for a deep dive had—until now—prevented me from producing professional-grade software.

Today, however, the landscape has shifted. With the rise of Artificial Intelligence, LLMs, and Generative AI, a new horizon has opened for profiles like mine: the ability to bring complex applications to life without needing to be an expert in deep syntax, by leveraging AI-powered editors that amplify our creative potential.

The Challenge: AWS Community Day Bolivia 2025

This adventure began with the organization of AWS Community Day Bolivia 2025. This year, the honor of leading the event fell to the AWS User Group Cochabamba, a team where I serve as one of the leaders. Organizing an event of this magnitude requires impeccable coordination with volunteers; while tools like Google Forms or Sheets are useful, I was looking for something more: a comprehensive, custom-built solution.

My vision was to build a platform that would allow us to:

Manage Projects: Create and administer specific initiatives for the event.
Dynamic Registration: Allow volunteers to sign up directly for projects.
Multichannel Communication: Send announcements and updates from a centralized hub.
Admin Panel: A secure portal for operations exclusive to authorized leaders.
Technological Innovation: Test Kiro, Amazon’s current IDE, and its powerful generative AI capabilities.
Community Legacy: Create a project "by the community, for the community" that could serve as a real-world case study in our talks.

The Journey is the Reward

Although the development wasn't finalized in time for the Community Day, the experience was a revelation. This process deeply enriched my understanding of Generative AI, application architecture, and the modern software development lifecycle. Above all, it allowed me to discover the "tips & tricks" of working with AI agents and the delicate human-machine synergy required to achieve the desired result.

As of this writing, Kiro has advanced significantly. Many of the initial limitations I encountered have been addressed—particularly regarding session management and memory—solidifying its position as a cutting-edge tool that leaves previous versions behind.

"Vibe Coding" is No Joke

I must confess, I was quite naive at first. I trusted Kiro’s output almost blindly because, initially at least, it generated the site’s starting structure correctly and surprisingly fast. The project kicked off with a specifications proposal (a Spec) designed by Kiro itself; in my prompt, I asked it to generate a three-tier serverless project: AstroJS for the frontend, FastAPI for the backend, and DynamoDB for data persistence.

During the early stages, I worked with three editors open and deployed directly from my local machine to the User Group’s AWS account. However, the time came to do things right and set up deployment via a CI/CD workflow (because, as the saying goes: "the shoemaker's son always goes barefoot"). For this, I decided to use AWS CDK. In my experience, managing state files is an additional headache I wanted to avoid, so I ruled out Terraform and Pulumi from the start.

Unifying All Projects Under a Single Session

At the start of every task, I would enter a prompt to polish details that didn’t quite look right or weren't functioning correctly. This is where I hit my first major roadblock: I had four different Kiro sessions that shared no context with one another.

If Kiro detected an API bottleneck while developing the frontend, the tool was essentially "blind" to the other components. This forced me into a constant cycle of copying and pasting to transfer data from one environment to another. To solve this, I decided to centralize everything into a single session. I grouped all the repositories into a root directory so that Kiro could navigate between them with full awareness of how the components interacted.

Below is the local structure I defined to achieve that synchrony:

❯ tree -L 1 -a
.
├── .amazonq
├── .devbox
├── .envrc
├── .gitignore
├── .kiro
├── .python-version
├── .venv
├── README.md
├── devbox.json
├── devbox.lock
├── generated-diagrams
├── pyproject.toml
├── registry-api
├── registry-documentation
├── registry-frontend
├── registry-infrastructure
└── uv.lock

9 directories, 8 files

The reader will notice that I have Devbox configured in the root directory. I made this choice because Kiro frequently needed to run Python scripts to sanitize repositories, perform searches, or handle troubleshooting tasks. Therefore, I saw the need to provide it with an isolated dependency chain, thus avoiding the installation of unnecessary software on my primary operating system.

Clear Rules: The Art of Coexistence

This was the most complex stage and the one that demanded the most time. It was a period of alignment between the AI and myself; the moment where we discovered our character, our limits, and just how much we could tolerate one another. Readers might be skeptical, but after working through dozens of sessions, I can confirm that each one develops a distinct "personality." There is a subtle but real difference: the speed at which they grasp previous context, the tone of the conversation, and the level of initiative varies from session to session.

For those who haven't yet experimented with Kiro (or Amazon Q), there are fundamental aspects that must be taken very seriously:

Session Volatility: Sessions are temporary. Upon reaching a context limit, the session resets, transferring only a very brief summary of what happened. Critical details can be lost in this process, especially if the previous activity was intense.
Trust Management: When running tools, Kiro asks if commands are safe. If you decline, it won't execute anything; if you accept, it will run everything without further confirmation. It’s an "all or nothing" situation that requires vigilance.
Git Structure Invisibility: Kiro does not natively understand the concept of a "repository." It ignores the existence of commits, branches, or staged files. Because of this, you must be surgical: you have to tell it exactly which file to modify and which change to make.
Project Ecosystem Disconnect: It doesn’t automatically assume the existence of config files, dependencies, or CI/CD workflows. To Kiro, every file is an isolated entity unless you provide the full map.

Ignoring these rules comes at a high price: Kiro will generate code that doesn't work or doesn't align with your goals. The most dangerous part is that the tool will always confidently assure you that everything is fine, leaving you with a false sense of success.

The breaking point came during an iteration where I requested an architectural adjustment. Kiro misinterpreted the instruction and altered the entire project: it transformed a Serverless architecture into one based on ECS and Aurora. It was a frustrating experience, but a necessary one. At that moment, I decided to establish rules of engagement: I created an "Architecture Primitives" document. In it, I defined strict guidelines on project structure, repository management, and expected behavior when publishing changes.

From that "contract" onward, the project stabilized. I moved forward with a fluidity that previously seemed impossible, and thanks to that, the beta version materialized much sooner than expected and is already available online.

The Blueprint: Anatomy of an Efficient Architecture

The project's architecture is illustrated in the following diagram:

To achieve the goals of cost-efficiency and scalability, I designed a modular structure divided into logical layers. Here is how the components interact:

1. Access and Delivery Layer (Edge & Auth)

This is the first line of contact with the user, prioritizing security and speed.

Amazon CloudFront: Acts as a CDN to distribute content with low global latency.
Amazon Cognito: Serves as the Identity Provider (IdP), managing authentication and the lifecycle of both users and administrators.

2. Interface Layer (API Gateway)

We separated the control planes to ensure the security of sensitive operations.

App API: The public entry point for application functionalities.
Admin API: A dedicated, isolated Gateway for privileged administrative operations.

3. The Brain: Orchestration and Serverless Logic

This is where the system's intelligence resides, utilizing an event-driven microservices approach.

AWS Step Functions: Orchestrates complex workflows, ensuring each step executes in the correct order.
Lambda Functions (Multi-purpose): Specialized functions that execute business logic, ranging from the Route Manager to access control (HBAC).
Amazon ECR: Stores the container images that power our Lambdas, enabling consistent execution environments.
AWS CDK: The "glue" of the entire project, allowing this infrastructure to be 100% reproducible through code.

4. Service Layer and Dynamic Registry

The heart of the system uses the Service Registry pattern to avoid tight coupling.

Service Registry Pattern: Implemented via Lambdas acting as a central directory, enabling dynamic service discovery at runtime.
Specialized Services: Dedicated modules for searches (Search Service), scheduled tasks (Cron Service), and personnel management (People Service).

5. Persistence and Communications (Data Layer)

A polyglot combination to handle different data types efficiently.

Amazon DynamoDB: Our NoSQL database for high-speed caching and case management.
Amazon S3: The central repository for image and object storage.
Amazon SES: The notification engine for direct communication with volunteers.

6. Cross-Cutting Layers: Security and Observability

Components that span the entire architecture to ensure health and protection.

Security and Configuration: Intensive use of AWS Secrets Manager and Parameter Store for secret management and zero-trust policies.
360° Observability: Implementation of Amazon CloudWatch for tracing, performance metrics, and log centralization.

The Project Manifesto: Patterns and Guidelines

To prevent our collaboration with AI from descending into the architectural chaos I mentioned earlier, I had to formalize our knowledge into two fundamental pillars. These documents didn't just guide Kiro; they established the foundation of what I consider modern assisted development.

1. Enterprise Architecture Patterns (EAP)

It isn’t just about writing code; it’s about following principles that guarantee the system’s evolution. Based on the documentation from the Registry Project, we implemented three golden rules:

Isolation and Decoupling: Every service operates autonomously. The use of the Service Registry is not optional; it is the mechanism that allows our infrastructure to scale without creating rigid dependencies (spaghetti code).
Design for Resilience: We apply the Saga Pattern to manage distributed transactions in serverless environments, ensuring that if one step fails, the system can automatically recover or compensate for the error.
Security by Design (Zero-Trust): No component trusts another by default. Every interaction requires identity validation through Cognito and access control based on strict policies.

2. AI Coexistence Manual: The "AI Assistant Guidelines"

Learning to talk to an agent like Kiro requires more than simple instructions; it requires a framework. These are the key takeaways from our Assistance Guidelines:

Incremental Context: Instead of firing off massive prompts, we feed the AI specific fragments of context. If Kiro knows the database structure but not the authentication flow, we explicitly remind it of the latter before asking for a change in that area.
Mandatory Human Validation: The AI proposes; the human disposes. We established that no deployment occurs without a manual review of the generated diffs. This prevented the project from accidentally transforming back into costly and unnecessary infrastructure.
Living Documentation: Every time the AI generated an innovative solution, that logic was immediately documented. In this way, the "memory" of the project didn't rely solely on Kiro's current session, but on our central knowledge repository.

The Reasoning Behind a "Multi-Cloud-Ready" Architecture in an AWS Environment

Although the project lives and breathes in the Amazon Web Services ecosystem, I made a strategic decision from day one: the architecture had to be Multi-Cloud-Ready.

Many might ask: Why complicate the design if we already have the AWS toolset? The answer lies in technical sovereignty and cost control. By implementing patterns like the Service Registry and using Devbox to isolate environments, we avoid the dreaded vendor lock-in.

Designing this way forces us to separate business logic from infrastructure. This means that if the community decided tomorrow to migrate part of the workload to another platform or integrate external services, the core of our application would not suffer a technical trauma. It is an architecture designed for freedom—where AWS is our choice of excellence, but not our only possibility.

Conclusion

This project allowed me to experience a new way of working and a new way of thinking about software development. It isn’t about replacing developers; it’s about empowering them—freeing their minds so they can focus on what truly matters: creativity, innovation, and solving complex problems.

Generative AI is a powerful tool, but it requires a human to guide it, correct it, and refine it. That is what I love most about this experience: the fact that there is a human behind every line of generated code, and that this human has the capacity to learn, evolve, and improve.

It is not about letting the AI do everything; it is about learning to work alongside it, leveraging its power to do more, be more, and achieve things that previously seemed impossible.

I hope this journey serves as an inspiration for you to explore new ways of working, thinking, and creating. May it also remind you that the future isn't something that just happens to us—it is something we build together, with tools, with technology, with AI, and with humanity.

Finally, to all those who have always wanted to develop applications but haven't been able to: now is the time. From this point forward, nothing is impossible. However, do not go into this process blindly; you must do it with a solid foundation. So, it's time to hit the books!

Thank you for reading this far, and as always, see you next time!

El Futuro del Trabajo

Sergio D. Rodríguez Inclán — Mon, 10 Nov 2025 20:37:38 +0000

English version here!

Situación actual

En el momento de escribir este artículo, las empresas tecnológicas se encuentran en una fase de transición. Con la llegada de la inteligencia artificial, la forma de producir software cambiará, y el tipo de profesionales requeridos para su construcción también lo hará (si no ha empezado a suceder ya).

En el ámbito de la informática, los roles profesionales más comunes incluyen: arquitectos y desarrolladores, especialistas en control de calidad (QA), ingenieros de infraestructura, analistas de bases de datos, y todas las variantes relacionadas con estas especialidades.

Los arquitectos y desarrolladores diseñan e implementan todo el código relacionado con el producto.

Los especialistas en control de calidad (QA) aseguran que el producto cumpla con los requisitos de calidad.

Los ingenieros de infraestructura se encargan de la infraestructura de la empresa, abarcando elementos como servidores, bases de datos, automatización en la nube, y un largo etcétera.

Los analistas de bases de datos se ocupan de estas, incluyendo el diseño de esquemas y la migración de datos, entre otras tareas.

Obviamente, existen otros roles de carácter más administrativo, pero no nos centraremos en ellos en este análisis.

La cuestión fundamental es que la IA está redefiniendo la manera en que la industria crea sus productos; el primer y más importante sector afectado es, sin duda, el software. Los ingenieros de software, que hasta hace no mucho tiempo eran muy demandados por su capacidad para producir código y llevarlo a producción, realizaban su trabajo de forma predominantemente artesanal. Aunque siempre se han seguido buenas prácticas y procesos, la mayor parte del software existente ha sido diseñado y programado por cerebros y manos humanas.

Hoy en día, los modelos de lenguaje de gran escala (LLM, por sus siglas en inglés) han superado a otros modelos de IA anteriores (como BERT) y se han consolidado como la herramienta más potente para la industria del software.

Además, las técnicas de IA generativa, como el vibe coding (si es un término específico), los agentes y los servidores MCP (Machine Control Program), combinadas, podrían potencialmente reemplazar una parte considerable del trabajo de desarrollo tradicional que impera hoy en la industria del software.

Por lo tanto, las empresas tecnológicas, especialmente las de mayor envergadura, han comenzado a reemplazar ingenieros de desarrollo tradicionales por ingenieros especializados en IA.

¿Cuál es la diferencia entre el desarrollo tradicional y el desarrollo con IA?

En pocas palabras, ya no será necesario que un desarrollador cree una API, o que un especialista DevOps despliegue una solución en la nube; un agente con esas capacidades específicas podrá hacerlo.

¿Cómo funcionan los Agentes de IA?

Los agentes de IA son sistemas que combinan modelos de lenguaje (LLM) con herramientas y capacidades de ejecución. A diferencia de un simple chatbot, un agente puede:

Razonar sobre qué acciones tomar
Ejecutar herramientas y comandos
Observar los resultados
Iterar hasta completar la tarea

He aquí un pequeño flujo de ejemplo de despliegue usando un agente de IA.

Componentes clave del sistema

LLM (Modelo de Lenguaje): El "cerebro" que razona y toma decisiones
Agente: Orquestador que coordina entre el LLM y las herramientas
Herramientas: APIs, comandos CLI, acceso a archivos, bases de datos, etc.
Entorno: El sistema real donde se ejecutan las acciones

Flujo de trabajo

Entrada del usuario: Define la tarea de alto nivel
Razonamiento: El LLM analiza qué herramientas usar y en qué orden
Ejecución: El agente invoca las herramientas necesarias
Observación: Recibe los resultados de cada acción
Iteración: El LLM decide el siguiente paso basándose en los resultados
Completación: Cuando la tarea está terminada, reporta al usuario

Este ciclo de Razonar → Actuar → Observar se repite hasta que el agente completa la tarea o determina que no puede continuar.

La imagen a continuación ilustra lo que denomino la "torre de la abstracción". Al igual que en todo proceso, existe una evolución natural donde los componentes se especializan progresivamente y su interacción se vuelve más concreta y optimizada.

Consideremos un ejemplo: el cerebro humano no "sabe" directamente cómo hacer que la mano apriete un objeto. Simplemente decide que existe una situación en la que la acción de apretar es necesaria y envía la señal al órgano especializado, que en este caso son los músculos de la mano. En la imagen, podemos establecer la siguiente analogía: el LLM representa el cerebro, el transporte simboliza los nervios, y cada agente equivale a un músculo específico de la mano.

De manera similar, en el mundo del software, el proceso evolucionó desde la implementación de un módulo monolítico único hasta la ejecución de tareas específicas en microservicios orquestados por un controlador. Este controlador decide qué microservicio debe ser invocado como resultado de un evento o una condición. Aplicando esta analogía a la imagen, el LLM se correspondería con un Control Plane, el transporte con el networking y las rutas, y los agentes con los Pods/containers.

En esta evolución, el agente de IA determina qué herramientas utilizar y en qué secuencia, mientras que el LLM decide el paso siguiente basándose en los resultados obtenidos.

El siguiente paso en el desarrollo tradicional resultó ser, quizás, más inesperado que lógico. Esta evolución de la industria del software (y de muchas otras) se traduce en la delegación del trabajo de desarrollo, implementación, pruebas y despliegue a agentes inteligentes. Estos pueden realizar dicha labor de manera ininterrumpida y con una eficiencia superior a la humana, al consumir menos recursos, dejando así atrás la faceta artesanal del proceso.

¿Y entonces, qué pasará con...?

Sí, la pregunta es crucial: ¿qué destino aguarda a los ingenieros tradicionales que, día a día, entregan tarea tras tarea?

Se presentan, entonces, dos alternativas claras: o dejamos que los acontecimientos nos arrollen y el "tsunami" nos sepulte bajo toneladas de agua, o bien, nos reinventamos y adaptamos (una vez más), aprendiendo a navegar el vasto mar de cambios que se avecinan.

De ahora en adelante, la industria ya no requerirá desarrolladores que elaboren código de principio a fin, ingenieros que desplieguen soluciones completas, o analistas que revisen exhaustivamente el código o la estructura de datos. En cambio, la industria demandará ingenieros capaces de orquestar los agentes ofrecidos por otros proveedores, así como de crear sus propios agentes para los casos específicos de su negocio.

El trabajo que antes era realizado por equipos de decenas de personas, ahora será llevado a cabo por unos pocos, quienes, sin embargo, producirán lo mismo o incluso más que aquellos "pequeños ejércitos".

Dado que la creación de productos será mucho más sencilla, es probable que surjan numerosas startups que, aunque con pocas personas, lograrán un gran impacto y se posicionarán en el mercado. Además, se crearán muchas nuevas posiciones para aquellos que aprendan a interactuar con los agentes y a mejorarlos.

La educación, sin duda, deberá transformarse también, especialmente la educación superior, que aún forma ingenieros con un perfil "clásico" que saldrán a un mercado que ya no los necesita. Las instituciones de educación superior deben reformar sus currículos ¡con urgencia!

Del mismo modo, las empresas de software que pretendan retener a sus ingenieros deberán impulsarlos a actualizarse y a realizar esta transición de la forma menos traumática posible. Como ingenieros, nos enorgullecemos de nuestras capacidades, pero en ocasiones mostramos necedad y reticencia, o incluso incredulidad, ante el cambio, sobre todo cuando este parece no favorecernos.

¿Por dónde empezar?

Como líder de un AWS User Group, uno de mis deberes consiste en guiar a la comunidad hacia este futuro.

No hay herramienta más poderosa que la educación. Por lo tanto, mi primer consejo sería buscar las certificaciones relacionadas con el tema, creadas y diseñadas por las mismas empresas que están liderando esta transición. Personalmente, considero que no hay mejor incentivo para estudiar que una certificación, ya que el conocimiento que exige no solo es teórico, sino que abarca también el dominio práctico del día a día; en consecuencia, quien no posea esa experiencia se verá impulsado a adquirirla por medios propios.

La primera y más importante certificación para iniciar este camino sería la "AWS Certified AI Practitioner", donde se abordan los fundamentos: qué es un LLM, qué es una base de datos vectorial, qué es un agente, cómo crear prompts efectivos para interactuar con un agente de IA, entre otros aspectos. Dado que es una certificación de AWS, requiere el conocimiento básico, al menos, de muchos de sus servicios y su configuración mínima. Por lo tanto, revisar el material de la certificación "AWS Certified Cloud Practitioner" resulta también muy beneficioso; y, por supuesto, si uno se anima a obtenerla, tanto mejor.

Una vez obtenida la primera certificación, se puede comenzar a crear agentes de IA y, de este modo, avanzar paulatinamente en la transición.

La primera opción es un servicio completamente administrado denominado Amazon Bedrock, que integra numerosos LLM y ofrece herramientas para crear agentes, integrar modelos, etc. Aquí puede consultarse una lista exhaustiva de artículos relacionados con Amazon Bedrock.

AWS también ofrece un framework de código abierto llamado Strands Agents, orientado a código (actualmente en Python) y de uso sencillo. Su repositorio en GitHub contiene excelentes ejemplos para iniciarse, destacando particularmente el asistente personal:

Este ejemplo emplea varios agentes integrados entre sí, como los de búsqueda de información, imágenes y videos, entre otros; así como un agente principal encargado de responder a las preguntas del usuario. Constituye un ejemplo muy didáctico para comprender las capacidades de Strands en la creación de agentes.

Una vez adquirida la experiencia necesaria, se podría optar a la certificación "AWS Certified AI Developer Professional", la cual, en el momento de redactar este artículo, se encuentra en fase beta. Obtenida esta certificación de nivel profesional, se podrá acreditar la proficiencia en el desarrollo de aplicaciones con y orientadas a la IA.

Aunque esta certificación, a pesar de ser de nivel profesional, no exige ningún requisito previo para su realización, el sentir de la comunidad sugiere que las siguientes son certificaciones ideales como preparación:

El tiempo dirá si es así.

Conclusión

Si hay algo seguro en esta vida es que todo cambia. Por lo tanto, todos debemos estar preparados para los cambios que inevitablemente llegarán.

Personalmente, he comenzado mi propio camino de transición y debo confesar que lo disfruto enormemente. Siempre fui un "Developer Wannabe" que no había encontrado el tiempo ni el coraje para concretar sus aspiraciones. Sin embargo, ahora puedo hacerlo sin la necesidad de invertir tanto tiempo profundizando en programación, y con la capacidad de crear aplicaciones funcionales en un tiempo significativamente menor. Sé que mis estimados compañeros desarrolladores critican el vibe coding con vehemencia, pero es imperativo despojarse de prejuicios, reaprender y abrir la mente, porque este cambio, que ya ha comenzado, no se detendrá, le pese a quien le pese.

Forem: Sergio D. Rodríguez Inclán

DevSecOps Fundamentals Project

Introduction

The Vision: More Than Just Posting

Hexagonal Architecture: The Foundation

The Domain Model

Ports and Adapters in Practice

Three Services, One Stream

Dual-Mode Deployment: Containers or Serverless

Why This Matters

Running Both Simultaneously

Zero Trust Security: Trust Nothing, Verify Everything

Network Security

Authentication Flow

API Security Middleware

Data Protection

Secure Supply Chain

Defense in Depth: Multiple Scanners

Container Security

CI/CD with GitHub Actions OIDC

The Golden Thread: Distributed Security Tracing

Attack Simulation Exercises

AI-Powered Content Adaptation

AI-Powered Security Testing Agent

Strict Guardrails

The Test Suite

Automated Penetration Testing Framework

Threat Detection and Incident Response

Security Observability

The Developer Experience

Project Structure

Lessons Learned

Conclusion

Links

An Incredible Operations Platform - Rundeck

Introduction

What Makes Rundeck Special

Core Capabilities

Where It Shines

REST API: Automation Beyond the UI

API Capabilities

Authentication

Triggering Jobs Programmatically

Integration Scenarios

Licensing: Open Source vs Enterprise

Rundeck Community (Open Source)

PagerDuty Runbook Automation (Commercial)

Which Should You Choose?

The Gap: Node-to-Node File Transfers

Rundeck Node-to-Node Plugin

Features

Transfer Modes Explained

Node Configuration

Plugin Options

Installation

Production-Ready Docker Image

Architecture

Quick Start

Production Setup with Docker Compose

Environment Variables

User Authentication

Custom Port Mapping

Practical Example: Config Distribution Workflow

Testing the Plugin

CI/CD Integration

Deploying Rundeck on AWS

Best Option: Amazon ECS on Fargate

Budget Option: ECS with PostgreSQL Sidecar

Comparison of AWS Options

Why Not the Others?

My Recommendations

ECS Task Definition Example

Conclusions

Links

GitHub Action to Publish Hugo Posts to Dev.to

Introduction

The Problem: Cross-Posting is Painful

The Solution: Automation Through GitHub Actions

Building the Action: Technical Deep Dive

Architecture Overview