DEV Community: Mario Ezquerro

Building Enterprise Storage, Backups & Cosign Image Security in Go & Flutter with Google Antigravity

Mario Ezquerro — Thu, 20 Aug 2026 18:13:27 +0000

Building Enterprise Storage, Point-in-Time Backups & Cosign Image Security in Go & Flutter with Google Antigravity

When architecting a modern container orchestrator like Gubernator (gbnt) — designed to strike the Goldilocks balance between the simplicity of Docker Swarm and the placement flexibility of Nomad — two major enterprise pillars stand between an MVP and true production readiness:

State Persistence & Backup Mobility (The Granaries / Horreum): Moving stateful containers (PostgreSQL, MySQL, Redis, custom data volumes) across worker nodes without data loss, backed by compressed point-in-time snapshots and retention policies.
Software Supply Chain Security & Admission Control (The Imperial Seal / Armamentarium): Detecting CVE vulnerabilities before deployment, cataloging dependencies via Software Bill of Materials (SBOM), signing container images with cryptographic keypairs (Cosign/Sigstore), and enforcing strict Gatekeeper admission policies.

In this article, we break down how we designed and implemented these two major subsystems in Gubernator v2.24.0 & v2.25.0, and how we leveraged Google Antigravity (AGY) as an autonomous AI engineering partner to architect, implement, test, and live-deploy Full-Stack features (Go + SQLite + Flutter Web + CLI) across a live 3-node multi-host cluster.

Part 1: Persistent Storage & The Backup Subsystem (The Granaries)

Stateful container workloads present a fundamental orchestration challenge: how can a container move between different physical hosts while maintaining access to its persistent disk storage?

 ┌─────────────────────────────────────────────────────────────────────────┐
 │                   GUBERNATOR STORAGE & BACKUP ENGINE                     │
 ├─────────────────────────────────────────────────────────────────────────┤
 │   /var/contenedores (Shared Mobility Pool: NFS, GlusterFS, CephFS)    │
 │   Point-in-Time Compressed Tarballs (.tar.gz) + SHA-256 Checksums     │
 │   Background Cron Scheduler & Automated Retention Pruning            │
 │   Zero-Downtime Consistent Freeze (docker pause -> tar -> unpause)    │
 └─────────────────┬───────────────────────────────────┬───────────────────┘
                   │                                   │
                   ▼                                   ▼
      ┌─────────────────────────┐         ┌─────────────────────────┐
      │  Centurion 1 (Manager)  │         │  Centurion 2 (Worker 1) │
      │   IP: 192.168.252.27    │         │   IP: 192.168.252.25    │
      │  Mount: /var/contened.. │         │  Mount: /var/contened.. │
      └─────────────────────────┘         └─────────────────────────┘

1. Shared Storage Mobility (`/var/contenedores`)

Gubernator standardizes volume mobility by designating /var/contenedores across all cluster nodes. When backed by a distributed file system (NFS, GlusterFS, CephFS, CIFS) or localized volumes:

The orchestrator can dynamically schedule database or application containers to any active Centurion host.
The storage explorer inspects and displays disk utilization (used / total, percentage, and node read/write mount health).

2. Database-Consistent Snapshots with Docker Freeze

Backing up a running relational database (PostgreSQL, MariaDB, SQLite) while active transactions are in flight risks data corruption.

We implemented an optional Atomic Freeze Strategy:

// internal/storage/backup.go
func CreateBackup(name, targetPath, stackName, serviceName string, pauseContainer bool) (*db.Backup, error) {
    if pauseContainer && containerID != "" {
        slog.Info("backup: pausing container for consistent snapshot", "container", containerID)
        _ = dockerClient.ContainerPause(ctx, containerID)
        defer dockerClient.ContainerUnpause(ctx, containerID)
    }

    // Stream directory to tar.gz with SHA-256 calculation
    archiveFile, sha256Checksum, sizeBytes, err := archiveDirectory(targetPath, destFile)
    if err != nil {
        return nil, err
    }
    // ... Save record to SQLite ...
}

3. Automated Cron Policies & Retention Rotation

Gubernator's background backup daemon evaluates standard cron expressions (e.g. 0 2 * * * for nightly 2:00 AM backups) and automatically prunes older snapshots according to a configured retention count (e.g. keep last 7 copies).

Part 2: Image Security, SBOM & Cosign Cryptography (The Imperial Seal)

Deploying third-party container images blindly introduces severe supply-chain risks. In v2.25.0, we introduced a complete Pre-Deployment Admission Gatekeeper:

                         [ Stack Deploy / Container Run Request ]
                                          │
                                          ▼
                 ┌──────────────────────────────────────────────────┐
                 │     GUBERNATOR ADMISSION GATEKEEPER (Port 4000)   │
                 │     - Evaluates Cluster & Stack Security Policy  │
                 └────────────────────────┬─────────────────────────┘
                                          │
          ┌───────────────────────────────┴───────────────────────────────┐
          ▼                                                               ▼
 ┌───────────────────────────┐                                 ┌───────────────────────────┐
 │  1. Cryptographic Sign  │                                 │ 🔍 2. CVE Vulnerability   │
 │    (Cosign / Sigstore)    │                                 │    Scanning & CVSS Scores │
 ├───────────────────────────┤                                 ├───────────────────────────┤
 │ Is the image signed with  │                                 │ Does image exceed Max     │
 │ a trusted cluster key?    │                                 │ Severity (Critical/High)? │
 └─────────────┬─────────────┘                                 └─────────────┬─────────────┘
               │                                                             │
               ├───────── ❌ Unsigned / Invalid                              ├───────── ❌ Exceeds Threshold
               │          (If policy = 'ENFORCE')                            │          (If policy = 'BLOCK')
               ▼                                                             ▼
 ╔═══════════════════════════╗                                 ╔═══════════════════════════╗
 ║  ⛔ DEPLOYMENT REJECTED   ║                                 ║   ⛔ DEPLOYMENT BLOCKED   ║
 ║ "Signature check failed"  ║                                 ║ "Found 2 Critical CVEs"   ║
 ╚═══════════════════════════╝                                 ╚═══════════════════════════╝
               │                                                             │
               └──────────────────────────┬──────────────────────────────────┘
                                          │ ✅ Passes All Admission Checks
                                          ▼
                         ╔═════════════════════════════════╗
                         ║ 🚀 Container Scheduled on Hosts ║
                         ╚═════════════════════════════════╝

1. Pure Go Cosign ECDSA Keypair Generation & Signing

To eliminate heavy external binary dependencies like cosign or CGO toolchains, we implemented the cryptographic signing engine using Go's standard library (crypto/ecdsa, crypto/elliptic, crypto/x509, crypto/sha256):

// internal/security/signing.go
func GenerateCosignKeypair(name string) (pubPEM string, privPEM string, err error) {
    privKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
    if err != nil {
        return "", "", err
    }

    privBytes, _ := x509.MarshalECPrivateKey(privKey)
    privPEMBlock := &pem.Block{Type: "EC PRIVATE KEY", Bytes: privBytes}
    privPEM = string(pem.EncodeToMemory(privPEMBlock))

    pubBytes, _ := x509.MarshalPKIXPublicKey(&privKey.PublicKey)
    pubPEMBlock := &pem.Block{Type: "PUBLIC KEY", Bytes: pubBytes}
    pubPEM = string(pem.EncodeToMemory(pubPEMBlock))

    return pubPEM, privPEM, nil
}

2. Multi-Standard SBOM Generator (CycloneDX & SPDX)

For software inventory audits and compliance, Gubernator automatically analyzes container image layers, extracts packages and OS libraries (musl, glibc, OpenSSL, busybox), and exports standardized Software Bill of Materials in:

CycloneDX 1.5 JSON
SPDX 2.3 JSON

3. Cluster-Wide Auto-Discovery & Host Mapping

Rather than requiring users to register images manually, Gubernator continuously discovers all container images running across every node in the cluster (Manager, Worker 1, Worker 2). The UI dynamically renders host badges and service tags indicating where every container instance is hosted.

Part 3: The Flutter Web Dashboard Visualization

Gubernator's Web Dashboard (Port 4001) provides two rich Material Design 3 interfaces:

Storage & Backups (The Granaries)

Volumes Table: Displays Named Volumes, Shared Pools, and Host Bind Mounts with live disk usage calculations.
Snapshot Manager: 1-click on-demand backup creation, direct .tar.gz browser downloads, and backup restore modals.
Pool Health Matrix: Validates mount availability, read/write permissions, and free disk space across all cluster hosts.

Image Security & SBOM (The Imperial Seal)

** Vulnerabilities Tab**: Real-time image catalog displaying Critical, High, Medium, Low CVE counts, verified signature badges, and host mappings (Used in: caddy, promtail on Manager, Worker 1, Worker 2).
** SBOM Explorer Tab**: Component dependency tree with license compliance auditing and 1-click CycloneDX/SPDX downloads.
** Signatures & Keys Tab**: In-cluster Cosign ECDSA keypair generator and image signing terminal.
** Gatekeeper Policies Tab**: Interactive admission policy switches (Audit / Warn Only vs Strict Enforcement, CVE severity threshold blocking).

⚡ Part 4: Full CLI Parity

Every capability is accessible directly through the gbnt CLI:

# === Storage & Backups ===
gbnt volume ls
gbnt backup ls
gbnt backup create --name "postgres-nightly" --pause /var/contenedores/postgres
gbnt backup restore <backup-id> --target /var/contenedores/postgres

# === Image Security & SBOM ===
gbnt scan
gbnt scan postgres:16-alpine
gbnt sbom postgres:16-alpine --format cyclonedx-json > sbom.json

# === Cosign Signing & Verification ===
gbnt security key generate --name "prod-release-key"
gbnt image sign company/payments:2.1.0 --key /path/to/private.key
gbnt image verify company/payments:2.1.0

# === Cluster Gatekeeper Policy ===
gbnt security policy

Part 5: How We Built This with Google Antigravity (AGY)

Building a distributed orchestrator with state synchronization, cryptographic operations, cross-compilation, and Full-Stack Web UIs is an intricate endeavor. Here is how Google Antigravity accelerated development:

1. Specification-Driven Engineering

Before writing code, we used Antigravity to formalize comprehensive architectural blueprints:

Having structured specifications allowed the AI to implement the entire pipeline (GORM database schemas, pure Go cryptography, REST API routes, Flutter Dart models, and CLI flags) with complete architectural alignment.

2. Autonomous Root-Cause Debugging

During initial testing of the backup scheduler, we encountered a recursive mutex deadlock: StartBackupScheduler() was holding cronMutex.Lock() while calling SyncSchedules(), which also attempted to acquire cronMutex.Lock(). Antigravity inspected the call graph, refactored syncSchedulesLocked(), and verified thread-safety without human intervention.

3. Live Cluster Deployment & Verification

Antigravity seamlessly built Linux ARM64 binaries (CGO_ENABLED=0 GOOS=linux GOARCH=arm64), transferred them to a live 3-node Multipass virtualized cluster (gbnt-manager, gbnt-worker1, gbnt-worker2), and executed live HTTP and CLI verification checks against Port 4000, 4001, and 4002.

🏁 Conclusion & What's Next

With Storage & Backups (v2.24.0) and Image Security & Cosign (v2.25.0), Gubernator bridges the gap between lightweight simplicity and enterprise-grade resilience.

Whether you are running a single-node homelab or an edge-distributed cluster, you can now:

Run stateful databases with confidence using point-in-time compressed backups.
Secure your software supply chain with automated CVE scanning and Cosign cryptographic signatures.

Explore the project on GitHub:
GitHub: mario-ezquerro/gubernator
Official Documentation & Guides

Have you implemented image signing or shared volume mobility in your container setups? Share your thoughts in the comments below!

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

Mario Ezquerro — Mon, 17 Aug 2026 09:00:16 +0000

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

When building a lightweight container orchestrator like Gubernator (gbnt) — designed to strike the perfect balance between the simplicity of Docker Swarm and the flexibility of Nomad under a Roman Empire theme — a critical milestone inevitably emerges: Enterprise Security and Access Control.

While a default admin credential works well for local dev environments, moving into enterprise production with multi-disciplinary engineering teams demands:

Corporate Single Sign-On (SSO) with Microsoft Active Directory and OpenLDAP.
Role-Based Access Control (RBAC) to clearly segregate who can deploy stacks, restart containers, or audit telemetries in read-only mode.
Dynamic Group Mapping from corporate security groups (memberOf) to orchestrator roles.
Emergency Break-Glass Access (Local Administrator) in case network directory controllers are unreachable.

In this article, we explore the complete architecture of the enterprise security engine introduced in Gubernator v2.20.0, and how we leveraged Google Antigravity (AGY) as an autonomous AI pair programmer to design, implement, test, and verify this Full-Stack feature (Go + Flutter Web) across a live 3-node cluster.

The Security Architecture

We designed a decoupled, asymmetric architecture connecting identity providers, REST API middleware, and the Flutter Web UI:

 ┌────────────────────────────────────────────────────────┐
 │                   GUBERNATOR WEB UI                    │
 │   - Modern Login Screen with Domain / AD Selector      │
 │   - Header Role Badge: Admin |  Ops |  Read-Only.      │
 └──────────────────────────┬─────────────────────────────┘
                            │ (REST /api/auth/login)
                            ▼
 ┌────────────────────────────────────────────────────────┐
 │             GUBERNATOR CORE AUTH ENGINE (Go)           │
 │  - Local Emergency Admin (admin / admin fallback)      │
 │  - Multi-Server Active Directory / OpenLDAP Dialers    │
 │  - LDAPS (Port 636) & StartTLS (Port 389) Handshake    │
 │  - Dynamic Group DN -> RBAC Role Resolution            │
 │  - Cryptographic HMAC-SHA256 JWT Token Signing         │
 └─────────────┬────────────────────────────┬─────────────┘
               │                            │
               ▼                            ▼
 ┌───────────────────────────┐ ┌──────────────────────────┐
 │  Primary Active Directory │ │ Secondary LDAP Server    │
 │   dc1.corporate.local     │ │   dc2.dr-site.local      │
 └───────────────────────────┘ └──────────────────────────┘

Role-Based Access Control (RBAC) Matrix

We established three distinct operational tiers:

Operational Capability	`admin`	`operator`	`readonly`
Overview, Metrics & SRE Telemetry	✅ Full	✅ Full	✅ Full
Deploy Stacks (`docker-compose.yml`)	✅ Full	✅ Full	❌ Restricted
Redeploy & Duplicate Stacks	✅ Full	✅ Full	❌ Restricted
Delete Stacks	✅ Full	❌ Restricted	❌ Restricted
Task Lifecycle (Start / Stop / Restart)	✅ Full	✅ Full	❌ Restricted
Container & Node Terminal Shell	✅ Full	✅ Full	❌ Restricted
Node Fleet Management (Drain / Activate / Leave)	✅ Full	❌ Restricted	❌ Restricted
Caddy TLS Certificates & Ingress Routes	✅ Full	❌ Restricted	❌ Restricted
Active Directory & LDAP Directory Settings	✅ Full	❌ Restricted	❌ Restricted
Grafana, Jaeger & Weave Scope Dashboards	✅ Full	✅ Full	✅ Full

💻 The Go Backend Engine (`internal/auth/`)

For LDAP/Active Directory interactions, we used github.com/go-ldap/ldap/v3, and for session management github.com/golang-jwt/jwt/v5.

1. Two-Phase Bind & Credential Verification

Authentication follows a secure two-phase pattern:

Connect and perform a Service Account Bind (BindDN / BindPassword) to query the directory.
Search for the user object using a configurable LDAP filter (defaulting to (&(objectClass=user)(sAMAccountName=%s))).
Open a secondary connection and perform a Direct User Bind with the user-submitted password against the domain controller.

func AuthenticateLDAP(cfg db.LDAPConfig, username, password string) (*AuthResult, error) {
    conn, err := ConnectLDAP(cfg)
    if err != nil {
        return nil, err
    }
    defer conn.Close()

    // 1. Initial service account bind
    if cfg.BindDN != "" && cfg.BindPassword != "" {
        if err := conn.Bind(cfg.BindDN, cfg.BindPassword); err != nil {
            return nil, fmt.Errorf("service account bind failed: %w", err)
        }
    }

    // 2. Search for the user
    filter := fmt.Sprintf(cfg.UserFilter, ldap.EscapeFilter(username))
    searchReq := ldap.NewSearchRequest(
        cfg.BaseDN,
        ldap.ScopeWholeSubtree, ldap.NeverDerefAliases, 0, 0, false,
        filter,
        []string{"dn", "displayName", "mail", "memberOf"},
        nil,
    )
    sr, err := conn.Search(searchReq)
    if err != nil || len(sr.Entries) == 0 {
        return nil, errors.New("user not found in directory")
    }

    userEntry := sr.Entries[0]

    // 3. Direct user bind to verify password
    userConn, err := ConnectLDAP(cfg)
    if err != nil {
        return nil, err
    }
    defer userConn.Close()

    if err := userConn.Bind(userEntry.DN, password); err != nil {
        return nil, errors.New("invalid credentials")
    }

    // 4. Map groups to RBAC role
    groups := userEntry.GetAttributeValues("memberOf")
    role := ResolveRole(cfg, groups)

    return &AuthResult{
        UserDN:      userEntry.DN,
        Username:    username,
        DisplayName: userEntry.GetAttributeValue("displayName"),
        Email:       userEntry.GetAttributeValue("mail"),
        Groups:      groups,
        Role:        role,
    }, nil
}

2. Dynamic Group-to-Role Mapping

Gubernator inspects the user's memberOf group list and matches them against the configured group DNs:

func ResolveRole(cfg db.LDAPConfig, userGroups []string) Role {
    matchesGroup := func(targetGroup string) bool {
        if targetGroup == "" { return false }
        target := strings.ToLower(strings.TrimSpace(targetGroup))
        for _, g := range userGroups {
            if strings.ToLower(strings.TrimSpace(g)) == target {
                return true
            }
        }
        return false
    }

    if matchesGroup(cfg.AdminGroupDN) { return RoleAdmin }
    if matchesGroup(cfg.OperatorGroupDN) { return RoleOperator }
    if matchesGroup(cfg.ReadOnlyGroupDN) { return RoleReadOnly }

    return NormalizeRole(cfg.DefaultRole)
}

The Flutter Web UI Experience

Gubernator's Web Dashboard is built with Flutter Web and Material Design 3, compiled and embedded directly into the Go binary (go:embed).

1. Modern Login Screen with Domain Selector

Operators can select their target authentication provider (Corporate Active Directory, DR Site LDAP, or Local Administrator):

2. Active Directory Management & Diagnostics

In the new Seguridad & AD tab, cluster administrators can configure directory servers, TLS certificates, and run a live "Test Connection" diagnostic tool:

3. Real-Time Role Badges & Contextual Guards

The dashboard header displays the active user and their assigned role (ADMIN, ⚡ OPERATOR, READ-ONLY). Mutating actions (e.g., Delete Stack, Drain Node, Shell) are automatically disabled for read-only audit accounts.

How Google Antigravity Accelerated Development

We utilized Google Antigravity (AGY) as an autonomous AI pair programmer to build this feature end-to-end. AGY accelerated the development cycle through several key workflows:

Architectural Planning:
Before writing code, Antigravity produced a comprehensive implementation plan (implementation_plan.md) outlining the GORM schema changes (LDAPConfig), RBAC authorization matrix, and API routes.
Synchronized Full-Stack Implementation:
In a single coordinated session, Antigravity:
- Built the Go internal/auth/ engine with LDAP dialers, JWT session handlers, and Gin middlewares.
- Applied SQLite database auto-migrations.
- Implemented the Flutter Web UI (login_screen.dart, security_page.dart, and state models).
- Updated existing views (legions_page.dart, tasks_page.dart, centurions_page.dart) with RBAC permission guards.
Live Cluster Testing & Verification:
Using automated commands across a 3-node multipass cluster (gbnt-manager, gbnt-worker1, gbnt-worker2), Antigravity:
- Deployed and hot-restarted the ARM64 binaries.
- Tested REST endpoints via curl (valid login, invalid login, LDAP connection tests, configuration lifecycle).
- Executed Go unit tests (go test ./internal/auth/...) with 100% pass rates.
Automated Documentation & Release:
- Generated high-fidelity visual UI showcases.
- Authored complete documentation in docs/auth-rbac.md and validated MkDocs builds in strict mode.
- Bumped the version to v2.20.0, created git release tags, and triggered GitHub Pages publishing.

Conclusion & Open Source

Adding Active Directory SSO and RBAC allows teams to deploy Gubernator in enterprise production environments that require enterprise security compliance without the operational overhead of Kubernetes.

Check out Gubernator and try it out:

GitHub Repository: github.com/mario-ezquerro/gubernator
Official Documentation: mario-ezquerro.github.io/gubernator
Active Directory & RBAC Guide: docs/auth-rbac.md

What do you think about this hybrid approach to container orchestration? Let us know your thoughts and suggestions in the comments!

Reviving Open Source Giants: How I Brought Weave Scope Back with Multi-Platform Docker Support in One Afternoon Using Antigravity

Mario Ezquerro — Fri, 14 Aug 2026 16:36:10 +0000

The open-source ecosystem is full of architectural masterpieces that—due to corporate pivots, lack of maintainers, or shifting market focus—eventually get frozen in time. One of the most prominent examples is Weave Scope: a legendary tool for visual monitoring, real-time mapping, and debugging container clusters.

When the original repository was archived and left unmaintained, its dependency tree froze and it remained strictly tied to x86_64 architectures. In today’s world, with the widespread adoption of ARM servers (AWS Graviton, Apple Silicon, Raspberry Pi clusters, etc.), running the original build has become nearly impossible.

I set out to rescue it, modernize its build pipelines, and create multi-platform Docker images. The result? The project is back to life at github.com/mario-ezquerro/scope with multi-arch Docker images live on Docker Hub.

The best part: the entire journey took a single afternoon and a few tokens thanks to Antigravity.

The Challenge: Brilliant Code Locked in the Past

Weave Scope is far from a trivial codebase. Its architecture integrates:

Low-level kernel probes and agents written in Go and eBPF.
A reactive, interactive web UI.
Complex legacy Makefiles and container toolchains originally engineered exclusively for amd64/x86_64.

Manually upgrading this stack to modern docker buildx workflows with native support for both ARM64 and AMD64 would traditionally mean days of painful software archaeology: resolving broken Go packages, outdated C libraries, incompatible packaging scripts, and compilation errors.

The Catalyst: Antigravity as a Software Rescue Agent

This is where Antigravity makes an extraordinary difference.

Instead of spending days fighting legacy Makefiles and deprecated toolchains, I leveraged Antigravity to parse the repository structure, diagnose build blockers, and modernize the compilation and packaging pipeline for multi-architecture targets.

What used to be a tedious migration became an agile, iterative session:

Dependency Audit & Fixes: Identifying system calls and C bindings that prevented cross-compilation.
Dockerfile & Buildx Refactoring: Modernizing the multi-stage build pipeline to compile native binaries for both linux/amd64 and linux/arm64.
Automated Publishing: Generating multi-arch manifest lists and pushing them directly to Docker Hub.

The Modernized Multi-Arch Scope

The revived project is ready for the community:

New GitHub Repository: https://github.com/mario-ezquerro/scope
Original Repository (Legacy): https://github.com/weaveworks/scope
Docker Hub Multi-Arch Images: Ready to deploy on both x86 and ARM infrastructure.

Quick Start

Run the probe and visualization UI on any local machine or server (including Apple Silicon and Raspberry Pi clusters):

# Pull and run Scope with multi-arch support
docker run -d --name weave-scope \
  --net=host \
  --pid=host \
  --privileged \
  -v /var/run/docker.sock:/var/run/docker.sock \
  marioezquerro/scope:latest
Open your browser at http://localhost:4040 to see your real-time container topology in action.

Takeaway: A Golden Era for Open Source Maintenance
The true power of modern AI platforms like Antigravity isn't just generating boilerplate code from scratch—it is their astonishing capability for software restoration and modernization.

GitHub contains thousands of brilliant, abandoned projects that simply need an afternoon of care, dependency updates, and container modernization. With a single afternoon and a handful of tokens, any developer now has the superpower to revive forgotten open-source gems and give them back to the global community.

What abandoned open-source project is on your wishlist to revive next? Let me know in the comments!

[Boost]

Mario Ezquerro — Tue, 11 Aug 2026 08:43:08 +0000

Mario Ezquerro for Google Developer Experts

Aug 11

Gubernator v2.13.0: Google SRE SLOs, Native CoreDNS Suite & Caddy Ingress for Docker Compose

#devops #docker #sre #go

5 min read

Gubernator v2.13.0: Google SRE SLOs, Native CoreDNS Suite & Caddy Ingress for Docker Compose

Mario Ezquerro — Tue, 11 Aug 2026 06:14:53 +0000

If you love the simplicity of Docker Swarm (native Compose files, lightweight single binary) but miss the advanced capabilities of Kubernetes (targeted label placement, SRE-grade observability, built-in DNS service discovery, and zero-trust ingress), meet Gubernator (gbnt).

We are excited to release Gubernator v2.13.0, introducing three massive feature suites natively integrated into a single binary and a modern Material Design 3 Flutter Web Dashboard:

Google SRE Multi-Burn-Rate SLO Engine & Interactive Suite
CoreDNS 4-Tab Management Suite & Interactive Dig Playground
Caddy Ingress & Zero-Trust Reverse Proxy Suite

Fun Fact: The entirety of Gubernator's codebase, multi-node deployment pipelines, and SRE features were designed, built, and pair-programmed using **Google Antigravity (AGY), Google DeepMind's agentic AI coding assistant!

Let's dive into what's new and how you can level up your self-hosted or production container clusters!

1. Google SRE Multi-Burn-Rate SLO Engine & Web Suite

Defining Service Level Objectives (SLOs) and tracking Error Budgets is the gold standard of Site Reliability Engineering. Until now, implementing SLOs meant running heavy Kubernetes CRDs (via tools like Sloth or Pyrra) or using costly SaaS platforms.

Gubernator v2.13.0 brings Google SRE Workbook (Chapter 5) compliant multi-burn-rate alerting straight to simple docker-compose.yml services:

version: "3.8"
services:
  payment-api:
    image: hashicorp/http-echo:latest
    labels:
      gbnt.slo.enable: "true"
      gbnt.slo.target: "99.9"
      gbnt.slo.window: "30d"
      gbnt.slo.template: "caddy-http"
      gbnt.slo.journey: "Checkout Flow"

What makes Gubernator's SLO Suite unique?

Google Multi-Burn-Rate Alerting: Automatically generates standard 4-window Prometheus recording and alert rules (Critical Page 1h/6h & Warning Ticket 3d/14d).
Dynamic "No-Code" Management: Click "+ Configure / Add SLO" in the Web UI or call POST /v1/slo/edit to create, edit, or disable SLOs on the fly without editing Compose files.
Composite User Journeys: Group multi-service SLOs into end-to-end flows (Checkout Flow: API Gateway + Payment + DB) and automatically identify the weakest-link bottleneck service.
Deployment Correlation Timeline: Cross-reference real-time burn rate spikes against stack updates and container restarts to answer "Did our last deploy burn the budget?".
PromQL Dry-Run Backtesting: Validate Compose YAML syntax and test PromQL queries against historical Prometheus metrics prior to deployment.
Automated Grafana Dashboards: Automatically generates /data/monitor/grafana/dashboards/slo_dashboard.json on rule sync.

SLO Ecosystem Comparison Matrix

Here is how Gubernator compares to other popular open-source and commercial SLO tools:

Feature / Capability	Gubernator	Sloth (`slok/sloth`)	Pyrra (`pyrra-dev/pyrra`)	OpenSLO / Nobl9
Native Runtime Environment	Docker Compose / Swarm / Bare Metal	Kubernetes / OpenSLO CLI	Kubernetes CRDs / Filesystem	Multi-Cloud / SaaS
Declarative Spec	`docker-compose.yml` labels (`gbnt.slo.*`)	K8s CRDs / Sloth YAML	Custom Resources (`ServiceLevelObjective`)	OpenSLO YAML Spec
SRE Calculation Engine	Google SRE Multi-Burn-Rate (via Sloth Engine)	Google SRE Multi-Burn-Rate (4 windows)	Prometheus Multi-Burn-Rate	Proprietary / Custom
Integrated Web Dashboard	Yes (Flutter Web 5-Tab Suite)	No (CLI / Operator only)	Yes (React/Go UI)	Yes (SaaS Console)
Dynamic Hot-Editing	Yes (Web UI Modal & REST API)	No (Requires re-applying YAMLs)	No (Read-only from K8s/Files)	Yes (SaaS Console)
User Journeys (Composite SLOs)	Yes (Aggregation & Bottleneck Analysis)	No	No	Yes (Related Services)
Deployment Correlation	Yes (Real-time Timeline of Stacks/Restarts)	No	No	Partial (CI/CD Webhooks)
Built-in SLI Templates	Yes (`caddy-http`, `http-status`, `latency-p99`, `grpc`)	Partial (Sloth Libraries)	No (Raw PromQL)	No
Dry-Run PromQL Backtesting	Yes (Pre-deploy Validation)	Partial (`validate` command)	No	No
RED Metrics Breakdown	Yes (RPS, Error Rate, P99 Latency Cards)	No	Partial (RPS & Errors)	Yes
Automated Grafana Provisioning	Yes (Auto-generates `slo_dashboard.json`)	Partial (Generic Rules)	No	No

2. Native CoreDNS 4-Tab Suite & Interactive Dig Playground

Internal container service discovery should "just work." In Gubernator, every deployed container automatically receives --dns <CoreDNS_IP>, enabling seamless *.gbnt internal resolution across multi-node clusters.

With v2.13.0, we are expanding CoreDNS into a full 4-Tab Management Suite:

+-------------------------------------------------------------------------+
|                      GUBERNATOR COREDNS SUITE                           |
|                                                                         |
|  [Tab 1: Auto-Discovered] [Tab 2: Custom Records] [Tab 3: DNS Playground] [Tab 4: Config]
+-------------------------------------------------------------------------+

Key Features:

Tab 1: Auto-Discovered Stacks (*.gbnt): Real-time table mapping running containers to <service>.<stack>.gbnt with copyable curl commands.
Tab 2: Custom Static DNS Records: Manage custom A, AAAA, CNAME, TXT, and PTR records stored in SQLite and merged into CoreDNS on the fly (POST /v1/coredns/custom-records).
Tab 3: Interactive Dig Playground: A built-in terminal console to run DNS queries against local CoreDNS (127.0.0.1:5354), benchmark query latency in milliseconds, and inspect raw nslookup output.
Tab 4: Upstream Forwarders & Corefile Editor: One-click upstream DNS presets (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) and a live Corefile editor with container reload.

3. Caddy Ingress Suite & Zero-Trust Reverse Proxy

Gubernator packages Caddy as its default edge proxy, handling HTTPS certificate provisioning, reverse proxying, and access logging across multi-node setups.

Features in the Caddy Suite:

7-Tab Management Visualizer: Dashboard, Dynamic Routes Matrix, Corefile Preview, TLS Certs Inspector, Real-time Access Logs, Log Config, and Prometheus Metrics.
Root CA Trust Installation: One-click download of Gubernator's internal Root CA certificate for local TLS trust across your developer devices.
Automatic Ingress Label Routing: Simply add ingress.host=my-app.example.com to your Compose service, and Gubernator reconfigures Caddy route matrices across all cluster nodes automatically.

Getting Started in Under 60 Seconds

You can spin up a complete Gubernator cluster with full observability, CoreDNS, Caddy, and Prometheus/Grafana in seconds:

# 1. Download binary & start Gubernator Manager
curl -sSL https://raw.githubusercontent.com/mario-ezquerro/gubernator/main/install.sh | bash
gbnt serve

# 2. Deploy the SRE Monitoring Stack (Prometheus, Grafana, Loki, cAdvisor, Jaeger)
gbnt monitor init

3. Access Web Dashboards

Web UI Dashboard -> http://localhost:4001

Grafana -> http://localhost:3000

CoreDNS Playground -> http://localhost:4001 (CoreDNS tab)




---

## Built Autonomous with Google Antigravity

A special shoutout to **Google Antigravity (AGY)**! The entire architecture of Gubernator -- from Go backend REST APIs, SQLite ORMs, Caddy route management, CoreDNS hosts sync, Sloth SLO rule compilation, down to the 5-tab Flutter Web UI -- was built autonomously in pair-programming sessions with Google Antigravity AI.

---

## Conclusion & Open Source

Gubernator aims to make container orchestration **fast, resilient, and enjoyable** again -- without the steep operational overhead of Kubernetes.

- **GitHub Repository**: [mario-ezquerro/gubernator](https://github.com/mario-ezquerro/gubernator)
- **Documentation & Guides**: [https://mario-ezquerro.github.io/gubernator/](https://mario-ezquerro.github.io/gubernator/)
- **Give us a Star**: If you find Gubernator useful, drop a star on GitHub!

*What are your thoughts on native SLO tracking for Docker Compose? Let us know in the comments below!*

Gubernator Weekly Update: CoreDNS Aqueducts, SRE Stack, Network Topology & Cluster Auto-Updates!i

Mario Ezquerro — Thu, 30 Jul 2026 06:55:16 +0000

Gubernator Weekly Update: CoreDNS Aqueducts, SRE Stack, Network Topology & Cluster Auto-Updates!
Gubernator Weekly Update Banner
Review
Gubernator Weekly Update Banner

What an intense week for Gubernator (gbnt)! If you're new here, Gubernator is the "Goldilocks" container orchestrator that bridges the gap between Docker Swarm's simplicity (native Compose support, simple node joining) and Nomad's scheduling flexibility (hardware targeting, labels, task-based management).

Over the past 7 days, Gubernator evolved from a single-node engine into a production-ready cluster ecosystem. Here is a breakdown of everything shipped this week!

1. Ingress & Service Discovery ("The Aqueducts")
One of our biggest milestones this week was shipping automated internal DNS resolution and edge ingress routing:

CoreDNS Integration: Every node running Gubernator can now deploy CoreDNS. Containers across all hosts can resolve internal service IPs using dynamic domain names (.gbnt.test). As containers spin up or die, Gubernator's manager updates CoreDNS records in real-time.
Caddy Ingress: Exposing web services is now effortless. Services deployed with routing labels are automatically proxied by Caddy, managing SSL and HTTP/HTTPS ingress dynamically.

2. SRE Observability Suite (gbnt monitor init)
Observability shouldn't require writing 500 lines of YAML. With a single command, gbnt monitor init, Gubernator deploys a complete, production-grade observability stack:

Prometheus & cAdvisor: Detailed container and host-level metrics collection (CPU, RAM, Network I/O).
Loki & Promtail: Centralized log aggregation across all containers.
Grafana: Pre-configured dashboards for instant visualization out of the box.
Jaeger Tracing: Full OpenTelemetry distributed tracing support (OTLP gRPC :4317 & HTTP :4318).

Interactive Network Topology (Weave Scope Integration) Understanding how containers talk to each other across a distributed cluster can be tough. We integrated Weave Scope directly into the Flutter Web Dashboard!

Live Process & Socket Spy: Mounts /proc and /sys to trace active socket connections between containers in real-time.
Dynamic CoreDNS Spy: Container relationships are automatically linked and mapped based on DNS requests and active network traffic.

4. Zero-Downtime Cluster Auto-Updates
Keeping a cluster updated shouldn't require manual SSH scripts. We introduced Gubernator Cluster Auto-Updates:

GitHub Releases Integration: The Manager polls the GitHub Releases API (with 15-minute smart caching).
Header Notification: When a new tag is detected, the top-left sidebar header highlights the available update: [ MANAGER v2.7.2 ] → [ MANAGER v2.7.4 ]
Cluster-Wide Rolling Update: Clicking the badge opens a confirmation dialog with full release notes. Confirming triggers an automated image pull (marioezquerro/gubernator:) and coordinated rolling restarts across the Manager and all registered Worker nodes!

5. UI/UX Refinements (Flutter Web Dashboard)
We also polished the Web UI for maximum developer ergonomics:

Clickable Port Chips: Mapped container ports (e.g. 8080:80) are now rendered as interactive chips. One click opens http://: directly in your browser.
Bulk Container Actions: Checkboxes on the Tasks table allow batch Start, Stop, Restart, or Delete operations.
Dynamic Split Ratio: Legions (Stacks) and Centurions (Nodes) panels now feature a default 1/3 vs 2/3 layout with drag-to-resize support.

Try Gubernator Today!
Gubernator is open-source and built for developers who want the simplicity of Swarm combined with modern SRE observability.

GitHub Repository: mario-ezquerro/gubernator
Docker Hub: https://github.com/mario-ezquerro/gubernator

Drop a ⭐ on GitHub if you like where Gubernator is heading! What features would you like to see next? Let me know in the comments!

Introducing Gubernator: The Goldilocks Container Orchestrator (Docker Swarm + Nomad Hybrid)

Mario Ezquerro — Sat, 25 Jul 2026 11:47:44 +0000

Introducing Gubernator: The Goldilocks Container Orchestrator

Gubernator combines the simplicity of Docker Swarm with the flexibility of Nomad.

Technical Foundation

Language: Go (Golang)
State: SQLite (Centralized on Manager, with local cache on Workers for resilience)
API: Secured REST (Port 4000)
Web UI: Flutter Web Dashboard with Material Design 3 (Port 4001)
Observability: OpenTelemetry + Prometheus, Swagger, Healthchecks (Port 4002)
Engine: Docker Engine API interaction

Building a Hybrid Docker Orchestrator in Go: The Journey from Single VM to Multi-Node Cluster

Mario Ezquerro — Tue, 14 Jul 2026 17:54:10 +0000

What if you could combine the native simplicity of Docker Compose with the decentralized targeting and reliability of HashiCorp Nomad?

Meet Gubernator (or gbnt), a "Goldilocks" container orchestrator written in Go. In this post, I want to share how I took Gubernator from a single-node API to a fully decentralized, multi-node VM cluster with autonomous DNS resolution and local ingress routing—all co-authored alongside Antigravity, Google DeepMind's agentic AI pair programmer.

The Vision: Why Gubernator?

Kubernetes is the undisputed king of container orchestration, but for small-to-medium projects, homelabs, or edge deployments, it represents massive operational overhead. Docker Swarm is simple but lacks fine-grained task scheduling constraints.

Gubernator is designed to fill that sweet spot:

Single Binary Portability: The same gbnt binary acts as the Central Manager (holding the centralized SQLite state) and the Worker Agents.
Central SQLite with Local Cache: Workers run a local cache so that containers keep running and resolving internal routes even if connectivity to the Manager is lost.
Decentralized Ingress & DNS: The cluster leverages a distributed network of CoreDNS and Caddy instances.

The Architecture: Multi-Node Setup

To test the orchestrator realistically, we provisioned three Multipass Ubuntu VMs:

gbnt-manager (192.168.252.8)
gbnt-worker1 (192.168.252.9)
gbnt-worker2 (192.168.252.10)

graph TD
    Host[Mac/Laptop Host OS] -->|Resolves *.gbnt via local resolver| CoreDNS_Manager
    subgraph Manager VM [gbnt-manager: 192.168.252.8]
        CoreDNS_Manager[gbnt-coredns]
        Mgr[gbnt-manager API & DB]
        Caddy_Mgr[gbnt-caddy]
    end
    subgraph Worker 1 VM [gbnt-worker1: 192.168.252.9]
        Agent1[gbnt Agent]
        Caddy1[gbnt-caddy]
        CoreDNS1[gbnt-coredns]
        Cont1[App Containers]
    end
    subgraph Worker 2 VM [gbnt-worker2: 192.168.252.10]
        Agent2[gbnt Agent]
        Caddy2[gbnt-caddy]
        CoreDNS2[gbnt-coredns]
        Cont2[App Containers]
    end

    Mgr -->|Orchestrates| Agent1 & Agent2
    CoreDNS_Manager -->|Synchronizes Records| CoreDNS1 & CoreDNS2
    Caddy1 -->|Routes to local| Cont1
    Caddy2 -->|Routes to local| Cont2

Decentralized Ingress & Localized Caddy Routing

One of the biggest challenges in multi-host networking is how to route web traffic to containers without overloading the Manager.

Instead of routing all external traffic through a single ingress proxy on the Manager, we built a fully decentralized routing scheme:

Decentralized DNS (CoreDNS): When a stack is deployed, Gubernator registers the domain (e.g., hello-app.gbnt) pointing directly to the IP of the Worker VM hosting the container.
Localized Ingress (Caddy): Each VM runs its own independent Caddy Ingress container.
Decentralized Caddyfiles: Caddy on the Manager only manages reverse-proxy rules for containers running locally on the Manager. Worker agents periodically poll the Manager for their assigned tasks and generate a local Caddyfile targeting only their local containers.

This means if hello-app.gbnt is deployed on gbnt-worker2 (192.168.252.10):

The client's browser queries DNS, which resolves to 192.168.252.10.
The browser connects directly to Caddy on gbnt-worker2 on port 80.
Caddy proxies the request to the local container IP (e.g. 172.17.0.2:80).
Zero transit traffic touches the Manager VM.

Co-authoring with Antigravity (Google DeepMind)

What makes this project unique is that 100% of the Go code, GORM integrations, Flutter dashboard widgets, and cluster setups were co-authored with Antigravity, Google DeepMind's agentic AI coding assistant.

Unlike simple autocomplete or chat windows, Antigravity acts as a pair programmer with agentic capabilities:

Debugging Complex Network Behaviors: We encountered an issue where containers connected to multiple Docker networks (like bridge and gbnt-monitor-net) had their IPs concatenated (e.g., 172.17.0.2172.19.0.7). Antigravity traced the container IP extraction logic, proposed a fix, and validated the parser.
Infrastructure Bootstrapping: Antigravity ran Multipass commands to spin up the VMs, transfer Go binaries, configure authorization keys, and join the workers into the cluster via JWT tokens.
Auto-Generating the Flutter Dashboard: Antigravity designed and iterated on the Flutter Web UI, implementing features like a real-time cluster topology map, live task statuses, and a settings dialog containing system metadata and version tags.

Cluster Observability

Observability is built-in. By running gbnt monitor init, the Manager spins up a complete telemetry stack connected via a dedicated network gbnt-monitor-net:

cAdvisor: Exposes hardware and container metrics.
Prometheus: Scrapes metrics from all nodes.
Grafana: Visualizes metrics.
Loki & Promtail: Aggregates logs across all nodes.

Conclusion

Gubernator proves that you don't need a heavy orchestrator like Kubernetes to manage multi-host Docker deployments. By combining Go, SQLite, CoreDNS, and Caddy, we created a lightning-fast, decentralized orchestrator.

Pair-programming with an agentic coder like Antigravity allowed me to focus on high-level architecture while the AI handled refactoring, cross-compilation, VM deployment, and frontend updates.

If you are interested in building lightweight orchestration systems, check out the Gubernator repository and start building!

Have you built or used lightweight orchestrators? Let me know in the comments below!

#devops #docker #golang #ai #pairprogramming #antigravity

Stop Copy-Pasting `dns:` Blocks: Introducing Transparent DNS Injection in Gubernator

Mario Ezquerro — Mon, 13 Jul 2026 06:21:32 +0000

If you’ve ever built a containerized home lab, a multi-host cluster, or an internal development environment using Docker Compose with custom local DNS (like CoreDNS), you know this exact pain point:


yaml
services:
  web:
    image: nginx:alpine
    dns:
      - 192.168.1.100  # Hardcoded CoreDNS IP
  api:
    image: my-api:latest
    dns:
      - 192.168.1.100  # Copied again...
  db:
    image: postgres:alpine
    dns:
      - 192.168.1.100  # And again!

It is repetitive, it litters your configuration files, and if you forget to paste that block or the DNS IP changes, your container is born blind—unable to resolve internal services or talk to the internet.

With Gubernator, we decided to eliminate this boilerplate entirely.

The Solution: Transparent DNS Injection 🪄
Starting with version v2.4.13, Gubernator implements Transparent DNS Injection.

Now, you can deploy your standard, clean, unedited docker-compose.yml file. No custom network configurations, no hardcoded IPs.

yaml
# Standard, clean Compose file. No "dns:" blocks required!
services:
  web:
    image: nginx:alpine
  api:
    image: my-api:latest
  db:
    image: postgres:alpine

Behind the scenes, Gubernator's deployment executor intercepts container creation and dynamically injects the cluster's CoreDNS host IP directly into the container's runtime configuration.

How It Works Under the Hood 
Host IP Auto-Detection: Gubernator automatically detects the Manager Node IP at startup (either via GBNT_HOST_IP or by testing outbound gateway paths).

Dynamic Templating: CoreDNS templates are updated on the fly to handle custom local routing domains (like *.gbnt and *.gbnt.test).
Runtime Interception: During scheduling and task execution, Gubernator intercepts the container host configuration and populates the DNS servers parameter with the dynamically resolved CoreDNS address.

The Result: 0% Boilerplate, 100% Magic 
Your containers are deployed instantly and gain immediate out-of-the-box support to:

Resolve internal service domains seamlessly.
Communicate with the outer internet through your configured upstream forwarders.
Adapt automatically even if the physical IP of your manager host changes.

Get Started 
Gubernator is designed to combine the simplicity of Docker Compose with the scheduling power of Nomad. You can inspect the code, read the documentation, and launch your first cluster today on GitHub:

Gubernator GitHub Repository https://github.com/mario-ezquerro/gubernator

If you find this feature useful, don't forget to drop a ⭐️ on GitHub! What are your thoughts on container DNS management? Let me know in the comments!

Gubernator visual schema.

Mario Ezquerro — Tue, 09 Jun 2026 09:42:18 +0000

Excited to share the latest feature built for Gubernator (gbnt): Visual Stack Topology & Network Schema!

Gubernator is designed as a "Goldilocks" orchestrator—combining the raw simplicity of Docker Compose with Nomad-inspired scheduling and hardware/AI targeting. But deploying complex multi-container stacks means visualization is key to maintaining control.

To bridge this gap, I’ve just integrated a native Web Network Schema & Container Topology Viewer directly into the Gubernator dashboard:

What makes it unique?

Auto-discovered Ingress & Routing: The scheduler parses docker-compose.yml to automatically place a virtual Caddy Ingress node in web-facing services (e.g. n8n, WordPress, Jupyter) and internal sinks/databases (e.g. MySQL, PostgreSQL).

Live Network Context: Every container card details live telemetry—including internal container IPs, host port mappings, and active domains (e.g.ingress.host).

Visual Dependency Mapping: Custom Bézier-curve connection lines are dynamically drawn in yellow/amber to highlight container network relationships and dependencies (like depends_on).

One-Click Multi-Format Export: Perfect for team architecture syncs or DevOps documentation! Diagrams can be instantly exported and downloaded as PNG, JPEG, PDF, or native SVG (automatically adapting to light/dark system themes).

Gubernator continues its journey to simplify local and edge container orchestration. Let me know what you think of this visualization layer!

https://github.com/mario-ezquerro/gubernator/

_ #Docker #Golang #Flutter #DevOps #Nomad #Orchestration #WebDevelopment #SystemArchitecture #Containers

Gubernator E101 examples examples examplesss....

Mario Ezquerro — Mon, 08 Jun 2026 12:30:01 +0000

Gubernator Examples: Hands-On Tutorials

Gubernator features four progressive developer examples designed to walk you from basic container orchestration to advanced AI workloads:

Example 101 — Getting Started (WordPress & MySQL)
Goal: Understand the basics of single-node orchestration.
Stack: A classic multi-container application consisting of a WordPress front-end and a MySQL database backend.
Key Concepts: Persistent Docker named volumes, basic container scheduling, internal CoreDNS resolution (db.wp.gbnt), and initial Caddy Ingress routing.
Example 102 — Load Balancing (Round-Robin Routing)
Goal: Learn how Gubernator handles horizontal scaling and high availability.
Stack: A scaled deployment featuring multiple BusyBox HTTP replicas serving their individual container hostnames.
Key Concepts: Scaling up replicas, automatic target grouping under a single DNS record, and Caddy Ingress configuring native round-robin load balancing across the running replicas under hello.gbnt.local.
Example n8n — AI Automation Stack (RAG & Local LLMs)
Goal: Orchestrate a modern, automated AI agent workflow.
Stack: An automation workspace integrating n8n (workflows), PostgreSQL (backend database), Ollama (local LLM runtime running llama3.2), and Qdrant (vector database for RAG).
Key Concepts: Inter-container communication using CoreDNS, complex service dependencies, transient automated setup tasks (auto-pulling LLM models on startup), and multi-domain Caddy Ingress routing.
Example Jupyter — AI Development Stack (JupyterLab with PyTorch)
Goal: Spin up a fully-equipped machine learning and data science environment.

Stack: A specialized developer workspace running JupyterLab powered by the comprehensive quay.io/jupyter/pytorch-notebook image.
Key Concepts: Managing large Docker image downloads, mounting persistent data scientist workspace volumes, and setting up Ingress reverse proxying for custom/non-standard container ports (port 8888).

https://github.com/mario-ezquerro/gubernator/tree/main/examples https://github.com/mario-ezquerro/gubernator/tree/main/examples

docker #gubernator #examples #orchestration

Examples Gubernator

Mario Ezquerro — Sat, 06 Jun 2026 09:18:33 +0000

Gubernator Orchestrator Update!

Just shipped some major improvements examples to Gubernator (the lightweight Go container orchestrator):

Premium Data Grid UI: Upgraded the Tasks Dashboard to PlutoGrid for interactive column resizing, filtering, and custom actions.
Dynamic Ingress Routing: Fixed port mapping to auto-detect and route traffic to custom container ports (like n8n, Qdrant, Ollama) instead of hardcoding port 80.
AI Automation Stack (n8n + Ollama + Qdrant): Added a complete RAG workflow example with automated LLM pulling and CoreDNS service discovery.
Simplicity of Docker Swarm meets the flexibility of Nomad!

Check it out: https://github.com/mario-ezquerro/gubernator

DEV Community: Mario Ezquerro

Building Enterprise Storage, Backups & Cosign Image Security in Go & Flutter with Google Antigravity

Building Enterprise Storage, Point-in-Time Backups & Cosign Image Security in Go & Flutter with Google Antigravity

Part 1: Persistent Storage & The Backup Subsystem (The Granaries)

1. Shared Storage Mobility (/var/contenedores)

2. Database-Consistent Snapshots with Docker Freeze

3. Automated Cron Policies & Retention Rotation

Part 2: Image Security, SBOM & Cosign Cryptography (The Imperial Seal)

1. Pure Go Cosign ECDSA Keypair Generation & Signing

2. Multi-Standard SBOM Generator (CycloneDX & SPDX)

3. Cluster-Wide Auto-Discovery & Host Mapping

Part 3: The Flutter Web Dashboard Visualization

Storage & Backups (The Granaries)

Image Security & SBOM (The Imperial Seal)

⚡ Part 4: Full CLI Parity

Part 5: How We Built This with Google Antigravity (AGY)

1. Specification-Driven Engineering

2. Autonomous Root-Cause Debugging

3. Live Cluster Deployment & Verification

🏁 Conclusion & What's Next

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

The Security Architecture

Role-Based Access Control (RBAC) Matrix

💻 The Go Backend Engine (internal/auth/)

1. Two-Phase Bind & Credential Verification

2. Dynamic Group-to-Role Mapping

The Flutter Web UI Experience

1. Modern Login Screen with Domain Selector

2. Active Directory Management & Diagnostics

3. Real-Time Role Badges & Contextual Guards

How Google Antigravity Accelerated Development

Conclusion & Open Source

Reviving Open Source Giants: How I Brought Weave Scope Back with Multi-Platform Docker Support in One Afternoon Using Antigravity

The Challenge: Brilliant Code Locked in the Past

The Catalyst: Antigravity as a Software Rescue Agent

The Modernized Multi-Arch Scope

Quick Start

[Boost]

Gubernator v2.13.0: Google SRE SLOs, Native CoreDNS Suite & Caddy Ingress for Docker Compose

Gubernator v2.13.0: Google SRE SLOs, Native CoreDNS Suite & Caddy Ingress for Docker Compose

1. Google SRE Multi-Burn-Rate SLO Engine & Web Suite

What makes Gubernator's SLO Suite unique?

SLO Ecosystem Comparison Matrix

2. Native CoreDNS 4-Tab Suite & Interactive Dig Playground

Key Features:

3. Caddy Ingress Suite & Zero-Trust Reverse Proxy

Features in the Caddy Suite:

Getting Started in Under 60 Seconds

3. Access Web Dashboards

Web UI Dashboard -> http://localhost:4001

Grafana -> http://localhost:3000

CoreDNS Playground -> http://localhost:4001 (CoreDNS tab)

Gubernator Weekly Update: CoreDNS Aqueducts, SRE Stack, Network Topology & Cluster Auto-Updates!i

Introducing Gubernator: The Goldilocks Container Orchestrator (Docker Swarm + Nomad Hybrid)

Introducing Gubernator: The Goldilocks Container Orchestrator

Technical Foundation

Building a Hybrid Docker Orchestrator in Go: The Journey from Single VM to Multi-Node Cluster

The Vision: Why Gubernator?

The Architecture: Multi-Node Setup

Decentralized Ingress & Localized Caddy Routing

Co-authoring with Antigravity (Google DeepMind)

Cluster Observability

Conclusion

Stop Copy-Pasting `dns:` Blocks: Introducing Transparent DNS Injection in Gubernator

Gubernator visual schema.

Excited to share the latest feature built for Gubernator (gbnt): Visual Stack Topology & Network Schema!

Gubernator E101 examples examples examplesss....

docker #gubernator #examples #orchestration

Examples Gubernator

1. Shared Storage Mobility (`/var/contenedores`)

💻 The Go Backend Engine (`internal/auth/`)