标签：#devops

TL;DR An AI agent registry is a centralized catalog of every agent in your organization — what each agent does, what tools it can access, what version is running, who owns it, and how to call it It's to agents what a container registry is to Docker images or what a service mesh is to microservices — the layer that makes distributed components governable We hit the "which agents do we have?" wall at 14 agents across 3 teams. That's when the registry stopped being a nice-to-have About four months into our agentic AI buildout, our head of security asked a question I couldn't answer: "Can you give me a list of every AI agent running in production, what systems they have access to, and what version of each is currently deployed?" I had a rough mental model. I knew about the agents my team had built. I had a vague idea of what the data engineering team had shipped. The product team had recently added two agents I'd heard about secondhand. I spent the better part of a day pulling together a spreadsheet. By the time I finished, one of the agents I'd listed had already been replaced by a newer version. Two of them had been granted access to an internal API I hadn't known about. The spreadsheet was outdated before I sent it. That was our forcing function for building a proper agent registry. This post is what I wish I'd read before that conversation happened. What an agent registry is An agent registry is a centralized catalog of AI agents — a single source of truth that tracks every agent deployed in your organization, its capabilities, its integrations, its ownership, and its current state. The analogy that landed for me: it's to agents what a container registry (Docker Hub, ECR, GCR) is to container images. When you have three containers running, you don't need a registry — you know what you have. When you have 40 containers across six teams, you need a registry to know what's running, who owns it, what version is deployed, and what depends on what. Agents are the same. At

The Post-Mortem Nobody Learns From I've sat through hundreds of post-mortems. Most follow the same pattern: something breaks, someone writes a Google Doc, we have a meeting, we list action items, nobody follows up, the same thing happens again in 3 months. Here's how to break the cycle. The Blameless Culture Trap "Blameless" doesn't mean "actionless." The biggest failure mode I see is teams that use blameless culture as an excuse to avoid accountability. Blameless means: we don't punish the person who pushed the bad deploy. Blameless does NOT mean: nobody is responsible for fixing the systemic issue. My Post-Mortem Template # Incident: [SERVICE] [SYMPTOM] on [DATE] ## Impact - Duration: X minutes - Users affected: N - Revenue impact: $X - SLO budget consumed: X% ## Timeline (UTC) - HH:MM - First alert fired - HH:MM - On-call acknowledged - HH:MM - Root cause identified - HH:MM - Fix deployed - HH:MM - Service recovered - HH:MM - All-clear declared ## Root Cause [2-3 sentences. Technical but readable.] ## Contributing Factors 1. [Factor that made the incident possible] 2. [Factor that made detection slow] 3. [Factor that made resolution slow] ## What Went Well - [Something that worked] - [Something that helped] ## What Went Wrong - [Process failure] - [Technical gap] ## Action Items | Action | Owner | Priority | Due Date | Status | |--------|-------|----------|----------|--------| | ... | ... | P1/P2/P3 | ... | Open | ## Lessons Learned [1-2 paragraphs of genuine insight] The Action Item Problem Action items from post-mortems have a 30% completion rate industry-wide. That's terrible. Here's why: Too many items (I've seen post-mortems with 15 action items) No clear ownership No deadline No follow-up mechanism Competing with feature work The Fix: Three Rules Rule 1: Maximum 3 action items per post-mortem. If you can't narrow it to 3, you haven't identified the real problems. Rule 2: Every action item gets a JIRA ticket linked to the next sprint. Not "someday." Not "bac

Most cloud platforms that need access to your infrastructure start with the same onboarding step: paste in a service account key. Or an access key and secret. Or a JSON blob you downloaded from the console and definitely should not be emailing to yourself. You paste it in. The platform stores it. You hope they encrypted it. You hope they rotate it. You hope nobody on their team can read it. You move on with your day and try not to think about it. We built Zero — b0gy's platform for engineering truth — around a different premise. For cloud infrastructure access — GCP and AWS — we don't store credentials at all. The platform connects to your projects and accounts using short-lived, federated identity tokens that are minted on demand and expire in minutes. There is nothing to leak because there is nothing stored. Not every integration can work this way. GitHub, Slack, and Jira use OAuth, which means we do hold tokens for those services. But for the highest-risk connections — the ones with read access to your entire cloud infrastructure — keyless was a hard requirement. This is the first post in a three-part series about building Zero. We're starting here because the connector model shaped everything else. Why stored secrets are the wrong default The argument for storing a service account key is convenience. You paste it once, the platform can access your cloud whenever it needs to. Simple. The argument against it is longer. A stored secret is a liability that compounds over time. The moment you paste a GCP service account key into a third-party platform, you've created a credential that is valid indefinitely, scoped to whatever permissions you granted, and stored in a system you don't control. If that platform gets breached — or if an employee with database access gets curious — that key works until someone revokes it. And nobody revokes it, because nobody remembers it exists. This isn't theoretical. The GitGuardian 2026 report found 28.65 million hardcoded secrets pus

The Argo CD project released a v3.5 release candidate in June 2026. This version adds mutual TLS enforcement for internal components. It also includes Git commit signature verification for supply chain security and native ApplicationSet management in the UI. The release also graduates two significant features: impersonation and Source Hydrator, from alpha to beta. By Claudio Masolo

Hi folks! I’m the architect behind WLOADCTL, a commercial workload scheduling system for enterprise automated task orchestration and RPA docking. A quick share of my daily work focus: Distributed task scheduling core development with Java & C Cross-system automation scripts built by Python & Shell Backend frontend based on SpringBoot + Vue3 Edge traffic protection & access optimization using Cloudflare Enterprise RPA integration to automate repetitive backend operations I’ve been tackling a lot of real-world pain points like cross-Linux distro compatibility, high-frequency API access security and mass task concurrency control recently. If you’re working on workload scheduling, backend automation or Cloudflare security tuning, feel free to leave a comment to chat!

The dogfood run went green. The gate had governed zero calls. That is the agent-governance-plane's entire job: run an AI coding agent inside a sandbox, route every tool call through a Unix-domain-socket gateway, and write a signed, hash-chained journal of every allow/deny. A green run that gated nothing isn't a pass. It's a governance plane governing air. The gate that catches its own hollowness AGP's CI dogfood doesn't just check that the harness exits 0. evidence-bundle.sh fails on a 0-gated run — if the journal shows no decisions, the build is red regardless of process exit status. That guard is what surfaced this at all: the agent process came up, the harness reported success, but the bundle had no verdicts to verify. Red. That's the last I'll say about hollow-green detection here. It's the door, not the room. The room is why zero calls reached the gate, and the answer turned out to be a collision between two things that look unrelated until you trace the syscall: Linux capabilities and a Unix socket's permission bits. The wrong theory The first hypothesis blamed the execution path. AGP has a dev-sandbox mode where the agent and the gate share a process, and a docker mode where the agent runs in a container talking to a host daemon over a bind-mounted socket. The theory was that the same-process path was short-circuiting the gate — agent and gate in one address space, the socket round-trip optimized away, decisions never journaled. Plausible. Wrong. The dev-sandbox path journaled fine in isolation. The failure only appeared in docker mode, and the moment that became clear the investigation moved from "which code path" to "what's different about the container." What's different about the container is the security posture. The real root cause: caps meet a missing write bit The short version: connecting to a Unix domain socket needs write permission on the socket file. --cap-drop ALL strips CAP_DAC_OVERRIDE — the capability that lets root ignore permission bits — s

This is a complete, copy‑pasteable guide for shipping a backend app to a single Linux server using Docker Compose , with a GitHub Actions pipeline that builds the image, scans it, and deploys it over SSH. It is written to be language- and framework-agnostic . The examples use a Node/TypeScript API with PostgreSQL, Redis, and a background worker, but the same shape works for Python/Django, Go, Java/Spring, Ruby, etc. Anywhere you see your-app , your-org , your-server-ip , or example.com , substitute your own values. Every file is included in full, and every non-obvious line is explained. The last section — Common errors and how to fix them — is the part most guides skip, and it is the part that will actually save your afternoon. All of it comes from a real deployment, mistakes included. 1. The mental model (read this first) Before any YAML, understand the shape of what we're building. There are only three places anything lives: Your Git repository the single source of truth. Your code, your Dockerfile , your docker-compose.prod.yml , and your CI/CD workflows all live here. You only ever edit things here. A container registry (we use GHCR, GitHub's built-in registry) — a warehouse for the built application image. CI builds the image and pushes it here. Your server (a plain Linux VPS) pulls the image from the registry and runs it. It holds exactly two files: the compose file (copied from your repo by the pipeline) and a secrets file ( .env ) that never leaves the server. The flow, end to end: You push to main │ ▼ GitHub Actions: build image ──► push to registry ──► scan image │ ▼ GitHub Actions: SSH to server ──► pull image ──► run migrations ──► start app ──► health-check The single most important rule: the server is disposable . You never hand-edit files on the server, because the pipeline overwrites them from the repo on every deploy. If you fix something by editing on the server, the next deploy silently erases your fix. Edit in the repo, commit, push. (I learned t

A follow-up to Part 1 ( EN on LinkedIn · RU on Habr ), where we stood up a two-tier PKI: a Root CA and three intermediate CAs — Person, Server and Code. At the end of Part 1 I promised we'd learn to revoke certificates and run OCSP. That's what we'll do here. Like Part 1, this article is meant as a hands-on manual : for every command and extension we touch, there's an extended reference of the parameters you can actually use — with syntax, allowed values, defaults and gotchas. If you don't need a given option right now, just skim past the table; it's there so you don't have to dig through man later. Each section has the same shape: first the working commands for the common case, then the full parameter reference. Tested on versions. Flag names, defaults and extension syntax were verified against the official documentation of OpenSSL master , plus nginx and Apache mod_ssl. OpenSSL evolves per branch: anything marked "OpenSSL 4.0 / master" (for example the nonss qualifier on authorityKeyIdentifier ) is not yet available in the stable 3.x line. If you're on OpenSSL 3.0–3.6, double-check the disputed options with openssl <cmd> --help or your version's man before copy-pasting config. The numeric openssl verify error codes above 40 also shifted between branches — confirm them against your version's header. In this part: How a revoked certificate differs from an expired one, and why we need two mechanisms — CRL and OCSP. Adding the distribution points (CDP) and AIA to the config so issued certificates "tell" verifiers where to check them. Revoking a certificate and working with the CA database. Generating a CRL and inspecting it with openssl crl . Checking revocation with openssl verify . Running an OCSP responder: issuing its certificate, starting the daemon, querying status. Publishing the CRL and OCSP over HTTP (nginx), configuring OCSP stapling and revocation checking on the web server. All paths, file names and config sections are the same as in Part 1. Where you name

A monorepo can look like one repository, but security teams should treat it as many applications living under one roof. One repo may contain 10 frontend packages, 5 backend services, 3 shared utility libraries, 2 mobile apps, and one root lockfile that does not tell the full story by itself. Monorepo dependency security means scanning the root dependency graph, every workspace package, shared libraries, lockfiles, and generated SBOMs. If you scan only one file, you may miss the vulnerable package that ships in production. Why Monorepos Create Unique Vulnerability Challenges Monorepos centralize multiple packages, apps, services, and libraries inside one repository. This improves code sharing, dependency alignment, refactoring, CI caching, and cross-team collaboration. It also creates a security problem: one repository can contain many different dependency trees, owners, deployment targets, and risk profiles. A typical JavaScript or TypeScript monorepo may include apps/web , apps/admin , apps/api , packages/ui , packages/auth , packages/logger , and packages/config . Each package may have its own package.json . Some packages are deployed to production. Some are internal libraries. Some are build-only tools. Some are used by every app. A vulnerability in one package can affect one app, many apps, or the whole repo depending on how dependency relationships are structured. The biggest issue is shared code. If packages/auth depends on a vulnerable version of jsonwebtoken , every application that imports packages/auth may be affected. If packages/ui uses a vulnerable utility such as lodash , every frontend app that consumes that UI package may inherit the same risk. If a build tool dependency is compromised, the risk may appear during CI/CD rather than runtime. Real CVEs show why this matters. CVE-2021-23337 affected lodash through command injection in template handling. CVE-2022-31129 affected moment through inefficient parsing that could cause denial of service. CVE-202

Grab's security team built Palana, a Kubernetes-native secure execution platform, to run autonomous AI agents safely. Unlike deterministic software, model-driven agents exhibit unpredictable tool-use, code-writing, and prompt injection risks. Palana contains these threats at the infrastructure level using isolated namespaces, out-of-process control planes, and proxy-mediated, Vault-backed secrets. By Patrick Farry

Hey Dev Community, If you are running enterprise-scale web scrapers, pricing monitors, or data ingestion pipelines for LLMs, you’ve probably spent sleepless nights dealing with network latency and sudden 403 blocks. When choosing an infrastructure partner, every provider pitches the same script: "99.9% uptime guarantees, millions of residential IPs, and lightning-fast response times." But in the trenches of real-world data collection, we all know that marketing numbers rarely match production reality. Last quarter, my team ran an exhaustive infrastructure audit to compare proxy providers pricing performance and infrastructure stability. If you want to dive straight into our live dataset, telemetry scripts, and interactive monitoring utilities, you can check out the full workbench at ProxyVero . Here is a technical breakdown of how we built our benchmarking matrix, and the architectural gaps we discovered across mainstream enterprise proxy services. 📊 1. The Core Metrics: Uptime vs. Success Rates The biggest lie in the networking industry is confusing Server Uptime with Request Success Rate . A proxy gateway server can maintain a 99.9% uptime while the underlying residential peer network is failing 20% of your data collection requests due to strict target WAFs or high peer churn. When conducting our proxy providers uptime guarantees performance benchmarks , we evaluated three core parameters: TCP Handshake Latency : The time it takes to establish a connection with the proxy endpoint. TTFB (Time to First Byte) : Critical for parsing dynamic JavaScript targets. HTTP Status Code Reliability : Tracking the exact ratio of 200 OK vs. 403 Forbidden / 429 Too Many Requests . ⚖️ 2. The Big Three: Oxylabs vs Bright Data vs SmartProxy Comparison To provide an objective proxy network performance benchmarks comparison , we deployed standard headless browser worker instances (Playwright/Puppeteer) routed through different enterprise gateways. Below is a high-level summary of our a

Why API Breaking Changes Still Reach Production Even With CI/CD A few years ago I watched a "tiny" API change take down checkout for about forty minutes. The change was a one-liner. The pull request had two approvals. CI was green across the board. And it still broke production, because the thing that actually mattered was never tested. If you run microservices at any real scale, you have lived some version of this. Let's talk about why it keeps happening even with a mature pipeline, and what the teams who don't keep getting paged do differently. The Problem Here's the change that caused the outage. A payments service had a response that looked like this: { "status" : "ok" , "transaction_id" : "txn_8842" , "amount_cents" : 4200 } Someone renamed amount_cents to amount and switched it to a decimal, because "cents is confusing." Cleaner field, better docs. The producing service's tests were updated to match, everything passed, it shipped. The problem: three downstream services still read amount_cents . One of them was the order service, which now received undefined , multiplied it by a quantity, and wrote NaN into the database. The failures didn't even surface in the payments service. They surfaced two hops away, in a service the original author had never opened. This is the core issue. A breaking change is not defined by the service that makes it. It's defined by the consumers who depend on it. And the producer's CI pipeline has no idea those consumers exist. Why Existing Approaches Fail The natural reaction is "we need more tests." But look at what each layer actually checks. Unit tests verify the code does what the author intended. The author intended to rename the field. The unit tests were updated to expect amount . They passed because they were testing the new, broken behavior. Green unit tests told us nothing. Integration tests verify the service works with its own dependencies — its database, its cache, the APIs it calls. They almost never spin up the services

TL;DR: An API gateway manages HTTP traffic between services — auth, routing, rate limiting, load balancing for REST and gRPC. An AI gateway manages LLM workloads — token-based rate limiting, model routing, cost attribution, semantic caching, guardrails. Use an API gateway for your microservices. Use an AI gateway for your LLM traffic. Most production teams eventually need both, sitting at different layers. This post walks through exactly where each one fits. When we started adding LLM features to our platform, we already had Kong running for our microservices. The instinct was natural: route the LLM traffic through Kong too. Same auth, same rate limiting, same observability stack. One gateway to rule them all. It worked — for about six months, and only in the sense that requests got through. What it didn't give us was anything useful for actually managing AI workloads. We had no idea what each team was spending on tokens. We had no way to set a budget cap that would fire before the bill arrived. Our rate limits were based on requests per minute, which meant a single request with a 50k token prompt counted the same as one with a 200 token prompt. And when OpenAI had a partial outage, Kong had no concept of "try Anthropic instead" — we just served errors. None of that is a criticism of Kong. It's doing exactly what it was designed to do. The problem was us expecting an API gateway to handle a fundamentally different category of infrastructure problem. Here's the precise distinction, and why it matters architecturally. What an API gateway actually does An API gateway is a reverse proxy that sits between client applications and backend services. It handles the cross-cutting concerns of service-to-service HTTP communication: authentication, authorization, rate limiting, load balancing, SSL termination, request transformation, and routing based on URL paths or headers. A typical request flow through an API gateway: Client sends a request to the gateway endpoint Gateway ve

The Problem I Kept Seeing Over the past year working across multiple client teams on DevOps and pipeline work, I kept noticing the same thing. Developers storing GitHub PATs in Notepad. QA engineers keeping API keys in a text file on the desktop. DevOps folks with database passwords in a sticky note app. During screen shares — sprint reviews, debugging sessions, pair programming, recorded demos — those credentials were just sitting there. Visible to everyone in the call. Nobody said anything. It just kept happening. Why Existing Tools Didn't Fit I looked for something simple that solved this. Here's what I found and why none of it quite worked: Password managers (1Password, Bitwarden) Good tools. But they're built around cloud sync, browser extensions, and team sharing. For an individual developer who just wants somewhere safe to keep a PAT — overkill. Also: corporate IT policies often block installation of cloud-synced password managers on work machines. Secret managers (HashiCorp Vault, AWS Secrets Manager) These are infrastructure tools, not personal workflow tools. Setting up Vault for an individual developer's PAT collection is like using a forklift to move a chair. OS keystores (Windows Credential Manager, macOS Keychain) Actually decent for storage. But no UI built for this workflow, no copy-to-clipboard, and they don't solve the screen-exposure problem at all. The gap: Something simple, local, and designed around the moment of use — not just storage. So I Built Tokenly Tokenly is a local-only desktop credential vault. The core design principle is simple: Credential values are never shown on screen. You copy them to clipboard. That's the only way to use them. The clipboard auto-clears after 30 seconds. If you need to visually verify a value — press and hold a button. Release it, the value hides immediately. Not a toggle — a hold. Toggles get forgotten. Holds don't. Technical Decisions Worth Explaining Why Tauri over Electron Tauri uses the operating system's

Introduction When a query runs in ClickHouse®, the database does much more than simply read data and return results. Before execution begins, ClickHouse® parses the SQL statement, analyzes it, applies optimizations, and builds an execution plan that determines the most efficient way to process the query. Understanding query execution plans is one of the most valuable skills for anyone working with ClickHouse®. They provide visibility into how queries are executed, helping you identify bottlenecks, validate optimization efforts, and troubleshoot performance issues. In this article, we'll explore how ClickHouse® generates execution plans, the different EXPLAIN modes, and how to interpret them for better query optimization. Why Query Execution Plans Matter A SQL query defines what data you want, but it doesn't explain how the database retrieves it. Consider the following query: SELECT country , count () FROM events GROUP BY country ; Although the query looks simple, ClickHouse® must determine: Which data parts to read Whether primary indexes can reduce the scan If data skipping indexes can be used How aggregation should be performed Whether parallel execution is possible How intermediate results should be merged A query execution plan provides answers to these questions, making it an essential tool for performance tuning. The ClickHouse Query Lifecycle Every query passes through several stages before producing results. The lifecycle typically looks like this: SQL Query │ ▼ Parser │ ▼ Analyzer │ ▼ Optimizer │ ▼ Query Plan │ ▼ Execution Pipeline │ ▼ Results Each stage plays an important role: Parser validates SQL syntax. Analyzer resolves tables, columns, and expressions. Optimizer applies query optimizations. Query Plan determines the logical execution steps. Pipeline distributes work across multiple threads. Execution processes the data and returns the results. Understanding this workflow makes execution plans much easier to interpret. Introducing the EXPLAIN Statement

Here's a thinking process: Analyze User Input: Role: Ghostwriter for Roberto Luna Osorio Editorial Profile: Developer Storytelling (primary), Build in Public, Técnico, Reflexivo. Philosophy: Share the process/learnings, not just the perfect result. Mandatory narrative questions: Problem, First attempt, What went wrong, How solved, What learned, What's next. Tone: First person, direct, honest, technical but accessible, curious. Avoid corporate jargon, clickbait, marketing hype, false modesty, empty summaries. Language: Spanish (natural/colloquial tech MX/LatAm) OR English (conversational, dev-friendly). Wait, the prompt says "English only (Dev.to is primarily English)" for this specific article. I'll stick to English as instructed for the Dev.to angle. Angle: TECHNICAL DEEP-DIVE ("HOW I BUILT IT"). Focus on code, architecture, specific files. Different from Medium's narrative style. Style: Technical, precise, code-forward. Real file/function names, error messages. First person but engineer-voice. English only. Mandatory Structure: TL;DR, The Problem, What I Tried First, The Implementation, Key Takeaway, What's Next. Length: 800-1200 words. Tags: #vibecoding #buildinpublic + relevant tech tags. Input Data: Repo: VS, Date: 2026-06-23. Commits show v1.6.0 sprint 1, booking reminders, /confirm/:token, notifications, bulk actions, pipeline v2. Files modified: booking-reminders.service.ts , booking.controller.ts , email.cron.ts , notifications.controller.ts , NotificationBell.tsx , confirm/[token]/page.tsx , ventas/pipeline/page.tsx , etc. Diffs show version bumps, cron integration, notification controller refactor, new components. Constraint: Do NOT repeat angles from this week: "El control de acceso y la caja negra de las publicaciones". Choose a completely different angle. Final Instruction: Write complete article. Start directly with TL;DR. Include actual code snippets. Do NOT write a story — write a technical breakdown. Map to Editorial Profile & Constraints: Profile

Our infrastructure "documentation" was a Google Sheet. Anyone on the team could edit it. Nobody...

One of the most confusing errors you can face while deploying a Node.js or Docker-based application is: fatal: Need to specify how to reconcile divergent branches At first glance, it looks like a Git bug. In reality, it is Git doing exactly what it should do, protecting you from overwriting history. In this article, I’ll break down a real production incident where a deployment failed due to divergent Git branches, how we diagnosed it, and the correct DevOps fix. The Problem A simple deployment script was running: git pull docker compose down --remove-orphans docker compose up --build -d But it failed with: fatal: Need to specify how to reconcile divergent branches This stopped deployment completely. What Git Was Telling Us To understand the issue, we ran: git rev-list --left-right --count HEAD...origin/main Output: 1 16 This means: 1 commit exists locally on the server 16 commits exist on GitHub So the branches had diverged. Why This Happens (Important) This usually happens when: Someone runs git commit directly on a server A previous deployment used git pull with merge commits History between local and remote is no longer linear Git refuses to guess whether you want to: Merge Rebase Or reject changes So it throws an error. Deep Diagnosis We inspected the commits: git log --oneline origin/main..HEAD Result: 6d9046b Merge pull request #222 Then: git log --oneline HEAD..origin/main Showed multiple new GitHub PR merges. Conclusion: The server was behind GitHub The “local commit” was already part of repo history No real production changes existed on server The Real Fix (Production Safe) For deployment servers, you should NEVER rely on git pull . Instead, use a deterministic reset: git fetch origin git reset --hard origin/main Then redeploy: docker compose down --remove-orphans docker compose up --build -d Why This Works This approach ensures: Server always matches GitHub exactly No merge conflicts in production No accidental local commits survive Fully reproducible depl

Zabbix is an open-source monitoring platform that tracks the health and performance of servers, networks, applications, and services, with built-in alerting and visualisation. This guide deploys the Zabbix server, web UI, agent, and MySQL database using Docker Compose, with Traefik handling automatic HTTPS for the dashboard. By the end, you'll have Zabbix monitoring its own host with a secured dashboard at your domain. Set Up the Project Directory 1. Create the project directory: $ mkdir ~/zabbix-docker $ cd ~/zabbix-docker 2. Create the environment file: $ nano .env DOMAIN = zabbix.example.com LETSENCRYPT_EMAIL = admin@example.com MYSQL_PASSWORD = YOUR_DB_PASSWORD MYSQL_ROOT_PASSWORD = YOUR_ROOT_PASSWORD Deploy with Docker Compose 1. Add your user to the Docker group: $ sudo usermod -aG docker $USER $ newgrp docker 2. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik restart : unless-stopped command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.le.acme.httpchallenge=true" - " --certificatesresolvers.le.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.le.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - /var/run/docker.sock:/var/run/docker.sock:ro - ./letsencrypt:/letsencrypt networks : - zabbix-net mysql-server : image : mysql:8.4.8 container_name : zabbix-mysql environment : MYSQL_DATABASE : zabbix MYSQL_USER : zabbix MYSQL_PASSWORD : ${MYSQL_PASSWORD} MYSQL_ROOT_PASSWORD : ${MYSQL_ROOT_PASSWORD} volumes : - ./mysql-data:/var/lib/mysql networks : - zabbix-net restart : unless-stopped zabbix-server : image : zabbix/zabbix-se

SeaweedFS is an open-source, distributed object storage system with an S3-compatible API, a filer for POSIX-style hierarchical access, and a small footprint. This guide deploys SeaweedFS using Docker Compose with the master, volume, filer, S3, and admin services behind Traefik for automatic HTTPS on separate admin and S3 domains. By the end, you'll have SeaweedFS serving S3-compatible object storage securely at your domains. Prerequisite: Two DNS A records pointing at the server — storage.example.com (admin dashboard) and s3.storage.example.com (S3 API). AWS CLI installed on your local machine for testing. Set Up the Directory Structure 1. Create the project directory: $ mkdir seaweedfs && cd seaweedfs 2. Generate an access key and a secret key (run twice and save both): $ openssl rand -hex 16 3. Create the environment file: $ nano .env STORAGE_DOMAIN = storage.example.com LETSENCRYPT_EMAIL = your-email@example.com ADMIN_PASSWORD = yourpassword 4. Create the S3 identities file: $ nano s3-config.json { "identities" : [ { "name" : "admin" , "credentials" : [ { "accessKey" : "YOUR_ACCESS_KEY" , "secretKey" : "YOUR_SECRET_KEY" } ], "actions" : [ "Admin" , "Read" , "Write" , "List" , "Tagging" ] } ] } Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yml services : traefik : image : traefik:v3.7.0 container_name : traefik restart : unless-stopped ports : - " 80:80" - " 443:443" volumes : - /var/run/docker.sock:/var/run/docker.sock:ro - ./letsencrypt:/letsencrypt command : - --providers.docker=true - --providers.docker.exposedByDefault=false - --entrypoints.web.address=:80 - --entrypoints.websecure.address=:443 - --entrypoints.web.http.redirections.entrypoint.to=websecure - --entrypoints.web.http.redirections.entrypoint.scheme=https - --entrypoints.web.http.redirections.entrypoint.permanent=true - --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL} - --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json - --