标签：#docker

A pattern keeps repeating itself in AI projects. The model works. The demo works. The proof of...

Every time I started a side project, I rebuilt the same five things before I wrote a single line of the actual idea: auth, a database, file uploads, a deploy pipeline, and TLS. Different domain, same plumbing. By the third project I was copy-pasting my own docker-compose.yml from a folder two repos over and renaming things until they stopped erroring. So I stopped. I froze that plumbing into one boilerplate — PocketBase + Next.js + Caddy on a single cheap VPS — and now I ship every side project on it. Same shape every time: clone, rename, write the part that's actually new, push. The thing I care about most isn't the speed, though. It's that I stopped paying for it. A handful of real projects now run on this setup for a few euros a month, total — not a stack of per-service SaaS bills that each want $25 here and $20 there before you've shipped anything. No Vercel seat, no managed Postgres, no Auth-as-a-Service, no object-storage line item. Here's the whole thing. Why this stack The trick that makes the cost collapse is PocketBase . It's a single Go binary that gives you, in one process: Auth — email/password, OAuth, the works, with a real users collection A database — SQLite, with a schema you manage from an admin UI Realtime — subscribe to collection changes over SSE File storage — uploads handled, with on-the-fly thumbnails An admin dashboard — at /_/ , for free That's four or five separate SaaS products collapsed into one binary that runs anywhere and stores everything in a folder. Compared to wiring up Supabase or Firebase, the mental model is tiny: it's one process and one data directory. Back up the directory and you've backed up the entire app — database, uploaded files, auth tokens, all of it. For the front I use Next.js (App Router, React Server Components) because that's where I'm fastest, and Caddy as the reverse proxy because it gets you automatic HTTPS with zero config — it provisions and renews Let's Encrypt certificates on its own. And it all lives on

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

My Previous Deployment Choices Since I mostly do web development using Ruby on Rails, these were my go-to options for deployment: PaaS like Heroku, Render, or Railway Serverless setups (Cloud Run + NeonDB) Honestly, I didn’t have any major complaints. PaaS costs a bit more, but in return, you get a clean UI and dead-simple workflows like GitHub integration. If the cost bothered me, I’d just go serverless. For my personal servers—where huge traffic isn't exactly a concern—going serverless meant the app would just sleep when inactive, allowing me to run services for around 50 yen a month. Compared to the headache of clicking through complex AWS or GCP dashboards to piece things together based on architecture diagrams, it was a walk in the park. I was perfectly content. Seriously. Kamal Became the Default in Rails 8 Everything changed when Rails 8 dropped. I heard they adopted Kamal as the official deployment tool. Kamal — Deploy web apps anywhere From bare metal to cloud VMs using Docker, deploy web apps anywhere with zero downtime. kamal-deploy.org Kamal? Is deploying really going to get any easier? I mean, I’m doing completely fine right now, though... That’s what I thought. But once I gave it a shot, it felt like being struck by lightning. This is an absolute game-changer. All you have to do is run rails new , throw your server's IP address into deploy.yml , and run kamal setup . That’s it—your app is deployed. For every release after that, it's just kamal deploy . I couldn't believe how simple the deployment workflow was. # deploy.yml service : my-app image : my-user/my-app servers : web : - 192.0.2.1 # Just swap in your VPS IP address here proxy : ssl : true host : app.example.com # Set up your domain here Sure, you have to bring your own server, but Kamal prides itself on being able to deploy absolutely anywhere. I rented a couple of VPS instances from Hetzner for about $10 a month each to host SuperRails and LazyCafe . From what I looked into, you can't really

📌 This article was originally published on Sherdil E-Learning . I'm republishing it here so the dev.to community can benefit too. The Kubernetes vs Docker question is one of the most common sources of confusion for developers entering DevOps. People hear both names constantly, see them used together in job listings, and assume they must be competitors. They are not. Docker and Kubernetes do different jobs, and most modern infrastructure uses both. This guide explains what each tool actually does, how they fit together in a real deployment, the practical difference between Docker Compose and Kubernetes, and which one you should learn first. Docker: the container creator Docker is a tool for building, running, and managing containers . A container is a lightweight, portable package that contains an application together with its dependencies, runtime, system libraries, environment variables, and configuration files. The same container runs the same way on a laptop, a CI runner, a production server, or a cloud platform. In a typical Docker workflow you: Write a Dockerfile that describes how to build the image Run docker build to produce the image Run docker run to launch a container from it For multiple containers (a web app plus a database, for example), you use Docker Compose to define the whole set in a docker-compose.yml file and start them with one command. Docker is excellent for individual containers and small multi-container applications. The limitation is scale. What happens when you need a hundred containers across a dozen servers? When one container crashes at 3 a.m.? When you need to roll out a new version without downtime? Docker alone does not solve those problems. For the official reference, see docs.docker.com . Kubernetes: the orchestration layer above Docker Kubernetes (often shortened to K8s ) is an open-source platform that runs containers across many machines as a single coordinated system . It was originally built at Google, based on their internal

1. Introduction to Docker One of the biggest historical challenges in software engineering has been environment inconsistency , the frustrating situation where an application works perfectly on one machine but unexpectedly fails elsewhere. And this is precisely the problem Docker was designed to solve. Docker is a containerization platform that packages applications and their dependencies into isolated environments called containers . Its goal is simple: Run applications consistently everywhere. Instead of configuring every machine manually, Docker packages everything an application needs to run. 1.1 What is Docker? Docker is a platform used to build, package, and run applications inside containers. A container includes: Application code Dependencies Runtime Libraries Configuration Simple mental model: Code + Dependencies + Runtime = Container This ensures applications behave the same way across development, testing, and production environments. 1.2 VMs vs Containers VMs (Virtual Machines) package: Application Dependencies Full Operating System Containers package only: Application Dependencies Runtime Containers share the host operating system kernel, making them much lighter and faster. Feature Virtual Machine Docker Container Includes OS Yes No Startup Speed Slow Fast Resource Usage Heavy Lightweight Size Large Small Simple analogy: Virtual Machine = Full House Container = Apartment in a Building 1.3 Docker Ecosystem Overview Docker includes multiple tools: Docker Engine The core service that runs containers. Docker Desktop A local GUI and development environment. Docker Hub A cloud registry for storing and sharing Docker images. Docker Compose A tool for running multiple containers together. Example: docker compose up Can start an entire application stack: Backend API Database Redis Frontend with a single command. 2. Docker Architecture & Fundamentals To use Docker effectively, it is important to understand how its core components work together. Docker follows a

The Setup I run a Proxmox 9 homelab (pve-manager/9.0.5, kernel 6.14.8-2-pve) and I needed to run Docker inside an LXC container — not a VM — to test a customer-style "bring-your-own-VPS" deployment path for a PaaS I'm building. The container had to act like a standard Ubuntu cloud VM: Docker, systemd, the works. LXC over a full VM gets me near-bare-metal performance, a fraction of the RAM overhead, and instant boots. The catch: the "Docker on LXC" recipes you'll find on most blog posts and Proxmox forum threads are out of date . They assume kernel 5.x and runc 1.1.x. On a modern Proxmox (kernel 6.14 + runc 1.2+ shipped with Docker 29) those recipes fail in two new and confusing ways before you even reach the workarounds we used to know about. This article walks through exactly what fails, why it fails, and the config that actually works in 2026 — plus an honest look at the security tradeoffs, because spoiler: the working config is privileged , and that matters. The Goal A Proxmox LXC container that can: Run docker run hello-world cleanly Pull and build complex images (multi-stage builds, overlay2 storage driver) Run nested containers with their own systemd Use systemd --user for per-service lingering processes Attempt 1: Unprivileged LXC (the path you "should" take) Conventional wisdom says: use unprivileged LXC. The container's root is mapped to an unprivileged UID on the host (typically 100000 ), so even a full container compromise can't escape to host root. Modern Proxmox makes this the default and recommended mode. I started with an unprivileged Ubuntu 25.04 container, added the now-standard features: pct set <vmid> -features nesting = 1,keyctl = 1,fuse = 1 Then inside the container, installed Docker from the official download.docker.com repo and ran: docker run --rm hello-world Here's what happened: docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start

You buy a NAS for silent, always-on storage. It sits in a corner, humming quietly, doing its thing. Then you install Docker. Then Syncthing. Then a few containers. Suddenly the HDDs never stop. Seeking, spinning, clicking. Not occasionally - constantly. At 2am you can hear it from the next room. This is what happened, why it happens, and how to make it stop. What's Actually Causing the Noise Mechanical HDDs make noise when the read/write head moves. The more random the I/O - small reads and writes scattered across the disk - the more seeking, the more noise. Sequential writes to a single file are quiet. Random I/O across thousands of small files is loud. Docker and Syncthing are both pathological for HDDs in different ways. Docker overlay2 Docker's default storage driver is overlay2. Every container runs on top of layered filesystems - the image layers are stacked, and a thin writable layer sits on top for each running container. Every file operation inside a container that touches a file from a lower layer triggers a copy-on-write : the entire file gets copied up to the writable layer before the write happens. On an SSD this is fast and silent. On spinning HDDs with mechanical heads, every copy-on-write is a seek, a read, and a write - often scattered across the disk. And it's not just copy-on-write. Docker's overlay2 metadata lives in small files across a deep directory tree. Container startup reads dozens of these. Log rotation writes to them. Health checks touch them. Any container doing anything at all generates constant scattered I/O. Syncthing's 60-Second Heartbeat Syncthing uses BoltDB as its internal database - it stores file indexes, sync state, and peer information there. BoltDB flushes to disk every 60 seconds regardless of whether anything changed. On a busy sync folder with thousands of files, this flush isn't a single sequential write. It rewrites pages across the B-tree structure, which means multiple seeks across the database file. Quiet when it's a

We've all been there. You're 45 minutes into a Docker tutorial, feeling great about yourself, and then someone casually drops: "Just pull the image and spin up a container." And you think: "...wait, aren't those the same thing?" First - this has happened to a good number of us if we are to be honest. Even almost every single DevOps engineer, cloud architect, and platform wizard you admire has typed the wrong term in a sentence at least once in their career. It's practically a rite of initiation. There should be a badge for it if you ask me. Why Does This Trip Everyone Up? Here's the sneaky truth: Docker commands blur the line constantly. You type docker run nginx and something called a "container" starts — but wait, didn't you just use an "image" called nginx ? Where did one end and the other begin? The confusion lives in the fact that they are deeply related — one literally gives birth to the other. But they are fundamentally, completely different things. Getting this distinction straight is your official rite of passage into DevOps. Once it clicks, the rest of Docker feels like cheating. Basically, A Docker Image is the blueprint : a frozen, static snapshot of everything your app needs - the OS layer, the dependencies, the config files, your actual code. It just sits there on disk, completely inert. You can't run a blueprint. A Docker Container is the house : the live, running instance that was built from that blueprint. It has processes running, files potentially being written, network ports being listened on. It's alive. And now, just like one blueprint can produce 10 identical houses on different streets - one Image can launch 10 identical Containers simultaneously; and that's where Docker's scaling magic comes from. # The image just sits here, unchanging docker pull nginx # Now we BUILD a house (container) from the blueprint docker run nginx # Build THREE houses from the same single blueprint docker run nginx docker run nginx docker run nginx Here is an exampl

There's a question that keeps surfacing across engineering teams — sometimes in architecture reviews,...

Building a Unix-Domain-Socket IPC server for ECS-on-EC2 services that need to talk fast, cheap, and reliably A while back I was looking at a flamegraph of a service that, on paper, should not have been having any performance problems. The producer and the consumer were the same Docker image's worth of trouble — colocated on the same EC2 host, in the same ECS cluster, sharing the same instance type, the same kernel, the same RAM. By every reasonable measure they were neighbours. And yet every event was making a round trip that looked roughly like this: producer → kernel TCP stack → ENI on the producer task → AWS VPC → internal load balancer → ENI on the consumer task → kernel TCP stack → consumer. TLS handshake. HTTP framing. JSON over the wire. Connection pool. Retry policy. The whole circus. I wasn't doing anything wrong. This is what the platform funnels you toward. ECS with awsvpc networking gives every task its own ENI. The default story for "service A talks to service B" is "give B a DNS name, put a load balancer in front of it, configure a security group, point A at the LB." Even if A and B are physically on the same box, the bytes are still leaving the kernel, traversing the VPC, and coming back. There's a fix for this. It's been a fix for fifty-something years. It just hasn't been the default fix, because cloud-native architecture grew up assuming services would be scattered across hosts and the network was the abstraction that mattered. This article is about building a proper IPC server using Unix Domain Sockets, deployed as a sidecar pattern on ECS-on-EC2, with a wire protocol robust enough to ship in production. We're going to design it from scratch — the transport choice, the wire format, the backpressure model, the failure modes, the deployment topology. I'll show you real pseudo-code from the implementation and call out the small number of places where, if you get it wrong, you'll spend a weekend debugging it. The intended outcome is something you coul

In Part 14 , I finished HMAC webhook signing. The backend was complete — JWT auth, PostgreSQL, Redis caching, rate limiting, circuit breaker, worker pool, webhook delivery, migrations, Docker. All running locally. But "runs on my machine" isn't a portfolio project. It's a homework assignment. Time to ship it. The Stack Being Deployed Go backend — ~15MB Docker image (multi-stage build, CGO_ENABLED=0) PostgreSQL 16 — with golang-migrate running schema migrations on startup Redis — for caching, rate limiting, and refresh token storage Oracle Cloud Free Tier — 1GB RAM, 45GB disk, already provisioned Everything wired together with docker-compose.yml . One command to start the entire stack. Step 1: The VM Was Fine, Actually I was worried about the free tier specs. Turned out the "1GB" in the tier name refers to RAM, not disk. The actual disk is 45GB — plenty. free -h # 954MB RAM, 552MB available df -h # 45GB disk, 41GB free The real constraint: no swap . Go's compiler is memory-hungry. Without swap, building the Docker image on the VM would exhaust RAM and kill the process. More on this in a moment. Step 2: Install Docker curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker ubuntu newgrp docker The official install script handles everything — Docker Engine, containerd, Docker Compose plugin. One command, done. Step 3: Clone the Repo The repo is private. Created a fine-grained GitHub personal access token with Contents: Read-only permission. Used it to clone: git clone https://TOKEN@github.com/absep98/Go_learn.git Security note: never paste tokens in chat, email, or anywhere visible. Type them directly into the terminal. Tokens in chat history are compromised tokens. Step 4: Create the .env File The .env from my local machine needed two changes for Docker: # LOCAL (wrong for Docker): DB_HOST = localhost REDIS_HOST = localhost # DOCKER (correct): DB_HOST = postgres # ← service name in docker-compose.yml REDIS_HOST = redis # ← service name in docker-compose.ym

For a while, my starter kits didn't include any Docker configuration. The foundation was solid with auth, roles, MFA, Horizon, Logs Viewer, but the deployment side was left to whoever cloned the project. That was a deliberate choice at first. Docker setups vary a lot depending on the infrastructure: some people use a reverse proxy, others have Cloudflare in front, some run on bare metal, others on managed platforms. I didn't want to ship something that would need to be ripped out immediately. But over time I changed my mind. Here's why and what the process taught me. The problem with "just configure it yourself" Leaving deployment out of a starter kit sounds reasonable. In practice, it means every project starts with the same 4-6 hours of Docker work that never really changes. Multi-stage Dockerfile. PHP-FPM config. Nginx with HTTPS. PostgreSQL and Redis wired up. Horizon and the scheduler running as proper services. Healthchecks everywhere so Docker knows when things are actually ready. None of it is so complicated. But it's time-consuming, easy to get subtly wrong, and almost identical from one project to the next. Once I admitted that, the question wasn't whether to include Docker, it was how to do it in a way that's actually useful without being too opinionated about production infrastructure. What I ended up building The setup I settled on covers the full local development stack: A multi-stage Dockerfile : separate stages for Composer dependencies, Node assets, and the final PHP-FPM image. Keeps the production image lean. Nginx with HTTP-to-HTTPS redirect and a self-signed certificate for local dev, already included, no setup needed. PostgreSQL and Redis as services with proper healthchecks. Horizon and the scheduler as dedicated services, not crammed into the main app container. A bootstrap service that runs php artisan migrate --force before the app starts. The Dockerfile uses three stages to keep the final image as lean as possible: FROM php:8.4-fpm-alpine A