标签：#devops

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 - --

Qdrant is an open-source vector database for AI applications, optimised for similarity search over high-dimensional embeddings, with a REST/gRPC API, payload filtering, and a built-in dashboard. This guide deploys Qdrant using Docker Compose with Traefik handling automatic HTTPS, API-key authentication, and a sample collection that runs a similarity search. By the end, you'll have Qdrant serving vector search securely at your domain. Set Up the Directory Structure 1. Create the project directory: $ mkdir -p ~/qdrant/data $ cd ~/qdrant 2. Generate a strong API key: $ openssl rand -hex 32 Save the value for the .env file. 3. Create the environment file: $ nano .env DOMAIN = qdrant.example.com LETSENCRYPT_EMAIL = admin@example.com QDRANT_API_KEY = PASTE_GENERATED_KEY_HERE Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --api.dashboard=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.letsencrypt.acme.httpchallenge=true" - " --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - " ./letsencrypt:/letsencrypt" - " /var/run/docker.sock:/var/run/docker.sock:ro" restart : unless-stopped qdrant : image : qdrant/qdrant:v1.17.1 container_name : qdrant expose : - " 6333" volumes : - " ./data:/qdrant/storage" environment : QDRANT__SERVICE__API_KEY : " ${QDRANT_API_KEY}" labels : - " traefik.enable=true" - " traefik.http.routers.qdrant.rule=Host(`${DOMAIN}`)" - " traefik.http.routers.qdrant.entr

Paperless-ngx is an open-source document management system that converts scans and PDFs into a fully searchable archive using Tesseract OCR, with tags, custom fields, and automated processing rules. This guide deploys Paperless-ngx using Docker Compose with PostgreSQL, Redis, and Traefik handling automatic HTTPS, then uploads a document and verifies OCR extraction. By the end, you'll have Paperless-ngx serving an OCR-indexed document archive securely at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/paperless-ngx/ { data,media,export,consume,pgdata } $ cd ~/paperless-ngx 2. Create the environment file: $ nano .env DOMAIN = paperless.example.com LETSENCRYPT_EMAIL = admin@example.com PAPERLESS_SECRET_KEY = CHANGE_TO_RANDOM_STRING PAPERLESS_URL = https://paperless.example.com PAPERLESS_TIME_ZONE = UTC PAPERLESS_OCR_LANGUAGE = eng PAPERLESS_DBPASS = STRONG_PASSWORD_HERE POSTGRES_DB = paperless POSTGRES_USER = paperless POSTGRES_PASSWORD = STRONG_PASSWORD_HERE Use the same value for PAPERLESS_DBPASS and POSTGRES_PASSWORD . PAPERLESS_SECRET_KEY should be a 32+ character random string. Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik 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.letsencrypt.acme.httpchallenge=true" - " --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - " ./letsencrypt:/letsencrypt" - " /var/run/docker.sock:/var/run/docker.sock:ro"

Overleaf is an open-source, collaborative LaTeX editor that bundles MongoDB, Redis, and the ShareLaTeX application into a single self-hosted stack. This guide deploys Overleaf Community Edition using the official Toolkit plus a Traefik override that adds automatic HTTPS via Let's Encrypt. By the end, you'll have Overleaf serving collaborative LaTeX editing securely at your domain. Set Up the Project Directory 1. Clone the Overleaf Toolkit: $ git clone https://github.com/overleaf/toolkit.git ~/overleaf-toolkit $ cd ~/overleaf-toolkit 2. Initialize the configuration: $ bin/init This creates config/overleaf.rc , config/variables.env , and config/version . 3. Create a directory for Traefik file-provider routes: $ mkdir traefik-routes Configure Overleaf for a Reverse Proxy 1. Edit config/variables.env : $ nano config/variables.env OVERLEAF_APP_NAME = "My Overleaf Instance" OVERLEAF_SITE_URL = https://overleaf.example.com OVERLEAF_NAV_TITLE = "Overleaf CE" OVERLEAF_BEHIND_PROXY = true OVERLEAF_SECURE_COOKIE = true The last two flags are required when Overleaf is fronted by an HTTPS reverse proxy. 2. Edit config/overleaf.rc : $ nano config/overleaf.rc SIBLING_CONTAINERS_ENABLED = false 3. Create the project-level .env file used by the Traefik Compose file: $ nano .env DOMAIN = overleaf.example.com LETSENCRYPT_EMAIL = admin@example.com SERVER_IP = 192.0.2.1 SERVER_IP should be the server's public IP (Traefik binds 80/443 to it). Add the Traefik Route 1. Create the dynamic route: $ nano traefik-routes/overleaf.yml http : routers : overleaf : rule : " Host(`overleaf.example.com`)" service : overleaf entryPoints : - websecure tls : certResolver : le services : overleaf : loadBalancer : servers : - url : " http://sharelatex:80" 2. Create the Traefik Compose file: $ nano docker-compose.traefik.yml services : traefik : image : traefik:v3.6 container_name : traefik restart : unless-stopped command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --

Ory Kratos is an open-source, API-first identity and user management system handling registration, login, recovery, verification, and session management with a self-service UI. This guide deploys Kratos using Docker Compose with PostgreSQL, the self-service UI Node, and Traefik handling automatic HTTPS for the public API. By the end, you'll have Kratos managing identities and sessions for users registering through your domain over HTTPS. Prerequisite: SMTP credentials are required for verification and recovery emails. The admin API stays bound to 127.0.0.1 on purpose — never expose it publicly. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/ory-kratos/ { config,data/postgres } $ cd ~/ory-kratos 2. Create the environment file: $ nano .env DOMAIN = kratos.example.com LETSENCRYPT_EMAIL = admin@example.com KRATOS_VERSION = v26.2.0 POSTGRES_USER = kratos POSTGRES_PASSWORD = EXAMPLE_DB_PASSWORD POSTGRES_DB = kratosdb LOG_LEVEL = info 3. Create the identity schema — defines the user fields (email + name) and how the email maps to login, recovery, and verification: $ nano config/identity.schema.json Use the schema described in the Vultr Docs walkthrough — email is the login identifier with password auth; name is a free-text trait. 4. Create the Kratos configuration — public/admin API URLs, password policy (12-char minimum + HaveIBeenPwned), session lifetimes, self-service flows, SMTP courier: $ nano config/kratos.yml Fill in the full configuration from the source article. Key points to keep consistent with the stack below: Public API listens on the internal port and is fronted by Traefik on ${DOMAIN} . Admin API listens on 127.0.0.1:4434 only — used by tooling on the host. The DSN points at the postgres service ( postgres://kratos:...@postgres:5432/kratosdb?sslmode=disable ). The courier section uses your SMTP provider for verification mail. Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yml services : traefi

NocoDB is an open-source no-code platform that puts a spreadsheet-style UI on top of a relational database, with grid, form, Kanban, and gallery views plus a REST API. This guide deploys NocoDB using Docker Compose with a PostgreSQL backend and Traefik handling automatic HTTPS, then exercises the API with a sample base. By the end, you'll have NocoDB serving a base over HTTPS with API access at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/nocodb/ { data,pgdata,letsencrypt } $ cd ~/nocodb 2. Create the environment file: $ nano .env DOMAIN = nocodb.example.com LETSENCRYPT_EMAIL = admin@example.com POSTGRES_DB = postgres POSTGRES_PASSWORD = strong_password POSTGRES_USER = postgres Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik 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.letsencrypt.acme.httpchallenge=true" - " --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - " ./letsencrypt:/letsencrypt" - " /var/run/docker.sock:/var/run/docker.sock:ro" restart : unless-stopped db : image : postgres:16 container_name : nocodb-db hostname : root_db environment : POSTGRES_DB : ${POSTGRES_DB} POSTGRES_USER : ${POSTGRES_USER} POSTGRES_PASSWORD : ${POSTGRES_PASSWORD} volumes : - " ./pgdata:/var/lib/postgresql/data" healthcheck : test : [ " CMD" , " pg_isready" , " -U" , " ${POSTGRES_USER}" , " -d" , " ${POSTGRES_DB}" ] interval : 10s timeout : 5s retries :