标签：#docker

The Quest Begins (The "Why") Honestly, I was tired of playing “guess the state” every time I spun up a new environment. One day I clicked “Apply” in the AWS console, watched a handful of EC2 instances, S3 buckets, and IAM roles appear, and then realized I had no idea how to recreate that exact setup six months later when the team needed a staging copy. It felt like trying to rebuild the Death Star from memory after a single glance at the blueprints—frustrating, error‑prone, and definitely not the heroic saga I signed up for. That moment was my “aha!”: I needed a repeatable, version‑controlled way to describe infrastructure. Enter Infrastructure as Code (IaC). I’d heard the buzz, but the real question was which tool to wield—Terraform or CloudFormation? Both promised declarative provisioning, but they spoke different dialects. I decided to embark on a quest to learn both, slay the configuration drift dragon, and come out with a reusable spellbook I could share with anyone on the team. The Revelation (The Insight) The breakthrough came when I stopped thinking of IaC as “just another config file” and started seeing it as a storytelling language . Every resource block is a character, every variable a plot twist, and the state file the ever‑growing script that remembers what happened in previous chapters. When I wrote my first Terraform module, it felt like Neo realizing he could bend the spoon—suddenly the impossible became trivial. I could define a VPC, subnets, security groups, and an RDS instance in a few dozen lines, run terraform init , terraform plan , and watch the plan show exactly what would change before any resources touched the cloud. No more surprise “you created a public‑facing DB!” moments. CloudFormation, on the other hand, felt like the loyal sidekick that already lives in the AWS universe. Its JSON/YAML templates are native to AWS, so there’s no extra provider to install, and drift detection is built‑in. The trade‑off? A bit more verbosity and a steepe

Originally published on bckinfo.com Redis with Docker Compose: Persistence, Security, and Production-Ready Configuration Table of Contents Why Redis Containers Lose Data RDB vs AOF: Choosing a Persistence Strategy Basic Setup with Docker Compose Full Persistence Configuration Securing Redis in Docker Setting Resource Limits Redis in a Multi-Service Stack Backing Up and Restoring a Redis Volume Common Issues and Quick Fixes Closing Notes Redis is one of the most common services to run in Docker — it's fast to spin up, lightweight, and perfect for caching, session storage, and queues. But that same simplicity hides a trap: by default, Redis in Docker stores everything in memory, and the moment a container is removed, all of that data disappears . This guide walks through setting up Redis with Docker Compose the right way — covering persistence, authentication, resource limits, and the health checks you need before putting it anywhere near production. Why Redis Containers Lose Data A Docker container is meant to be disposable. That's a feature for stateless services, but it's a liability for a database like Redis. If you start a plain Redis container without a mounted volume, here's what happens: The container writes its dataset only inside its own writable layer. docker compose down or docker rm removes that layer entirely. The next time the container starts, Redis initializes with an empty dataset. This single oversight accounts for a large share of "we lost our session data" incidents in small teams running Redis in containers for the first time. The fix is straightforward once you understand the two persistence mechanisms Redis offers. RDB vs AOF: Choosing a Persistence Strategy Redis supports two persistence models, and production setups typically combine both: RDB (Redis Database snapshots) Point-in-time snapshots of the dataset, saved at intervals you define. Fast to restore, but you can lose any writes that happened after the last snapshot. AOF (Append Only Fil

In the previous article on hosting a Next.js app on a VPS , I'd left the deployment pipeline as a rough sketch: four lines to say "it ships to production on its own when you push." That's the piece I want to open up here, because it's what separates a VPS you fuss over by hand from infrastructure you can forget about. There's a stubborn myth that CI/CD is a big-company thing, with a dedicated DevOps team and six-figure tooling. Not true. The pipeline that deploys this portfolio fits in two YAML files, you can read it in five minutes, and it gives me back exactly the comfort I liked about Vercel: I push to master , I go grab a coffee, the app is live when I'm back. The one thing I gained along the way is knowing precisely what happens between the git push and the running container. Four steps, in this order Deployment is a chain. On every push to master , GitHub Actions runs lint, security scan, image build, and deploy. What matters is the needs : as long as a step fails, the following ones don't start. A critical vulnerability caught by the scan, and the image never gets built. At all. jobs : lint : # ESLint runs-on : ubuntu-latest # ... security : # Trivy scan (reusable workflow) uses : ./.github/workflows/security.yml build-push : # build the Docker image → push to GHCR needs : [ lint , security ] # ... deploy : # SSH to the VPS → docker compose pull && up -d needs : [ build-push ] # ... Lint first, because it's the cheapest step and there's no point building an image if ESLint is already screaming. The scan next, as a barrier. Then the build, which produces the Docker image and pushes it to GHCR, GitHub's container registry (private, in my case). And finally the deploy, which connects over SSH to the VPS, pulls the new image and restarts the container. Four links, each blocking the next. That's the whole secret. The security scan is in the path, not in a review "for later" This is the one I won't budge on. Dependency security, in a lot of projects, is a Dependabo

Vercel m'a longtemps convenu. Tu pousses ton code, trente secondes plus tard c'est en ligne avec un certificat valide, un CDN et des previews par branche. Pour démarrer un projet, je ne connais rien de plus confortable. Le problème arrive après, quand le projet vit. La facture grimpe avec le trafic et les fonctions serverless, certaines fonctionnalités propriétaires deviennent compliquées à reproduire ailleurs, et tu finis par ne plus vraiment savoir où ni comment ton app tourne. C'est un excellent point de départ, et un piège dès qu'on veut maîtriser son coût et son infra. Pour ce portfolio comme pour plusieurs projets clients, j'ai pris le chemin inverse. Un VPS à quelques euros par mois, une image Docker, un reverse proxy, un pipeline maison. L'idée n'est pas de revenir à l'âge de pierre du déploiement par FTP : je garde le « git push et c'est en ligne », mais sur une machine que je contrôle de bout en bout. Voici comment c'est câblé, et les deux ou trois endroits où je me suis fait avoir. L'image Docker : tout repose sur le mode standalone La pièce qui change tout, c'est output: "standalone" dans next.config.ts . Au build, Next trace exactement les fichiers nécessaires au runtime et les recopie dans .next/standalone/ . On passe d'une image d'environ 1 Go à environ 200 Mo. Sans ça, tu traînes tout node_modules dans ton conteneur de prod pour rien. Le Dockerfile est multi-stage : une étape pour installer les dépendances, une pour builder, une dernière qui ne garde que le strict nécessaire. # deps : installe les dépendances (cache Docker optimal) FROM node:22-alpine AS deps WORKDIR /app COPY package.json yarn.lock .yarnrc.yml ./ RUN corepack enable && yarn install --immutable # builder : build l'app FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && yarn build # runner : image finale, non-root FROM node:22-alpine AS runner WORKDIR /app ENV NODE_ENV=production RUN addgroup -g 1001 nodejs && a

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

n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job. How much server it actually needs Honest numbers first, so you don't over- or under-buy: ~2 GB RAM is the sweet spot — n8n plus its Postgres database plus normal workflows sit comfortably here. 1 GB works if your workflows are light, but you'll notice it on bigger runs. 4 GB if you do heavy parallel executions or push large payloads through. n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide .) The Docker setup On a fresh Ubuntu/Debian box, install Docker: curl -fsSL https://get.docker.com | sudo sh Make a folder and a docker-compose.yml — n8n with a persistent volume and Postgres: services : n8n : image : docker.n8n.io/n8nio/n8n restart : always ports : - " 127.0.0.1:5678:5678" environment : - N8N_HOST=n8n.yourdomain.com - N8N_PROTOCOL=https - WEBHOOK_URL=https://n8n.yourdomain.com/ - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=db - DB_POSTGRESDB_PASSWORD=change-me volumes : - ./n8n-data:/home/node/.n8n depends_on : [ db ] db : image : postgres:16 restart : always environment : - POSTGRES_PASSWORD=change-me - POSTGRES_DB=n8n volumes : - ./db-data:/var/lib/postgresql/data sudo docker compose up -d Two things worth pointing out: the volumes ( n8n-data , db-data ) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1 , not 0.0.0.0 — it's not exposed to the internet directly. That's deliberate; the next step handles access safely. Access: HTTPS or a tunnel Public URL (needed for OAuth nodes and webhooks): point a subdomain at the server and run

If you've ever wanted your AI coding agent to do more than just write code — to actually plan , validate , and cost-estimate real cloud infrastructure — the new Terraform Ops Kit for Docker Sandbox (sbx) is here to make that happen. This community-contributed kit, submitted to the docker/sbx-kits-contrib repository, brings a production-ready Infrastructure-as-Code (IaC) toolkit straight into the sandbox environment where agents like Claude, Gemini, GitHub Copilot, and Shell already run. What Is a Sandbox Kit? Docker Sandbox ( sbx ) is a runtime environment where AI agents operate. Kits are modular add-ons that extend the capabilities of those agents — think of them as pre-configured toolboxes that get installed automatically when a sandbox is created. The Terraform Ops Kit is a mixin kit , meaning it can be layered on top of any existing agent setup without replacing or conflicting with other kits. What's Inside the Kit? When the Terraform Ops Kit is activated, six tools are pre-installed and ready to use inside the sandbox: Tool Purpose Terraform Core IaC engine — plan, apply, and destroy infrastructure Terragrunt Terraform wrapper for DRY configurations and multi-account workflows tflint Linter for catching Terraform misconfigurations before they're applied Checkov Static analysis security scanner for IaC files Infracost Cost estimation — know the price tag before you deploy AWS CLI Interact with AWS services directly from the sandbox Together, these tools enable AI agents to autonomously carry out the full infrastructure development lifecycle: write Terraform code, lint it, scan it for security issues, estimate its cost, and plan the deployment — all without leaving the sandbox. Why This Matters Infrastructure work has traditionally required a human-in-the-loop at every step. You'd write the config, then manually run terraform plan , then check the security scan, then get a cost estimate — context switching across multiple tools. With the Terraform Ops Kit, an AI

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 :

MLflow is an open-source platform for managing the machine learning lifecycle — experiment tracking, model registry, and reproducible runs. This guide deploys MLflow using Docker Compose with a PostgreSQL backend, S3-compatible artifact storage, basic-auth, and Traefik handling automatic HTTPS, then logs a sample scikit-learn run. By the end, you'll have MLflow recording experiments at your domain over HTTPS. Prerequisite: An S3-compatible bucket (e.g. Vultr Object Storage) with access key, secret key, region, and endpoint URL. Set Up the Directory Structure 1. Create the project directory: $ mkdir -p ~/mlflow $ cd ~/mlflow 2. Create the environment file: $ nano .env DOMAIN = mlflow.example.com LETSENCRYPT_EMAIL = admin@example.com POSTGRES_USER = mlflow POSTGRES_PASSWORD = StrongDatabasePassword123 MLFLOW_AUTH_CONFIG_PATH = /app/basic_auth.ini MLFLOW_FLASK_SERVER_SECRET_KEY = GENERATED_SECRET_KEY S3_BUCKET = mlflow-artifacts S3_ACCESS_KEY = YOUR_ACCESS_KEY S3_SECRET_KEY = YOUR_SECRET_KEY S3_REGION = YOUR_REGION S3_ENDPOINT = https://YOUR_OBJECT_STORAGE_ENDPOINT 3. Create the basic-auth configuration: $ nano basic_auth.ini [mlflow] default_permission = READ database_uri = sqlite:///basic_auth.db admin_username = admin admin_password = ADMIN_PASSWORD authorization_function = mlflow.server.auth:authenticate_request_basic_auth 4. Create a Dockerfile that adds the auth-server extras and Postgres/S3 clients to the official image: $ nano Dockerfile FROM ghcr.io/mlflow/mlflow:v3.10.1 RUN pip install --no-cache-dir psycopg2-binary boto3 'mlflow[auth]' Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yml 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

LocalAI is an open-source platform for running Large Language Models locally with an OpenAI-compatible API, so you can swap it in behind existing OpenAI client code without paying per-token or sending data off-server. This guide deploys LocalAI using Docker Compose with Traefik handling automatic HTTPS, persistent model and cache directories, and a working chat-completion test. By the end, you'll have LocalAI serving an OpenAI-compatible API securely at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/localai/ { models,cache } $ cd ~/localai models/ holds downloaded model files; cache/ persists between restarts. 2. Create the environment file: $ nano .env DOMAIN = localai.example.com LETSENCRYPT_EMAIL = admin@example.com 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 environment : DOCKER_API_VERSION : " 1.44" 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 localai : image : localai/localai:latest-aio-cpu container_name : localai restart : unless-stopped volumes : - ./models:/models:cached - ./cache:/cache:cached healthcheck : test : [ " CMD" , " curl" , " -f" , " http://localhost:8080/readyz" ] interval :

LibreChat is an open-source, ChatGPT-style web UI that supports OpenAI, Anthropic, Azure OpenAI, Gemini, OpenRouter, local OpenAI-compatible endpoints, and more — with MongoDB-backed conversation history and Meilisearch-powered search. This guide deploys LibreChat using its official Compose manifest plus a Traefik override for automatic HTTPS. By the end, you'll have LibreChat running with a registration page and multi-provider chat at your domain over HTTPS. Clone LibreChat and Prepare the Environment 1. Clone the LibreChat repository and check out a stable tag: $ git clone https://github.com/danny-avila/LibreChat.git $ cd LibreChat $ git checkout tags/v0.8.3 2. Find the Meilisearch data directory name pinned by this release: $ grep -o 'meili_data_v[0-9.]*' docker-compose.yml | head -1 3. Create the required data directories (replace meili_data_v1.35.1 if the previous command printed a different name): $ mkdir -p data-node images logs meili_data_v1.35.1 uploads $ sudo chown -R 1000:1000 meili_data_v1.35.1 4. Copy the env template and uncomment the UID/GID lines: $ cp .env.example .env $ nano .env UID = 1000 GID = 1000 Override the Compose Stack with Traefik 1. Create a Compose override that adds Traefik and wires the API to it: $ nano docker-compose.override.yml services : api : labels : - " traefik.enable=true" - " traefik.http.routers.librechat.rule=Host(`librechat.example.com`)" - " traefik.http.routers.librechat.entrypoints=websecure" - " traefik.http.routers.librechat.tls.certresolver=leresolver" - " traefik.http.services.librechat.loadbalancer.server.port=3080" volumes : - ./librechat.yaml:/app/librechat.yaml traefik : image : traefik:v3.6.10 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.redirect

A few weeks ago I published corridor-lab — a Docker lab that proved a triage mismatch: a service that stores nothing sensitive can become high-priority because of where it sits in the path to a sensitive downstream system. The lab proved the premise. The next question was whether a tool could identify those nodes automatically — without manual path declaration, without value labels, from graph position alone. So I built corridor-id. You point it at a Docker Compose file. It discovers the topology, computes depth from exposed surfaces, and identifies which nodes expand forward reach into deeper parts of the environment. No asset-value labels. No sensitivity ratings. No human classification. Reach and graph position only. Then I pointed it at four architecturally different Docker environments. Two had corridor nodes. Two had none. Both answers were useful. But the zero-corridor results taught me more than the positive ones. What corridor-id does The tool reads a Docker Compose file and builds a reachability graph from service definitions, network memberships, and port mappings. It then orients that graph from exposed surfaces using BFS and identifies nodes that provide forward reach — access to strictly deeper nodes that the exposed surface cannot reach directly. The output is a ranked list with two metrics: exposure distance (how close to the surface) and forward reach gain (how many deeper nodes become reachable through this node). One command: python corridor-id.py docker-compose.yml No manual path declaration. No value labels. No configuration. From graph position alone. The four tests corridor-lab — segmented, depth 3 My own lab, five services across five segmented networks. The tool independently identified status-api as a corridor node — the same finding the lab was built to prove. Corridor nodes found: 3 → status-api Exposure distance: 1 Forward reach gain: 1 → log-monitor Exposure distance: 1 Forward reach gain: 1 → internal-admin-api Exposure distance: 2 For

The Quest Begins (The "Why") Picture this: I’m hunched over my laptop at 2 a.m., surrounded by empty coffee mugs, trying to get a simple Node.js API to run on a friend’s Windows machine. I’ve got the code, I’ve got the dependencies, but every time I hit npm start on his box I’m greeted with “Cannot find module ‘left-pad’” (yeah, I know, that’s a meme, but it felt real). It was like trying to cast a spell in Harry Potter while forgetting the wand‑movement — nothing happened, and I felt like a Muggle in a wizard’s duel. That night I realized the real dragon wasn’t the buggy code; it was the “it works on my machine” curse. I needed a way to package everything — the runtime, the libraries, the environment variables — into a single, portable chest that any teammate (or future‑me) could open and instantly get the same result. Enter Docker, the holy grail of reproducibility. If The Matrix taught us anything, it’s that once you see the underlying code, you can bend reality. Docker lets you see the container code and then bend your deployment reality to your will. The Revelation (The Insight) The big “aha!” came when I stopped thinking of Docker as just another VM and started seeing it as a lightweight, immutable snapshot of my app’s filesystem. Unlike a full VM that boots an entire OS, a Docker container shares the host kernel but isolates everything else — think of it as the Inception dream‑within‑a‑dream, but each layer is a read‑only snapshot you can stack like LEGO bricks. Here’s the secret sauce in three lines: Dockerfile – a recipe that tells Docker how to build the image. Image – the built, immutable artifact (the “DVD” of your app). Container – a running instance of that image (the “movie playing” from the DVD). When you docker build , Docker reads the Dockerfile line‑by‑line, creates intermediate layers, caches them, and finally spits out an image you can tag, push to a registry, and run anywhere. No more “it works on my machine” because the machine inside the cont

If you've ever heard the phrase "it works on my machine", you already understand the exact problem Docker was built to solve. Before Docker existed, deploying software was painful. Developers would spend hours — sometimes days — configuring servers, managing dependencies, and debugging environment-specific issues. Docker changed all of that by packaging applications and their dependencies into lightweight, portable units called containers. What Exactly Is a Container? Think of a container like a shipping container in the real world. No matter what's inside — electronics, furniture, food — it fits on any ship, truck, or train. In software, a Docker container holds your application code, runtime, libraries, and configuration, all bundled together so it runs identically anywhere: your laptop, a staging server, or a cloud provider. This is fundamentally different from virtual machines (VMs). While VMs emulate an entire operating system — making them heavy and slow to start — containers share the host OS kernel and start in milliseconds. They use far less memory and disk space, making them ideal for modern microservices architectures. The Core Docker Concepts You Need to Know Image : A read-only template used to create containers. Think of it as a recipe. You define it in a Dockerfile, and Docker builds it into an image. Container : A running instance of an image. You can run multiple containers from the same image simultaneously. Dockerfile : A plain text file with instructions for building a Docker image. Every command in the file adds a new layer to the image. Docker Hub : A cloud registry where you can find and share Docker images. It's like GitHub, but for container images. Docker Compose : A tool for defining and running multi-container applications using a YAML file. Your First Docker Commands Getting started with Docker is simpler than most developers expect. After installing Docker Desktop on your machine, you can run your first container with a single command: