DEV Community: Mihai Farcas

Do You Need Rancher Desktop (or Docker Desktop) on Linux? My CachyOS Setup

Mihai Farcas — Wed, 14 Oct 2026 09:58:35 +0000

Originally published on mihai.ltd.

Like everyone, I switched to CachyOS from Windows. Now I can say "I use Arch, by the way." But does native Linux still need a desktop container manager?

Like everyone else in the homelab and systems engineering community, I switched to CachyOS from Windows. I wiped the workstation, configured my NVMe drives on Btrfs, and can now say "I use Arch, by the way."

Moving to an Arch-based distribution with optimized x86-64-v3 packages, zram, and the BORE (Burst-Oriented Response Enhancer) CPU scheduler changes your baseline expectations. Everything executes with zero latency.

That speed brings up a fundamental question for daily container workflows: Do you actually need Rancher Desktop—or Docker Desktop—on Linux?

On Windows and macOS, the answer is straightforward. Neither operating system can run Linux containers natively. They both require a virtualization layer: WSL2 on Windows or the Apple Virtualization framework on macOS. If you work on Windows, a dedicated manager is mandatory, as detailed in my companion guide on Rancher Desktop on Windows.

On Linux, your operating system is the kernel. Containers are standard Linux processes isolated by kernel cgroups, namespaces, and seccomp profiles.

Running a desktop container manager on Linux creates trade-offs every engineer should weigh before setting up a workstation.

1. The Peculiar Architecture of Docker Desktop on Linux

To understand why running desktop container suites on Linux feels counterintuitive, examine how Docker Desktop operates on the platform.

When you install Docker Desktop on Linux, it does not manage your host kernel's container runtime directly. Instead, Docker Desktop spins up a dedicated virtual machine inside QEMU.

Running a virtual machine on a native Linux host introduces distinct penalties:

Nested Virtualization Overhead: You run Linux on bare metal, yet your container workloads execute inside a second, virtualized Linux kernel.
Artificial Resource Caps: You must carve out CPU cores and RAM for the VM upfront, recreating the exact memory contention that Linux developers avoid.
Storage and File I/O Latency: Host volume mounts cross virtualized filesystem bridges instead of using direct VFS page cache bind-mounts.
Commercial Licensing Exposure: If your organization employs more than 250 people or generates over $10 million in annual revenue, Docker Desktop requires paid per-seat subscriptions.

In our Tech Radar evaluation of Docker Desktop, we formally rejected Docker Desktop because of update instability and commercial licensing overhead. On Linux, adding a QEMU virtualization layer on top of a native Linux kernel makes the proposition even harder to justify.

2. Where Rancher Desktop on Linux Makes Technical Sense

Rancher Desktop takes a different path: fully open-source under the Apache 2.0 license, backed by SUSE, and listed under Adopt on our Tech Radar.

On Linux, Rancher Desktop runs through QEMU or container isolation. While a bare-metal daemon delivers lower latency for standard web development, Rancher Desktop serves four distinct engineering use cases on Linux workstations:

1. Disposable, Multi-Version Kubernetes Sandboxes

Testing Helm charts, operators, and Kubernetes manifests across diverse cluster versions is cumbersome when managing bare-metal k3s systemd services.

Rancher Desktop lets you select exact Kubernetes releases (from v1.26 to v1.32) through a dropdown. When an experiment leaves behind broken CRDs or orphaned namespaces, clicking Reset Kubernetes returns the cluster to a clean state in under 20 seconds without touching your host system packages.

2. Fleet Parity Across Mixed-OS Engineering Teams

In enterprise engineering organizations, developers rarely run identical operating systems. Half the team runs macOS, others run Windows with WSL2, and some run Linux.

Standardizing on Rancher Desktop allows platform teams to distribute identical configuration profiles (rancher-desktop.json). Every engineer gets the same container engine defaults (dockerd or containerd), the same bundled utilities (Helm 4.2, Trivy 0.72, Docker CLI 29.6), and identical Traefik ingress routing, regardless of host OS.

3. Isolated Sandboxing for Untrusted Containers

If you audit external container images or test third-party tools, running them directly against your host Docker socket exposes your root system to container escapes.

Rancher Desktop contains workloads inside an isolated runtime boundary, shielding your primary Linux host from disk exhaustion, network sniffing, and permission exploits.

4. The Headless 2.0 Architecture

As highlighted in the recent Rancher Desktop 2.0 Alpha 1 release notes, the project is decoupling from Electron. Version 2.0 introduces a headless mode that allows engineers to run container management and K3s clusters as a background service. On Linux, this brings declarative, scriptable container orchestration to headless development servers and CI runners without desktop UI overhead.

3. My Daily Driver Container Setup on CachyOS

When developing services locally on CachyOS, I target execution speed, direct disk throughput, and minimal background resource drain.

Here is the exact container stack running on my machine:

[ CachyOS Bare-Metal Workstation ]
  │
  ├── Kernel: Linux CachyOS (BORE Scheduler + x86-64-v3 packages)
  ├── Filesystem: Btrfs with zstd:1 compression (Direct NVMe I/O)
  │
  ├── Native Container Runtime:
  │     ├── Engine: docker-ce (systemd service)
  │     ├── Socket: /var/run/docker.sock (User Group: docker)
  │     └── CLI Tools: docker, docker compose, nerdctl
  │
  ├── Terminal UI:
  │     └── lazydocker (Instant container, log, and volume monitoring)
  │
  └── Local Kubernetes:
        ├── Fast Labs: k3d / kind (Ephemeral clusters on Docker)
        └── Production Parity: Rancher Desktop (Isolated K3s with Traefik)

Step 1: Installing Native Docker Engine on Arch / CachyOS

Instead of wrapping the engine in an Electron application, install the native Docker packages from the official repositories:

sudo pacman -S docker docker-compose

Enable the systemd service and socket:

sudo systemctl enable --now docker.service

Add your user to the docker group to drop sudo requirements for daily commands:

sudo usermod -aG docker $USER

Log out and back in, or run newgrp docker to apply the group membership.

Step 2: Filesystem Integration with Btrfs

CachyOS defaults to Btrfs, which integrates cleanly with Docker's btrfs storage driver. Docker leverages native subvolumes and copy-on-write (CoW) snapshots for container layers, making image pulls and build cache lookups immediate while conserving NVMe write cycles.

Check your active storage driver:

docker info | grep "Storage Driver"

If it shows btrfs or overlay2, your setup uses native Linux filesystem snapshots directly on disk without virtual disk translation.

Step 3: Installing Native K3s and Running at Startup

For local Kubernetes, you do not need to wrap clusters inside an Electron app. Install native K3s directly via the official script:

curl -sfL https://get.k3s.io | sh -

The installer configures /usr/local/bin/k3s and registers a systemd unit at /etc/systemd/system/k3s.service.

To ensure the cluster starts automatically with your workstation:

sudo systemctl enable k3s.service

To configure kubectl access for your current user:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config

Step 4: Real-World Resource Consumption: Why Idle K3s Stays On

A common concern with running Kubernetes locally is memory drain. Here are the measured numbers from my active CachyOS workstation:

Baseline Idle Footprint: Running bare K3s (control plane, CoreDNS, metrics-server, Traefik ingress, and local-path-provisioner) consumes 500 MB to 700 MB of RAM and negligible CPU (<1%).
Full Platform Lab Footprint: On my machine, K3s runs over 60 active pods: Argo CD, Argo Workflows, CloudNativePG, Gitea, Grafana Alloy/Loki/Mimir, KEDA, n8n in queue mode, SeaweedFS, and Zitadel. Even under this workload, the entire k3s.service cgroup sits at 3.3 GB of RAM.

On a 60 GB RAM workstation paired with CachyOS's BORE scheduler, 3.3 GB represents roughly 5.5% of total memory. Because memory pressure remains near zero, stopping and starting the cluster between coding sessions offers no tangible performance gain. Leaving it idling in the background is the most practical choice.

Step 5: Bringing Down and Bringing Back Up K3s Without Losing Volumes

When you do need to shut down the cluster—such as before major kernel upgrades or offline backups—you must ensure stateful databases (PostgreSQL, SeaweedFS, Gitea) do not suffer corrupted data or broken volume attachments.

Where Data Actually Lives

K3s uses the embedded Rancher local-path-provisioner. When a pod requests a PersistentVolumeClaim (PVC), the provisioner creates a host directory at:

/var/lib/rancher/k3s/storage/pvc-<volume-uuid>

Stopping K3s never deletes these directories. The storage stays intact on disk until you explicitly run kubectl delete pvc <name>.

Safe Shutdown Procedure

To shut down cleanly without leaving orphaned network interfaces or corrupting database write-ahead logs (WAL):

Graceful Service Stop:

   sudo systemctl stop k3s

Systemd issues a SIGTERM signal, allowing K3s and containerd shims time to flush file writes and stop containers cleanly.

The Clean Reset Fallback (If Processes or CNI Hang): If a container hangs or CNI network interfaces (cni0, flannel.1) fail to detach during an abrupt restart, run K3s's built-in cleanup script:

   sudo /usr/local/bin/k3s-killall.sh

This script kills leftover containerd shims and deletes stale CNI bridge interfaces, but does not touch /var/lib/rancher/k3s/storage. Your databases and persistent data remain safe.

Bringing the Cluster Back Up

To restore the cluster:

sudo systemctl start k3s

Verify that all workloads and volumes recover:

k3s kubectl get pods -A
k3s kubectl get pvc -A

Kubelet restarts, inspects existing volume definitions, re-binds the local storage paths, and brings every application back online without data loss.

Step 6: Terminal-First Observability with `lazydocker`

For standalone containers running outside K3s, I avoid heavy Electron wrappers and inspect running containers, stream logs, and prune stale images through lazydocker:

sudo pacman -S lazydocker

Launching lazydocker inside a terminal window consumes under 30 MB of RAM while providing real-time CPU and memory graphs, top processes, and interactive shell attach capabilities.

4. Comparing the Architectural Options on Linux

Dimension	Native Linux Docker / containerd	Rancher Desktop on Linux	Docker Desktop on Linux
Virtualization	None (Direct host kernel)	Isolated VM / sandbox	QEMU virtual machine
File I/O Latency	Native NVMe disk speed	Virtualized bridge latency	9P bridge latency
RAM Footprint (Idle)	~60 MB	~1.5 GB (with K3s)	~2.5 GB (with VM & UI)
Kubernetes Support	Requires k3d, kind, or bare k3s	Built-in K3s with version selector	Built-in single-node Kubernetes
Licensing	100% Free & Open Source	100% Free & Open Source (Apache 2.0)	Paid subscription required for large orgs
Primary CLI	`docker`, `docker compose`, `nerdctl`	`rdctl`, `nerdctl`, `docker`	`docker`, `docker compose`
Best For	Daily development, peak performance	Multi-version K8s testing, mixed-OS teams	Legacy enterprise compliance only

5. Which Path Should You Choose?

Your choice depends on team structure and daily workflow requirements:

Choose Native Linux Docker / containerd if your priority is development velocity, battery life, and raw performance on an Arch, CachyOS, Fedora, or Ubuntu desktop. Your builds run directly against the Linux page cache, and docker compose up starts in milliseconds.
Choose Rancher Desktop if you maintain complex Kubernetes workloads, frequently test upgrades across Kubernetes versions, or need identical operational workflows across a distributed team running Windows, macOS, and Linux.
Avoid Docker Desktop on Linux unless your organization enforces it through mandatory enterprise device policies. Running a QEMU virtual machine on top of a Linux kernel reintroduces performance bottlenecks that the operating system natively eliminates.

Related Guides & Architectural Reviews

Windows Setup Guide: Rancher Desktop on Windows: The Complete Zero-License Replacement for Docker Desktop
Tech Radar Adoption Report: Rancher Desktop (Adopt)
Tech Radar Reject Report: Docker Desktop (Reject)
Kubernetes Storage Deep Dive: Mount Local Storage to Kubernetes Pods with K3s

This article first appeared on mihai.ltd. Read the original for the full version.

About the author

I'm Mihai Farcas, a software architect with over a decade of experience building and scaling production systems. I write about Kubernetes, n8n workflow automation, AI agents and local LLM infrastructure, and I share the good results and the face-palm moments alike.

On my YouTube channel, Let's Talk Dev, I break down complex engineering concepts and the experiments behind these articles.

Connect with me:

Website and blog: mihai.ltd
YouTube: @letstalkdev
GitHub: mihailtd
LinkedIn: Mihai Farcas

n8n + Argo = ❤️: Offloading CPU-Heavy Steps to Argo Workflows

Mihai Farcas — Mon, 12 Oct 2026 06:28:54 +0000

Originally published on mihai.ltd.

Hand heavy steps from n8n to Argo Workflows, release the worker slot, and let a pod do the compute.

n8n and Argo Workflows each do a different job well, and together they cover each other's gaps.

n8n handles event-driven orchestration: it connects hundreds of SaaS APIs, listens to webhooks, transforms JSON payloads, and manages human-in-the-loop approvals.

Argo Workflows runs heavy, isolated container jobs on Kubernetes: batch jobs, video transcoding, and ML pipelines, each in its own pod.

A CPU-heavy step does not belong in an n8n worker's Node.js event loop. Let n8n hand the job to Argo, release its worker slot with a Wait node, and resume when the Argo pod calls back.

In my k3s lab, ten concurrent 30-CPU-second jobs finished with a median execution time of 81 seconds. The n8n workers peaked at 0.07 CPU cores, and a light neighbor workflow kept its baseline queue wait. This article covers the failure that motivates the pattern, the pattern itself, and the lab data.

What does the lab run?

The cluster is the one from the KEDA article: single-node k3s, n8n 2.40.5 in queue mode (main, two webhook processors, KEDA-scaled workers with a concurrency of 10 and a CPU limit of 1 core each), PostgreSQL on CloudNativePG, Valkey as the queue, all deployed by Argo CD. I added Argo Workflows 4.1.4 in a single namespace.

The test job is a synchronous JavaScript loop: xorshift over a 256 MiB typed array, calibrated so one unit costs about one CPU-second on this machine. Both variants run the identical function, so the only difference is where it runs:

Inline. A webhook triggers a workflow with one Code node that calls heavy(units).
Offloaded. A webhook triggers a workflow that submits an Argo Workflow running the same function in a node:26-alpine pod with 1 CPU and 512 MiB, then waits for the pod to call back.

k6 fires 10 jobs at once. At the same time it runs a light neighbor workflow at one execution per second: a 6-second HTTP call, the shape of a typical SaaS sync. That neighbor measures what the heavy jobs do to unrelated work. Timings come from n8n's execution_entity table (queue wait is startedAt minus createdAt) and worker CPU from the metrics API.

Each scenario ran once with 10 jobs, so read the numbers as shapes, not benchmarks. The machine is a 12-core, 24-thread workstation that also runs the rest of the lab.

What breaks when a Code node does heavy work?

At 30 CPU-seconds per job, 9 of the 10 executions failed with Task execution aborted because runner became unresponsive. The one that succeeded finished in 29 seconds. At 10 CPU-seconds per job the result was the same: 1 of 10. At 5 CPU-seconds per job all 10 passed.

Inline, default runner settings	Executions ok	Median execution time
5 CPU-seconds per job	10/10	44 s
10 CPU-seconds per job	1/10	n/a
30 CPU-seconds per job	1/10	n/a

The cause sits in how n8n runs Code nodes. With the default N8N_RUNNERS_MODE=internal, the worker launches a task runner as a child process, and ps in the worker pod shows it as a second Node process next to n8n worker. The runner has one event loop. When the task broker offers the runner a task, the runner has to acknowledge it within N8N_RUNNERS_TASK_ACCEPT_TIMEOUT, which defaults to 2 seconds in n8n 2.40.5. A runner stuck in a synchronous loop cannot acknowledge anything. After three consecutive missed acknowledgements the broker declares the runner unresponsive and restarts it, and every task running on it aborts. The worker log shows the sequence:

Runner (4w6aiSeMoixrVB-hWUW7J) took too long to acknowledge acceptance of task (hC9eTMmw)
Task runner failed heartbeat check, restarting...
Task execution aborted because runner became unresponsive

The default N8N_RUNNERS_MAX_CONCURRENCY is 5 tasks, but one thread cannot run a synchronous loop for a second task until the first one returns, so concurrency inside the runner is nominal for CPU-bound code. At 5 CPU-seconds per job the runner survived and the ten jobs finished in sequence, in about 50 seconds. I did not bisect the failure threshold between 5 and 10 CPU-seconds.

Can you tune your way out?

Partly. I raised the four runner limits on the workers (N8N_RUNNERS_TASK_ACCEPT_TIMEOUT, N8N_RUNNERS_HEARTBEAT_INTERVAL, N8N_RUNNERS_TASK_TIMEOUT and N8N_RUNNERS_TASK_REQUEST_TIMEOUT, all to 900 seconds) and set N8N_RUNNERS_MAX_CONCURRENCY=10. All ten 30-second jobs then succeeded, with a median execution time of 305 seconds.

That number is the problem. The runner processes one synchronous task at a time, so ten 30-second jobs take about 300 seconds on a worker, and the others sit inside the runner while the worker shows free slots. KEDA saw almost no backlog. Its Redis trigger watches the waiting list, and the tasks queued inside the runner never appear there, so the Deployment peaked at 2 workers. Adding CPU to the pod does not help either, because a single-threaded runner cannot use more than one core.

Tuning turns failures into a serial queue. It also removes the protection the limits provide: a task that hangs now holds a runner for 15 minutes.

How does the offload work?

The offloaded workflow has three nodes. The flow:

Submit. An HTTP Request node posts to the Argo server's submit endpoint, naming a WorkflowTemplate and passing the job parameters plus the execution's resume URL.
Wait. A Wait node set to resume on a webhook call saves the execution and releases the worker.
Callback. When the job ends, an exit handler in the Argo Workflow posts the status to the resume URL, and n8n continues the execution.

The submit call is a plain REST request. The body names the template and passes $execution.resumeUrl, the unique URL n8n generates for the Wait node of that execution:

POST http://argo-workflows-server.argo-workflows.svc:2746/api/v1/workflows/argo-workflows/submit

={{ JSON.stringify({
  resourceKind: "WorkflowTemplate",
  resourceName: "heavy-job",
  submitOptions: { parameters: [
    "job-id=" + $execution.id,
    "units=" + ($("Webhook").first().json.body.units || 30),
    "callback-url=" + $execution.resumeUrl
  ] }
}) }}

The template (trimmed here) runs the job in its own pod with its own CPU and memory, and calls back from an onExit handler so a failed job resumes n8n as well:

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: heavy-job
spec:
  serviceAccountName: argo-workflow
  entrypoint: heavy
  onExit: callback
  arguments:
    parameters:
      - name: job-id
      - name: units
        value: "30"
      - name: callback-url
        value: ""
  templates:
    - name: heavy
      script:
        image: node:26-alpine
        command: [node]
        source: |
          // the same heavy(units) function as the Code node
          console.log(heavy({{workflow.parameters.units}}));
        resources:
          requests: { cpu: "1", memory: 384Mi }
          limits: { cpu: "1", memory: 512Mi }
    - name: callback
      container:
        image: node:26-alpine
        command: [node, -e]
        args:
          - |
            fetch(process.argv[1], {
              method: 'POST',
              headers: {'Content-Type': 'application/json'},
              body: JSON.stringify({jobId: process.argv[2], status: process.argv[3]}),
            });
          - "{{workflow.parameters.callback-url}}"
          - "{{workflow.parameters.job-id}}"
          - "{{workflow.status}}"

The Wait node releases the worker immediately. In the lab, the offloaded execution's stoppedAt was 0.4 seconds after it started, and its status in PostgreSQL was waiting until the callback arrived. The n8n documentation describes the 65-second persistence threshold for time-based waits; I observed that a webhook-resumed Wait persists the execution at once.

How does n8n authenticate to Argo?

The lab gives n8n its own ServiceAccount, n8n-submitter, with a long-lived token and a Role that allows only what the submit call needs:

rules:
  - apiGroups: ["argoproj.io"]
    resources: ["workflowtemplates"]
    verbs: ["get"]
  - apiGroups: ["argoproj.io"]
    resources: ["workflows"]
    verbs: ["create", "get", "list", "watch"]

The Argo server runs with --auth-mode=client and --auth-mode=server. A request that carries a bearer token acts as that ServiceAccount, so n8n gets exactly the Role above, and a request with an invalid token gets a 401. In n8n the token lives in a Header Auth credential (Authorization: Bearer <token>), which the bootstrap job creates from the Secret.

The server mode is the catch. A request with no token acts as the Argo server's own ServiceAccount, which is how the UI works behind my SSO proxy. I checked from a pod in the cluster: a call without a token returned 200 and the workflow list. Client mode alone does not close that, because it only constrains callers that identify themselves. The lab restricts who can reach the server instead, with a NetworkPolicy that admits Traefik (the UI path) and the n8n namespace and nothing else. A pod in default and a pod in the Argo namespace both fail to connect, and n8n still submits. Anything in the n8n namespace can still call without a token, so the policy narrows the exposure and does not remove it. In production, drop the server mode and put the UI behind Argo's SSO mode.

What did offloading change?

All ten jobs succeeded at every size. Offloading kept the workers nearly idle and left the neighbor workflow's queue wait at baseline:

Path	Job (CPU-s)	Executions ok	Median execution time	Neighbor queue wait p95 / max	Peak workers	Peak worker CPU (cores)
Baseline (neighbor only)	n/a	n/a	n/a	0.01 s / 0.10 s	1	n/a
Inline	5	10/10	44 s	4.18 s / 13.8 s	3	1.19
Inline	10	1/10	n/a	2.63 s / 9.9 s	2	1.19
Inline	30	1/10	n/a	0.03 s / 18.3 s	3	1.58
Inline, runner limits raised	30	10/10	305 s	0.08 s / 9.2 s	2	0.86
Offloaded	5	10/10	25 s	0.01 s / 0.1 s	1	0.07
Offloaded	10	10/10	35 s	0.02 s / 0.04 s	1	0.05
Offloaded	30	10/10	81 s	0.01 s / 0.1 s	1	0.07

Three effects stand out.

The workers stay idle. While ten 30-second jobs ran, the offloaded workers peaked at 0.07 cores in total, against 0.86 to 1.58 inline. n8n's own n8n_scaling_mode_queue_jobs_active gauge peaked at 6 during the offloaded run, which matches the neighbor workflow's six in-flight executions. The ten heavy jobs held no slots. During the inline runs the same gauge reached 15 to 30.

The neighbor keeps its latency. The light workflow waited a median of 0.01 seconds in the queue at baseline. With 5-second inline jobs its 95th-percentile wait rose to 4.18 seconds, and with 30-second inline jobs the worst wait reached 18.3 seconds. With offloaded jobs it stayed at the baseline.

KEDA has nothing to react to. The offloaded runs never scaled the workers past 1. The workers do not need more replicas, because the work no longer runs in them. The cluster scheduler absorbs it instead, which is the pod-per-step model I contrasted with n8n's queue workers in the KEDA article.

What does offloading cost?

A fixed delay on every job, and capacity that you must supply.

The fixed delay. I ran single jobs one at a time with no other load. A 1-CPU-second job took 1.0 seconds end to end inline and 11.7 seconds offloaded. A 5-CPU-second job took 4.9 seconds inline and 11.7 seconds offloaded. The Argo pod's main container ran for 2 to 6 seconds of that; I did not trace where the rest goes, so I report the total as measured. For a short job, offloading is slower.

The capacity. Argo gives you the cluster scheduler, not extra cores. I submitted N identical 30-second jobs directly to Argo, with no n8n involved, and measured the main container's run time per job:

Parallel jobs	Median run time per job
1	27 s
5	43 s
10	60 s
20	112 s

The lab node has 12 physical cores and the job walks a 256 MiB array, so I expect shared cores and memory bandwidth to slow concurrent jobs well before the 24 threads run out. I did not isolate the cause. On a multi-node cluster with a node autoscaler, those jobs spread out. On one node, offloading moves the contention from a worker's single core to the node's cores, which is still an improvement because the worker's capacity no longer limits it, but the parallelism is not free.

When should a step leave n8n?

This is my reading of the numbers from one lab, not a general rule.

Under about 2 CPU-seconds, stay inline. The offload adds about 12 seconds of fixed time, which dwarfs the work.
A few seconds to about 10, decide by concurrency. A single 5-second job is faster inline. Ten of them at once finished in 25 seconds offloaded against 44 inline, and left the neighbor workflow untouched.
At 10 CPU-seconds or more, offload. In this lab, the Code node on default settings did not survive ten of them at once.
Offload anything that needs more CPU, memory, or tooling than a worker pod has. The pod gets its own resource limits and any image you want.
Leave I/O-bound steps in n8n. Waiting on an API costs the worker a slot but almost no CPU, and KEDA handles it, as the first article shows.

Things this lab did not test: cancelling an n8n execution while its Argo job runs (the job keeps running unless something deletes it), retries through Argo's retryStrategy, the Wait node's time limit when a callback never arrives (the workflow sets 30 minutes), workflowRestrictions to stop a token holder from submitting arbitrary templates, and a multi-node cluster.

Key takeaways

A Code node runs in one single-threaded task runner per worker. A CPU-bound loop longer than a few seconds makes the runner miss task acknowledgements, and the broker restarts it and aborts every task on it.
Raising the runner limits avoids the failures and serializes the work: ten 30-second jobs took 305 seconds on one worker.
Offload with three pieces: an HTTP Request node that submits an Argo WorkflowTemplate, a Wait node resumed by webhook, and an onExit handler that posts the status to $execution.resumeUrl.
Give n8n its own Argo ServiceAccount with a Role limited to submitting from templates. Client auth mode only constrains callers that send a token, so close the server mode fallback with a NetworkPolicy or SSO.
Offloading costs about 12 seconds per job in this lab, so keep short jobs inline, and budget cluster capacity for the jobs you hand off.

Disclosure: I write on my blog independently. I'm also an official technical writer for n8n and a member of the n8n Creators program. I ran every experiment and benchmark in this article on my own single-node k3s lab cluster. If you want to try n8n Cloud, my referral link supports my personal research and lab benchmarks at no extra cost to you.

This article first appeared on mihai.ltd. Read the original for the full version.

About the author

On my YouTube channel, Let's Talk Dev, I break down complex engineering concepts and the experiments behind these articles.

Connect with me:

Website and blog: mihai.ltd
YouTube: @letstalkdev
GitHub: mihailtd
LinkedIn: Mihai Farcas

Mount Local Storage to Kubernetes Pods: An Easy Tutorial Using K3s and the Local Path Provisioner

Mihai Farcas — Thu, 08 Oct 2026 17:17:21 +0000

Originally published on mihai.ltd.

Persistent storage remains one of the first hurdles engineers hit when deploying stateful applications to Kubernetes. While stateless services restart cleanly anywhere across a cluster, databases, message brokers, and ML workloads require durable disks that survive pod restarts and rescheduling.

When developers first encounter storage on Kubernetes, they often find conflicting advice: enterprise blogs recommend multi-node distributed storage clusters like Ceph or Longhorn, while quickstart tutorials use raw hostPath volumes. For single-node clusters, homelabs, and edge environments, both extremes cause problems.

This guide clarifies how Kubernetes storage abstractions operate, examines how distributions handle local storage out of the box, and shows how Rancher's Local Path Provisioner enables automated, high-performance NVMe storage for your workloads.

The Ephemeral Container Problem

Kubernetes schedules Pods—groups of one or more co-located containers—onto worker nodes across a cluster. Containers provide lightweight, isolated process environments, but their file systems remain ephemeral by default. When a container crashes or restarts, Kubernetes recreates it from the base container image, discarding uncommitted runtime data.

In traditional Docker environments on a single physical host, engineers solve persistence by mounting a host directory via bind mounts:

docker run -d -v /var/data/postgres:/var/lib/postgresql/data postgres:16

In a distributed Kubernetes cluster, direct host paths break down:

Scheduling Blindness: The Kubernetes scheduler places pods dynamically based on CPU, memory, and affinity rules. If Kubernetes terminates a pod on Node A and restarts it on Node B, a hardcoded path on Node A remains unreachable from the new node.
Resource Leaks: When you delete a workload, Kubernetes deletes the pod, but the files on the host disk stay behind indefinitely. Without manual cleanup, dead workloads slowly fill host disks.
Security Risks: Hardcoding host filesystem paths in application manifests gives container processes direct access to node-level file systems, bypassing namespace isolation.

To solve these problems without tying manifests to physical hardware, Kubernetes introduces three layers of storage abstraction: PersistentVolumes, PersistentVolumeClaims, and StorageClasses.

The Kubernetes Storage Hierarchy

Kubernetes separates storage management into distinct concerns for infrastructure administrators and application developers.

1. PersistentVolume (PV)

A PersistentVolume represents an actual piece of storage in the cluster—such as an allocated NVMe directory on a worker node, an NFS export, or an AWS EBS volume. An administrator can provision PVs manually, or a storage driver can generate them dynamically. A PV defines capacity, access modes, and technical connection details.

2. PersistentVolumeClaim (PVC)

A PersistentVolumeClaim is an application developer's request for storage. Instead of specifying host paths or disk serial numbers, a developer specifies capacity (such as 10Gi), access modes, and an optional StorageClass name.

When you submit a PVC, the Kubernetes control plane matches the request against available PVs. Once matched, it binds the PV to the PVC in a strict one-to-one relationship.

3. StorageClass

In production clusters, administrators do not manually create PersistentVolume manifests for every developer deployment. A StorageClass defines a dynamic provisioner plugin and parameters. When a developer submits a PVC referencing that StorageClass, the provisioner creates the backing storage volume and registers the matching PV automatically.

The Homelab Storage Dilemma: Distributed SAN vs. Local Path

When setting up storage for local clusters, engineers generally consider three architectures:

Storage Model	Provisioning	Cleanup on Delete	Latency	Cluster Resource Overhead	Ideal Workload
Raw hostPath	Manual YAML per volume	None (leaks on host disk)	Sub-millisecond	None	Host node agents (Fluentbit, node-exporter)
Local Path Provisioner	Fully automated via PVC	Automated helper cleanup	Sub-millisecond	Negligible (ephemeral helper pods)	Databases with app-level HA, single-node labs
Distributed (Longhorn/Ceph)	Fully automated via PVC	Fully automated	Network sync delay	Heavy (15–30% CPU, gigabytes RAM)	Multi-node clusters requiring block failover
Cloud CSI (EBS/PD)	Fully automated via API	Fully automated	Network attached	Offloaded to cloud hypervisor	Public cloud managed Kubernetes

In enterprise data centers with 10GbE or 40GbE network fabrics, distributed storage systems like Rook-Ceph or Longhorn offer automatic replication and seamless volume failover between nodes.

In single-node homelabs, edge nodes, and developer workstations, running a distributed storage layer wastes significant resources. Systems like Longhorn replicate data across the network across the network, consuming 15% to 30% of cluster CPU capacity and gigabytes of RAM.

For high-throughput databases (such as PostgreSQL, Valkey, and ChromaDB), direct host NVMe storage provides the lowest latency and highest IOPS. Rancher's Local Path Provisioner delivers that native performance while maintaining standard Kubernetes PVC workflows.

How the Local Path Provisioner Works Under the Hood

The Local Path Provisioner runs as a lightweight controller pod inside the cluster. It watches for PVCs that request its StorageClass and manages host directories through a dedicated lifecycle.

The Lifecycle Flow

PVC Submission: A developer applies a PVC manifest specifying storageClassName: local-path.
Scheduler Placement: Because the storage class uses volumeBindingMode: WaitForFirstConsumer, the claim stays in Pending until a pod references it. Once you deploy the pod, the Kubernetes scheduler assigns the pod to an available worker node based on CPU and memory limits.
Helper Pod Execution: The Local Path controller detects the target node and launches a temporary helper pod (rancher/library-busybox) on that specific machine. The helper pod executes:

   mkdir -m 0777 -p /var/lib/rancher/k3s/storage/pvc-<uuid>

PV Generation and Binding: The provisioner registers a new PersistentVolume with nodeAffinity targeting the chosen node and binds it to the PVC.
Direct Kubelet Bind-Mount: The node's kubelet bind-mounts the newly initialized host directory directly into the pod container at the target path (such as /data).
Automated Teardown: When you delete the PVC, the provisioner observes the reclaimPolicy: Delete rule, launches a cleanup helper pod on the node, and runs rm -rf on the directory, ensuring no orphaned data remains.

Why `WaitForFirstConsumer` Is Non-Negotiable

Standard cloud block storage often uses volumeBindingMode: Immediate, which allocates a disk before assigning a pod to a node.

For local node storage, immediate binding causes scheduling failures. If the controller allocates a directory on Node A before the scheduler runs, and the pod subsequently requires a GPU or memory capacity available only on Node B, the pod will remain unschedulable indefinitely. WaitForFirstConsumer delays volume creation until the scheduler selects the target node.

Distribution Support: Does Your Cluster Include It?

Support for local storage provisioners varies across Kubernetes distributions:

K3s: Included out of the box. K3s deploys Rancher's Local Path Provisioner by default in the kube-system namespace and sets local-path as the cluster's default StorageClass.
Kind (Kubernetes in Docker): Included out of the box. Kind bundles Rancher's local-path provisioner under the standard storage class.
Minikube: Includes its own default storage-provisioner addon.
MicroK8s: Requires running microk8s enable hostpath-storage.
Vanilla Kubernetes (kubeadm, Talos, RKE2, Bare-Metal): Not included. Fresh bare-metal clusters do not include a default StorageClass. Running kubectl get sc returns an empty list, and any deployed PVC hangs in Pending.

Installing Local Path Provisioner on Any Cluster

If you run bare-metal Kubernetes via kubeadm, Talos, or RKE2, you can install the Rancher Local Path Provisioner with a single command:

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.30/deploy/local-path-storage.yaml

To configure it as your cluster's default storage class, apply the standard default annotation:

kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Verify that the provisioner pod is running:

kubectl -n local-path-storage get pods

Hands-On Walkthrough: Deploying a Stateful Pod

Let us deploy a stateful test application to examine volume creation, file persistence, and cleanup in practice.

Step 1: Create a PersistentVolumeClaim

Create a manifest named pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 5Gi

Apply the manifest and inspect its status:

kubectl apply -f pvc.yaml
kubectl get pvc

Notice that the claim status remains Pending:

NAME           STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-data-pvc   Pending                                      local-path     5s

Because local-path uses WaitForFirstConsumer, Kubernetes intentionally waits until a pod requests this volume before choosing a node.

Step 2: Deploy the Stateful Pod

Create a pod manifest named pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: storage-demo-pod
spec:
  containers:
    - name: alpine-app
      image: alpine:latest
      command:
        - "sh"
        - "-c"
        - "echo 'Data persisted at $(date)' >> /data/log.txt && sleep 3600"
      volumeMounts:
        - name: storage-volume
          mountPath: /data
  volumes:
    - name: storage-volume
      persistentVolumeClaim:
        claimName: app-data-pvc

Apply the pod:

kubectl apply -f pod.yaml

Check the PVC again:

kubectl get pvc,pv

The volume immediately transitions to Bound:

NAME                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/app-data-pvc   Bound    pvc-8e2b851a-7b3c-4b68-b80c-0744be958210   5Gi        RWO            local-path     30s

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   AGE
persistentvolume/pvc-8e2b851a-7b3c-4b68-b80c-0744be958210   5Gi        RWO            Delete           Bound    default/app-data-pvc   local-path     5s

Step 3: Verify Persistence Across Restarts

Verify that the pod wrote data to the mounted volume:

kubectl exec storage-demo-pod -- cat /data/log.txt

Now delete and recreate the pod:

kubectl delete pod storage-demo-pod
kubectl apply -f pod.yaml

Check the log contents again:

kubectl exec storage-demo-pod -- cat /data/log.txt

You will see both timestamp entries preserved across the pod lifecycle.

Step 4: Verify Host Directory Cleanup

On the physical host running the node, inspect the local path storage directory (defaulting to /var/lib/rancher/k3s/storage on K3s, or /opt/local-path-provisioner on standard installs):

ls -la /var/lib/rancher/k3s/storage

You will find the directory matching the generated PV volume name.

When you delete the PVC:

kubectl delete pod storage-demo-pod
kubectl delete pvc app-data-pvc

The provisioner launches its cleanup helper and removes the folder from the host filesystem, preventing disk accumulation.

Operational Caveats & Architectural Boundaries

While local path storage delivers exceptional speed, engineers must weigh its architectural constraints before choosing it for multi-node production clusters:

No Node-Level Redundancy: Local storage pins data to a specific physical machine. If the underlying hardware fails, Kubernetes cannot remount that data on another node.
Replication Strategy: Use local path storage for workloads that manage data replication at the application layer—such as PostgreSQL with CloudNativePG or patroni streaming replicas, Redis/Valkey clusters, and Kafka brokers. For workloads lacking internal replication, combine local storage with automated cloud snapshot backups (such as Barman S3 backups or Velero).
No Filesystem Quota Enforcement: By default, the storage: 5Gi request in your PVC acts solely as a scheduling filter. The Local Path Provisioner does not enforce Linux filesystem quotas unless your host partition is explicitly formatted and mounted with ext4 or xfs project quota support. A runaway container can write past its claimed capacity and fill the host partition.

Key Takeaways

Pod filesystems are ephemeral by default; persistent storage requires decoupling workload lifecycles from container lifecycles.
Raw hostPath mounts introduce security risks, lack dynamic provisioning, and orphan data on disk upon deletion.
K3s includes Rancher's Local Path Provisioner out of the box under the local-path storage class; bare-metal clusters can install it via a single manifest.
volumeBindingMode: WaitForFirstConsumer ensures the provisioner allocates volumes on the exact worker node selected by the scheduler.
Local path storage delivers raw NVMe throughput with zero network overhead, making it the ideal storage choice for homelabs, edge nodes, and replicated database clusters.

This article first appeared on mihai.ltd. Read the original for the full version.

About the author

On my YouTube channel, Let's Talk Dev, I break down complex engineering concepts and the experiments behind these articles.

Connect with me:

Website and blog: mihai.ltd
YouTube: @letstalkdev
GitHub: mihailtd
LinkedIn: Mihai Farcas

I Hired Claude, But Slower and More Expensive

Mihai Farcas — Tue, 21 Jul 2026 18:37:22 +0000

The comment landed on the pull request early afternoon, around 9 in the morning his time; we worked a few time zones apart. Four paragraphs defending his implementation, well structured, calm, thorough, closing with a suggestion that we align on the approach going forward. I still disagreed with the implementation, but I respected the argument. It read like something a senior engineer would write.

The next morning, we had a live share screen session to present the solution. I gave him a small task on the spot: take a hardcoded value and move it to an environment variable. Housekeeping. Two minutes, maybe five if you have to go get a coffee.

He opened Copilot and started typing a prompt.

"What are you doing?" I said. "Come on - you don't need Copilot to add an env var to your own code."

So he did it by hand, and that's when I saw it. He struggled to navigate his own code - the code he'd defended in four paragraphs - hunting for the pydantic config like a visitor in someone else's repository. Then the second thing: environment variables come in as strings, this value needed to be a number, and he didn't know how to do that. Not "forgot the syntax" - didn't know that converting a string to a number in Python was a thing he was supposed to do, or how to look for it. This is a person whose CV said data science. Years of it, allegedly, in a language where int() is the kind of thing you learn the first week and never think about again.
Four fluent architecture paragraphs one afternoon, couldn't int(x) the next morning. The interview had been great, the CV impressive.

What the interview measured

We ran the process remotely, like everyone did by then. He answered everything. Machine learning, evaluation metrics and scores, RAG and vector databases, Docker, SQL and NoSQL, database indexes, REST APIs, HTTPS, encryption, authentication and authorization - the whole spread, handled with unusual composure. No wrong turns, no backtracking, no "I'm not sure, but here's my guess."

At the time, that looked like a strong signal. In hindsight it was the tell.

A technical interview is built as a ladder. The early questions confirm the basics. The later ones climb in difficulty on purpose, because the interviewer is trying to find the step where you slow down, start reasoning out loud, and eventually say "I don't know." That step is the measurement. It tells me your level, and it tells me something more valuable: what you do when you run out of level. Do you reason from first principles? Ask a clarifying question? Bluff?

A candidate who never reaches that step has, in theory, exceeded the ceiling of my interview. That happens. I've met engineers who genuinely out-climbed every question I had. But they have a texture to them - they get more engaged as the questions get harder, they argue with the premise, they tell you where your scenario is unrealistic. What they don't do is deliver each answer with the same even confidence, in the same structured cadence.

Even confidence across all difficulty levels isn't a sign of skill. Skill has a gradient. You can hear it in how someone answers a question at their comfort level versus one just past it. When the gradient is missing - when the question about B-tree page splits gets the same fluent treatment as the question about basic data types - either you're talking to one of the best engineers of your generation, or you're talking to a second screen.
I assumed the first. I shouldn't have.

This is why we moved the technical round back to face-to-face, and it has nothing to do with tradition or nostalgia. A live conversation in the same room is the last environment where I can observe the thing I'm actually hiring: a person, reasoning, unassisted, at their real level. I don't need them to perform under pressure, a candidate can think in silence as long as they want. I need to see where the ladder ends. Remote interviews stopped being able to show me that, because for a mediocre engineer with a state of the art LLM, the ladder no longer has a top.

Debating a proxy

The env var morning changed how I read his messages, but the answers kept coming. Every review comment I left came back with a rebuttal. Fast, fluent, three or four paragraphs, complete with tradeoffs. The tone never wavered and nothing was ever conceded. I'd respond, and within the hour another one would arrive, just as calm, just as structured, addressing my points one by one with a weird politeness.

Producing one of those rebuttals cost him a copy, a prompt and a paste. Verifying it cost me twenty minutes - reading the documentation he cited, checking whether the tradeoff he described applied to our case at all, writing a response precise enough not to spawn three new threads. Reviewing his work had quietly become the biggest line item in my calendar.

And underneath every exchange sat the thing I couldn't say. I was fairly sure - the pydantic morning had made me fairly sure - that the person I was debating didn't understand the position he was defending. But knowing it and saying it are different weight classes. Accuse someone of relaying a model's arguments and you'd better be right, and able to show it; otherwise you're the manager who calls his reports frauds whenever they push back. So I kept my cards down and answered the arguments on their merits. Disagreement is the job; I don't mind it. What drained me was writing rebuttals to a machine, routed through a person who couldn't evaluate either side of the debate.

The second task was small and deliberately unglamorous: a script, no interface, no users. What he delivered had a web UI and a login screen. The script itself - the part anyone had asked for - still didn't work properly. When I asked why he'd spent his time on extras nobody requested while the requested part had problems, the answer came back without a flicker of doubt: "Because making a login is easy."

I've been doing this long enough to flinch at that sentence.

Authentication is a hard problem - session handling, token expiry, credential storage, password resets, and so on. Whole companies exist because engineering teams decided never to build it themselves. But I understood where his confidence came from. A model scaffolds a login page in thirty seconds, and it runs, so to him a login was easy. AI has flattened the visible effort of hard problems and trivial ones down to the same short wait, and if visible effort is your only gauge of complexity, everything seems as easy. He wasn't lying to me. He couldn't tell the difference. Or, more likely, never could, and now had a tool that agreed with him.

That was the shape of those weeks: confident essays in the pull requests, confident shortcuts in the work, and me in the middle, debating an LLM.

Why do I need you?

The clearest version of the problem surfaced in the next task. I handed him a piece of work with clear requirements. A solution came back. Decent, tidy, obviously generated, and wrong in two places that mattered. I reviewed it, found both problems, and explained them, along with the direction of the fix. A corrected version came back shortly after. It was fine. On the project board, this looked like an engineer completing a ticket.

Walk the steps, though. The requirements were mine. The review that caught the flaws was mine. The direction for the fix was mine. The code was the model's. His contribution was moving text between me and the LLM - my task description into the prompt, my corrections into the prompt, the output into a pull request. At which of those steps did I need him?

I had, in effect, added a layer between myself and Claude. It contributed latency, demanded a salary, and it subtracted accountability - when the corrected solution worked, that was his ticket done; when the first one was broken, that was somehow my fault for not writing clear enough requirements. Which was, notably, the only kind of pushback he ever produced. While the work was in front of him he never questioned a requirement, never asked what should happen at an edge, never flagged that a spec was ambiguous - the annoying, valuable questions that mean someone has thought past the ticket. Questioning a spec requires understanding it. His objections only ever arrived afterward, in defense. Cut the layer out and I'd get the same code faster, minus the endless debates. Somewhere in that loop the sentence formed on its own: I had hired Claude, but slower and more expensive.

To be fair to the tool - and to be honest about my own workflow - the tool was never the problem. I use Claude daily. So does everyone on the team whose work I don't re-check. The difference sits entirely in what happens before and after the final output. When I get a generated solution, a list forms in my head of the places it's most likely wrong: the edge case it silently ignores, the API that doesn't behave the way the training data thinks it does, the requirement it quietly rewrote into an easier one. He did no such due diligence. He trusted the output until someone else pointed at the flaw, and he didn't seem to think that checking was part of his job. The model produced, I verified, he forwarded.

This is what AI has done to the profession, and it took a bad hire for me to see it clearly. The visible difference between a junior and a senior used to announce itself in the code. You could tell from the diff who had ten years and who had one. Now both hand you clean, confident, working-looking solutions by the afternoon. The difference that's left is invisible, and it only shows up when something is wrong. Knowing what to distrust is now the entire job.

Trust, once it's gone

The man in our daily standups did not match the man from the interview. The candidate had walked through database indexes and RAG pipelines with confidence. The employee, asked what he did yesterday, produced hesitations and generalities like "still working on it," or "had some issues with the setup", and couldn't summarize his own ticket in two clean sentences. For a while I explained the gap away as nerves, or language barriers, or mornings. But it had a pattern. A model can answer questions about B-trees. It can't answer what you did yesterday.

And yet - every couple of weeks there would be a call where he was fine. He'd explain a decision coherently, catch some small thing, make a reasonable point, and I'd leave the meeting thinking: maybe I've been unfair to this guy. Maybe the env var morning was one bad day, magnified by everything I'd stacked on top of it since. The relief was genuine, and it lasted on average until his next pull request. Then the cycle restarted. I came to recognize it as a carousel - disbelief, then belief, then disbelief again - and to notice how much I wanted the belief half to win. Believing meant the problem would dissolve on its own. Disbelieving meant months of documentation and meetings I could already picture.

Trust is what lets a manager sample. You skim most pull requests, spot-check now and then, take "done" at face value, because the track record covers the rest. With him I had stopped sampling. I read his diffs line by line, re-ran what he claimed passed, re-verified every "done". One person on suspicion costs more oversight than five people on trust.

The part I didn't expect is how unfairly suspicion generalizes. Some of his work was genuinely fine, a config change or a small fix, yet I caught myself second-guessing that too, hunting for the flaw in code that didn't have one. Trust doesn't fail per-task; it fails per-person. Once it failed, there was no setting in which I could take something from him at face value, and rebuilding that was, realistically, no longer on the table.

Which left one decision, and a process famous for taking its time.

Why you can't just fix it quickly

There's a version of this story where the env var morning is followed, a week later, by a handshake and a "see you never" letter. That version exists in no company I've worked at.

Unfortunately the location he worked in had no such thing as a probation period. What existed instead was process: documented feedback, improvement objectives, meetings with agendas and alignment with the people whose job is to make sure no employee is ever removed carelessly. The process isn't designed to reach the obvious conclusion quickly; it's designed to make sure the conclusion is fair.

He understood the process too. The closer it moved, the more friction appeared: time-off requests at delicate moments, sudden personal problems and grievances that had to be heard out, each one consuming a meeting, a week, a cycle of someone else's attention. I can't prove any single one of them was tactical. Collectively, they had excellent timing.

And here is the conflict I didn't expect to be having with myself. The department defending him is the same department that would defend me. I want to work at a company where nobody can be removed on one manager's bad week. But wanting the shield to exist and watching it held, week after week, over someone I knew by then to be functionally a scammer, is an internal conflict I never expected to have.

All the while, the meter ran: my review hours, the tasks quietly routed around him, the senior engineer pulled into second-checking, the teammates watching a colleague produce almost nothing and remain on the team.

What changed

I'm not new to interviewing. I've sat on the interviewers' side of the table well over a hundred times, and I started in an era when remote interviews didn't exist - every single one was a conference room, a handshake, and a conversation. When the industry migrated to video calls and take-home assignments, I migrated with it, because it was efficient and, for a while, it worked.

The take-home assignment is dead. I'll say it plainly because I know how much some teams have invested in theirs. A take-home used to measure how someone works without an audience: how they structure a project, what they test, where they take shortcuts. It now measures whether a candidate can operate a model for an evening, and the answer is always yes. Every submission comes back senior-looking - clean structure, docstrings, a test suite. The signal isn't weakened; it's gone.

What replaced it, for me, is the same process of interviewing I started with 8 years ago: a face-to-face discussion, no augmentation, no second screen - just the candidate's head and mine. And I've changed what I probe for. What I care about is depth and logic - not "what is a database index," but "here's a query that got slower after we added an index; walk me through what could have happened and how you'd go about fixing it." Then I follow the answer downward. Everyone's understanding thins somewhere; the depth where it thins is their level. How they behave at that depth - guessing, bluffing, or saying "I don't know, but here's how I'd find out" - tells me the rest.

That's the calibration I described at the start, and it's the part no tool has managed to fake in a live conversation. A model can hand someone an answer. It cannot hand them the second layer of the answer, or the third, or the ability to notice that my follow-up question quietly contradicted their previous claim.

So that's how I interview for now. Not the production of answers - answers have become the cheapest thing in the profession. I look for the person who looks at a confident, plausible, generated solution and knows where to poke it, how to identify the edge cases where it doesn't work. Everything else, the tools cover.

I'm Mihai Farcas, a software architect from Cluj-Napoca, Romania. Add me on LinkedIn. I make YouTube videos about software architecture and engineering careers. If you've lived through a hire like this one, I'd genuinely like to hear how it went. Also if you've changed your interviewing process because of AI, I'd be curious to know how.

The $3/Month Enterprise-Ready Automation Stack: Zero-Trust n8n With One Command (n8n, Cloudflare, UpCloud, Pulumi)

Mihai Farcas — Tue, 07 Apr 2026 17:44:04 +0000

I run one command and get a fully working n8n instance — HTTPS, zero-trust tunnel, PostgreSQL, the works. One more command and it's all gone. Total cost: $3/month.

No SSH. No open ports. No clicking around in dashboards.

Here's exactly how it works.

The Problem With Self-Hosted Automation

Every self-hosting tutorial I find tells me to do the same thing: open ports 80 and 443, set up Nginx, wrestle with Let's Encrypt, and pray nobody scans my server before I've hardened it.

Then there's the database. Most n8n guides default to SQLite. It works — until two workflows fire at the same time and the whole thing locks up.

I don't want to babysit a server. I want to deploy, use it, and tear it down when I'm done. No manual steps. No leftover infrastructure.

So I built exactly that.

What You Get

One pulumi up command creates:

A $3/month UpCloud server (1 CPU, 1 GB RAM, 10 GB storage, Ubuntu 24.04). Use my UpCloud affiliate link and get started with this unbeatable deal!
A Cloudflare Tunnel — zero-trust, outbound-only connection. No open ports.
Automatic HTTPS and DDoS protection via Cloudflare's edge
PostgreSQL 18 for concurrent workflow execution
n8n running behind the tunnel, accessible at your custom domain
DNS records pointed at the tunnel automatically

One pulumi destroy removes everything. Server, tunnel, DNS — gone.

Why Zero-Trust Matters Here

Traditional setups expose your server to the internet. You open ports, configure firewalls, manage certificates. Every open port is an attack surface.

Cloudflare Tunnels flip this model. The cloudflared daemon on your server creates an outbound-only connection to Cloudflare's network. Traffic flows in reverse:

User → Cloudflare (HTTPS + DDoS) → Tunnel → n8n container

Your server has zero open inbound ports. No firewall rules to manage. No certificates to renew. Cloudflare handles all of it at the edge.

The 6-Pillar Stack

Each tool has one job:

Pulumi — Infrastructure as Code. Provisions everything.
UpCloud — $3/month compute (Frankfurt, DE).
Cloudflare — Zero-trust tunnel + HTTPS + DDoS protection.
Docker — Container runtime via Docker Compose.
n8n — Workflow automation engine.
PostgreSQL 18 — Production database for concurrent execution.

How It Wires Together

The entire deployment is 180 lines of TypeScript. Here's what happens when you run pulumi up:

1. Pulumi Creates the Cloudflare Tunnel

const tunnel = new cloudflare.ZeroTrustTunnelCloudflared("n8n-tunnel", {
  accountId: cfAccountId,
  name: "n8n-tunnel",
  configSrc: "cloudflare",
  tunnelSecret: crypto.randomBytes(32).toString("base64")
});

A 32-byte random secret gets generated. The tunnel routes traffic from your domain to http://n8n:5678 inside the Docker network.

2. The Tunnel Token Gets Fetched via API

const tunnelToken = cloudflare.getZeroTrustTunnelCloudflaredTokenOutput({
  accountId: cfAccountId,
  tunnelId: tunnel.id
});

This is the key trick. Instead of SSHing into the server after boot to inject the token, Pulumi fetches it directly from Cloudflare's API. The token gets baked into the cloud-init script — zero post-deploy steps.

3. DNS Points to the Tunnel

const dnsRecord = new cloudflare.DnsRecord("n8n-dns", {
  zoneId: cfZoneId,
  name: domain,
  type: "CNAME",
  content: pulumi.interpolate`${tunnel.id}.cfargotunnel.com`,
  proxied: true
});

A proxied CNAME record. Cloudflare's edge handles TLS termination and DDoS filtering before traffic ever reaches your server.

4. Cloud-Init Bootstraps the Server

Pulumi builds a cloud-init script that:

Installs Docker Engine
Writes docker-compose.yml with all secrets baked in
Writes the tunnel token to .env
Runs docker compose up -d

The server boots, runs this script, and 60 seconds later n8n is live. No SSH required.

5. Three Containers, One Compose File

services:
  postgres:
    image: postgres:18-alpine
    # Health check ensures n8n waits for DB

  n8n:
    image: n8nio/n8n:latest
    depends_on:
      postgres:
        condition: service_healthy
    # Full PostgreSQL config, HTTPS via tunnel

  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    # Token from .env file

PostgreSQL starts first. n8n waits for the health check. cloudflared connects the tunnel. The Docker network handles service discovery — n8n:5678 just works.

The Setup (5 Minutes)

Prerequisites

An UpCloud account (API credentials)
A Cloudflare account with a domain (API token with Zone:DNS:Edit + Account:Tunnels:Edit)
Pulumi CLI installed
Node.js 18+

Deploy

# Clone and install
cd infra && npm install

# Create .env from the template (in the project root)
cp ../.env.example ../.env
# Edit .env — fill in your API tokens, domain, and Cloudflare IDs
# SSH key is auto-detected from ~/.ssh/ (no config needed)

# Load env vars and set secrets
set -a && source ../.env && set +a
pulumi config set --secret postgresPassword "$(openssl rand -hex 16)"
pulumi config set --secret n8nBasicAuthUser "admin"
pulumi config set --secret n8nBasicAuthPassword "$(openssl rand -hex 16)"
pulumi config set --secret n8nEncryptionKey "$(openssl rand -hex 32)"

# Deploy everything
pulumi up

That's it. Visit https://n8n.yourdomain.com and log in.

Tear Down

pulumi destroy

Server, tunnel, DNS — all removed. Nothing left running. Nothing left billing.

What About Persistence?

PostgreSQL data is saved as a Docker volume on the server itself. Your workflows, credentials, and execution history survive container restarts and docker compose down / up cycles.

What they don't survive is pulumi destroy — that deletes the server and everything on it.

For production, consider switching to a managed PostgreSQL service (UpCloud, Aiven, Neon) or mounting resilient block storage for the database volume. Either option decouples your data from the server lifecycle.

What About n8n Cloud?

n8n Cloud is the easiest way to get started. Managed hosting, automatic updates, built-in auth, and zero infrastructure to think about. If you don't want to manage servers, it's the right choice.

This self-hosted stack is a different tradeoff. You get full control over the environment — custom domains, your own database, and the ability to spin up or tear down the whole thing in seconds. You also manage the infrastructure.

Both are valid paths. Pick the one that fits how you work.

The Full Lifecycle

Here's the entire flow, start to finish:

You (one-time): Fill in a .env file (API tokens, domain, Cloudflare IDs). Run 4 secret config commands. SSH key is auto-detected.

Pulumi (automated): Creates tunnel → fetches token → configures routes → creates DNS → builds cloud-init → provisions server.

Server (automated): Boots → installs Docker → writes configs → starts containers.

Result: n8n live at your domain with HTTPS, zero-trust networking, and PostgreSQL. No SSH. No open ports. $3/month.

Done? pulumi destroy. Everything gone.

Want to try it? The full source code is on GitHub. Clone the repo, set your API keys, and deploy in 5 minutes.

Need help with your setup? I build and consult on automation infrastructure professionally. Reach out and let's talk about your use case.

Automate Your Homelab Like a Pro with Ansible!

Mihai Farcas — Wed, 02 Apr 2025 07:02:04 +0000

Spending too much time manually configuring servers in your homelab? Wish you could automate setup, updates, and deployments reliably? Ansible is a powerful yet simple, agentless automation tool that can tame your infrastructure, whether it's a personal lab or a production environment.

This article walks through practical examples directly from my latest YouTube video, showing you how to automate Proxmox updates, VM setups, PostgreSQL configuration, and even handle secrets securely with Ansible Vault.

If you'd rather watch a youtube video than read:

If not, let's dive in!

Why Ansible for Your Homelab (and Beyond)?

So, why choose Ansible over manual configurations or complex scripts? Here are a few compelling reasons:

Simplicity & Readability

Ansible uses YAML for its playbooks, which is incredibly easy for humans to read and write. You describe the state you want your systems to be in, rather than scripting every single step. This makes your automation understandable and maintainable.

Agentless Architecture

This is a huge advantage! You don't need to install or manage special agent software on your servers (nodes). Ansible communicates primarily over standard SSH for Linux/Unix systems (or WinRM for Windows), using Python on the remote end (which is usually already there). This means less setup, less resource overhead, and a smaller attack surface.

Idempotency: The Automation Superpower

As highlighted in the video, Ansible operations are typically idempotent. This means you can run a playbook multiple times, and it will only make changes if needed to reach the desired state. Running it again won't break things or cause unintended side effects. This is absolutely crucial for reliable and predictable automation – run your updates, and only the nodes that need updating get touched!

Power & Flexibility ("Batteries Included")

Don't let the simplicity fool you. Ansible comes with a vast library of built-in modules that handle thousands of common tasks – installing packages (apt, yum), managing services (service, systemd), copying files (copy), generating configs from templates (template), managing users (user), interacting with cloud providers, configuring databases (like PostgreSQL!), and much more. You describe what you want done, and the module handles the how.

Getting Started: Prerequisites

Before you start automating, you need a couple of things set up.

1. On Your Control Machine (Where you run Ansible):

Python 3: Ansible is built with Python. Make sure you have Python 3 installed. You can check with:
```
python3 --version
```
Ansible: Install Ansible itself. Using pip (Python's package manager) is often recommended for getting the latest version: pip3 install ansible. Alternatively, use your OS package manager (like apt or brew). Check your installation with:
```
ansible --version
```
(Optional) Ansible VS Code Extension: If you use Visual Studio Code, the official Ansible extension by Red Hat provides excellent syntax highlighting and autocompletion.
Ansible Packages: Some Ansible community collections might need to be installed separately using commands like ansible-galaxy collection install community.postgresql for example.

2. Access to Your Target Nodes (Your Homelab Servers):

SSH Access: Since Ansible is agentless for Linux/Unix, it relies on SSH to connect and execute commands. You need SSH access from your control machine to your homelab servers.
SSH Key Authentication (Recommended): For seamless automation, set up SSH key-based authentication so Ansible doesn't need to ask for passwords. The easiest way is to copy your public SSH key (e.g., ~/.ssh/id_ed25519.pub) to your target nodes using ssh-copy-id. Replace root@<server_ip> with the appropriate user and IP for each server:
```
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<your_homelab_server_ip>
```
(Note: For Windows targets, Ansible uses WinRM instead of SSH, which requires different setup steps not covered in detail here.)

Understanding Your Ansible Project: Structure & Core Concepts

A well-structured Ansible project makes automation easier to manage and scale. Here's a typical layout, incorporating the core concepts:

your-ansible-project/
├── ansible.cfg         # Project-specific Ansible configuration
├── inventory/          # Defines WHAT servers Ansible manages
│   └── hosts.ini       # Your inventory file(s)
├── playbooks/          # Contains your automation instructions (playbooks)
│   ├── proxmox.yml
│   ├── postgres.yml
│   └── ...
├── vars/               # Stores variables, including secrets
│   ├── common_vars.yml
│   └── secrets.yml     # Encrypted secrets using Ansible Vault
└── roles/              # (Optional) Reusable units of automation (Not covered in detail here)

[Image: Simple diagram showing this directory structure]

Let's break down each part:

inventory/ (The "What"): This directory holds your Inventory file(s) (often hosts.ini or inventory.yml). This tells Ansible which servers (nodes) it should manage. You can list servers individually or group them logically (like [proxmox_nodes] or [webservers]). Your script showed an example inventory.ini:
```
[proxmox_nodes]
pve ansible_host=192.168.31.100
srv-1 ansible_host=192.168.31.101
srv-2 ansible_host=192.168.31.110 # The new node

[k3s_nodes]
k3s-master-1 ansible_host=192.168.31.50 ansible_user=k3s ansible_become_password="{{ k3s_password }}"
# ... other nodes ...

[all:vars]
# Global variables can go here
ansible_user=root # Default user if not specified per host/group
```
[Note: Variables like ansible_host, ansible_user, and group variables ([all:vars]) can also be defined here.]

playbooks/ (The "How"): This is where your Playbooks live. Playbooks are written in YAML and define a series of Tasks to be executed on hosts defined in your inventory. Each task typically uses an Ansible Module (the building blocks like apt, service, template, command, postgresql_user) to perform a specific action. Remember, good modules are idempotent. A basic task structure looks like this:

---
- name: Example Play # Descriptive name for the whole play
  hosts: proxmox_nodes # Which group(s) from inventory to target
  become: true # Execute tasks with root privileges (like sudo)

  tasks:
    - name: Update Proxmox # Descriptive name for this task
      apt: # The module being used
        update_cache: yes # Module parameters
        upgrade: dist

vars/ (The Data & Secrets): Store your variables here, separating them from your playbooks for better organization. You can have files for common variables (common_vars.yml) and crucially, for secrets (secrets.yml). Never commit plain-text passwords! Use Ansible Vault to encrypt sensitive files:

# Create a new encrypted file
ansible-vault create vars/secrets.yml

# Edit an existing encrypted file
ansible-vault edit vars/secrets.yml

# Run playbook asking for password
# ansible-playbook my_playbook.yml --ask-vault-pass

# Or better, use a password file (add vault.pass to .gitignore!)
ansible-playbook my_playbook.yml --vault-password-file=./vault.pass

Your secrets.yml might contain things like db_password: your_secret_password.

When you run ansible-vault create or edit, Ansible opens your default text editor ($EDITOR). Inside the editor, you just write standard YAML key-value pairs with your secrets, like this:

```yaml
# vars/secrets.yml
# --- This is just plain YAML while you edit! ---
k3s_password: "your_k3s_sudo_password"
app1_db_password: "supersafepassword123"
some_api_key: "xyz789abc123"
some_secret_value: 1234
```

Once you save and close the editor, Ansible encrypts the content. The actual file on disk becomes unreadable text, which is safe to commit to version control. This file is encrypted and can be decrypted with the password you picked when creating the vault!

ansible.cfg (The Settings): This optional file defines project-specific Ansible settings, overriding system defaults. Your script mentioned useful settings:

[defaults]
inventory = ./inventory/hosts.ini  # Default inventory file location
remote_user = root              # Default user to connect as
private_key_file = ~/.ssh/id_ed25519 # Default SSH key
host_key_checking = False       # Disable host key checking (use with caution!). Acceptable in trusted homelabs, but avoid in production - Disabling key checking skips verification of the remote host's identity, making you vulnerable to man-in-the-middle attacks.

[privilege_escalation]
become = True                   # Run tasks with privileges by default
become_method = sudo            # How to gain privileges
become_user = root              # Which user to become
become_ask_pass = False         # Don't ask for sudo password (assumes NOPASSWD)

Organizing your project this way keeps things tidy and makes your automation easier to understand, maintain, and share.

Homelab Automation in Action: Examples

Theory is great, but let's see Ansible solve real homelab problems, based on the examples from the YouTube video.

Before we look at example, do me a solid favor and check out my YouTube Channel, Let's Talk Dev

Let's Talk Dev - YouTube

I share my insights and tips on software engineering topics such as web development, databases, cloud computing, and more. Hi, I'm Mihai and I'm a full-stack software engineer with a passion for creating innovative and user-friendly solutions using web and cloud technologies. I have a home lab where I like to experiment with Kubernetes and other cutting-edge technologies. I'm also a big fan of open-source software. When I'm not coding, I enjoy photography, reading books, learning about finance and entrepreneurship, and watching movies.

youtube.com

Who knows, you might find those videos helpful and even subscribe!

1. Fixing Proxmox Subscription Error by Adding the Non-Subscription Repositories

Problem: Dealing with the Proxmox "no subscription" warnings by switching repositories, and keeping all Proxmox nodes consistently updated.
Solution: Use Ansible's dedicated apt_repository module to manage APT sources correctly, and the apt module for updates.

Fixing Repositories (using apt_repository):

# playbooks/proxmox_config.yml (Example Snippet)
---
- name: Fix Proxmox repository errors by adding the no-subscription repository
  hosts: proxmox_nodes
  become: true
  gather_facts: false # Facts not strictly needed for this part
  # vars_files: # Only needed if secrets were used here
  #  - ../vars/secrets.yml

  tasks:
    - name: Disable Proxmox enterprise repository
      ansible.builtin.apt_repository:
        repo: "deb [https://enterprise.proxmox.com/debian/pve](https://enterprise.proxmox.com/debian/pve) bookworm pve-enterprise" # Adjust 'bookworm' for your PVE version
        state: absent
        filename: pve-enterprise # Explicitly target the correct file

    - name: Add Proxmox no-subscription repository
      ansible.builtin.apt_repository:
        repo: "deb [http://download.proxmox.com/debian/pve](http://download.proxmox.com/debian/pve) bookworm pve-no-subscription" # Adjust 'bookworm'
        state: present
        filename: pve-no-subscription # Use a distinct filename

    - name: Disable Proxmox enterprise ceph repository (if applicable)
      ansible.builtin.apt_repository:
        repo: "deb [https://enterprise.proxmox.com/debian/ceph-quincy](https://enterprise.proxmox.com/debian/ceph-quincy) bookworm enterprise" # Adjust 'quincy'/'bookworm'
        state: absent
        filename: ceph-enterprise # Explicitly target the correct file

    - name: Add Proxmox no-subscription ceph repository (if applicable)
      ansible.builtin.apt_repository:
        repo: "deb [http://download.proxmox.com/debian/ceph-quincy](http://download.proxmox.com/debian/ceph-quincy) bookworm no-subscription" # Adjust 'quincy'/'bookworm'
        state: present
        filename: ceph-no-subscription # Use a distinct filename

    - name: Update apt cache after repo changes
      ansible.builtin.apt:
        update_cache: true

Explanation: This automation uses the ansible.builtin.apt_repository module, which is the idiomatic way to manage APT repositories. state: absent ensures the enterprise repositories are removed or commented out in their respective files (specified by filename), while state: present ensures the no-subscription repositories are added correctly. Finally, apt update_cache: true refreshes the package list.

2. Keeping Proxmox up to date!

Upgrading Proxmox Nodes (upgrade-proxmox.yml logic):

# playbooks/proxmox_upgrade.yml (Example Snippet)
---
- name: Upgrade Proxmox Nodes
  hosts: proxmox_nodes
  become: true

  tasks:
    - name: Update apt cache and perform dist-upgrade
      ansible.builtin.apt:
        update_cache: yes # Good practice before upgrade
        upgrade: dist # Handles kernel/PVE upgrades correctly
        autoclean: yes # Clean up downloaded package files
        autoremove: yes # Remove unused dependencies

    - name: Check if reboot is required
      ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_required_file

    - name: Reboot the server if required
      ansible.builtin.reboot:
        msg: "Reboot initiated by Ansible due to OS updates"
        connect_timeout: 5
        reboot_timeout: 600 # Wait up to 10 mins for reboot
        pre_reboot_delay: 0
        post_reboot_delay: 30 # Wait 30s after reboot before continuing
        test_command: uptime # Command to test if server is back up
      when: reboot_required_file.stat.exists # Only reboot if flag file exists

Explanation: This automation uses the apt module for the upgrade process (upgrade: dist is important for Proxmox). Crucially, it checks if the system flagged a required reboot (stat module) and then uses the reboot module only when that flag exists (when condition). Idempotency ensures nodes already up-to-date are simply skipped by the apt module.

3. Managing VMs Consistently

Problem: Ensuring all your VMs (e.g., Ubuntu servers running Docker or k3s) have essential tools like Python and specific libraries installed.

Solution: Target a group of VMs in your inventory and use the apt module.

# playbooks/vm_setup.yml (Example Snippet)
---
- name: Setup Base Packages on VMs
  hosts: k3s_nodes # Or a group like [all_vms]
  become: true # Needs sudo/root privileges
  # Assumes ansible_become_password might be needed (defined in inventory/vault)

  tasks:
    - name: Install Python, Pip, and other required packages
      ansible.builtin.apt:
        name:
          - python3
          - python3-pip
          - python3-psycopg2 # For PostgreSQL interaction later
          - python3-docker   # For Docker interaction later
        state: present
        update_cache: yes

Explanation: This playbook targets a specific group (k3s_nodes). The apt module ensures the listed packages are installed (state: present). If a package is already installed, Ansible makes no changes.

4. Automating PostgreSQL Initialization and Configuration

Problem: Manually creating database users and databases for different applications is repetitive and error-prone.

Solution: Use service-specific Ansible modules for more complex tasks.

# playbooks/postgres_setup.yml (Example Snippet)
---
- name: Configure PostgreSQL Users and Databases
  hosts: database_servers # Assuming a group for your DB server(s)
  become: true
  become_user: postgres # Run postgres tasks as the 'postgres' OS user, alternatively if postgres runs as root, keep using root.

  vars_files:
    - ../vars/secrets.yml # Load sensitive variables like passwords

  tasks:
    - name: Ensure database user exists for App1
      community.postgresql.postgresql_user:
        name: app1_user
        password: "{{ app1_db_password }}" # Password from vault
        state: present
      # This module handles creating the user idempotently

    - name: Ensure database exists for App1
      community.postgresql.postgresql_db:
        name: app1_db
        owner: app1_user
        state: present
      # This module handles creating the database idempotently

Explanation: This example uses modules from the community.postgresql collection (postgresql_user, postgresql_db). It runs tasks as the postgres system user (become_user) and pulls the password from an Ansible Vault encrypted file (vars_files and {{ app1_db_password }}). These modules are designed to be idempotent.

These examples show how Ansible moves beyond simple commands to reliably manage configurations, updates, and service setups across your homelab infrastructure.

Conclusion

As we've seen, Ansible is a fantastic tool for bringing order and efficiency to your homelab (and potentially your day job!). By defining your infrastructure as code, you reduce tedious manual work, ensure configurations are consistent across machines, and gain confidence through idempotent operations. The examples here – fixing Proxmox repos, updating nodes, setting up VMs, and configuring PostgreSQL – are just the beginning. Think about initial server setups, Docker container deployments, or keeping k3s clusters up-to-date; Ansible can handle it all.

Remember, the key concept is idempotency: run your playbooks as often as you need, knowing they'll only make changes necessary to reach your desired state.

I hope this gives you a solid starting point! For the full walkthrough and live demos, make sure to check out the companion Ansible Automation YouTube video.

What's the first thing you plan to automate in your homelab using Ansible? Let me know in the comments below!

If you found this article and the video helpful, consider subscribing to Let's Talk Dev on YouTube for more software engineering and DevOps content, and follow me here on Dev.to! Happy automating!

About me

I'm Mihai Farcas, a software architect with over a decade of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Functional Programming Face-Off: Python vs JavaScript vs Go!

Mihai Farcas — Wed, 05 Mar 2025 20:50:20 +0000

Functional programming has been gaining popularity in recent years, and for good reason. It offers a number of benefits over traditional imperative programming, such as improved code readability, testability, and maintainability.

In this article, we'll compare and contrast how three popular programming languages - Python, JavaScript, and Go - handle functional programming concepts. We'll explore how each language supports features like higher-order functions, immutability, and function composition, and discuss their strengths and weaknesses.

If you'd rather watch than read:

Check out the accompanying YouTube video!

1. Defining and Calling Functions

At the heart of functional programming lies, unsurprisingly, the function. The way functions are defined and invoked can significantly impact a language's suitability for functional programming paradigms. We'll examine how Python, JavaScript, and Go handle function definitions, looking at syntax, typing, and overall structure, setting the stage for more advanced functional concepts. Specifically how similar (or different) the syntax is, and the implications of different approaches to type systems (static, dynamic, type hints).

Python

def square(i: int) -> int:
    return i * i

result = square(5)
print(result)

In Python, functions are defined using the def keyword followed by the function name, parentheses for parameters, and a colon. The code block within the function is indented. Type hints can be optionally added to specify the expected types of parameters and return values.

JavaScript

const square = i => i * i;

const result = square(5);
console.log(result);

JavaScript offers a more compact syntax for defining functions, particularly with arrow functions. Arrow functions use the => operator, providing a concise way to express a function's logic.

Go

package main

import (
    "fmt"
)

func square(i int) int {
    return i * i
}

func main() {
    result := square(5)
    fmt.Println(result)
}

Go, a statically-typed language, requires explicit type declarations for both function parameters and return values. Functions are defined using the func keyword, followed by the function name, a parenthesized list of parameters (with their types), and the return type. The function body is enclosed in curly braces {}. Go's syntax is very similar to python in that it uses a keyword, followed by the name, followed by parameters. However, Go's strict typing and the need for explicit imports, even for basic operations like printing to the console (using the fmt package), introduce a slightly higher level of formality compared to Python and JavaScript. The Go example defines a function that, like the Python and JavaScript counterparts, takes an integer and returns its square.

However, Go differs significantly in its overall structure. Every Go file belongs to a package, and the package main declaration is special. It signifies that the file is part of the main package, which is the entry point for executable programs. Without package main and the func main() within it, Go wouldn't know where to begin executing your code. It's a fundamental difference from Python and JavaScript, where you don't need such explicit entry point declarations for simple scripts. Another key distinction is Go's requirement for explicit imports, even for basic functionalities like printing to the console. In the provided example, fmt.Println is used, requiring an import of the fmt (format) package.

2. Higher-Order Functions

This section delves into a cornerstone of functional programming: treating functions as first-class citizens. This means functions can be passed as arguments to other functions, returned as values from functions, and generally treated like any other variable. A direct consequence of this is the ability to create higher-order functions – functions that either take other functions as arguments or return them (or both). This allows for highly flexible and reusable code. We will also be touching on Closures, though the dedicated section for them comes later.

Python

def applyOperation(operation, a: int, b: int) -> int:
    return operation(a, b)


def add(a: int, b: int) -> int:
    return a + b


def subtract(a: int, b: int) -> int:
    return a - b


result = applyOperation(add, 10, 5)
print(result)  # Output: 15

result = applyOperation(subtract, 10, 5)
print(result)  # Output: 5

Python supports higher-order functions elegantly. In the Python snippet, applyOperation is a higher-order function because it takes another function (operation) as an argument. add and subtract are regular functions that perform addition and subtraction, respectively. applyOperation then calls the passed-in function (operation) with the provided arguments (a and b). Notice that the type hints are optional in Python. While the example does use type hints for clarity (specifying that operation should be a function taking two integers and returning an integer, and that a and b are integers), they are not enforced at runtime by default. This makes the Python code concise and similar in that aspect to JavaScript.

JavaScript

function applyOperation(operation, a, b) {
  return operation(a, b);
}

function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

let result = applyOperation(add, 10, 5);
console.log(result); // Output: 15

result = applyOperation(subtract, 10, 5);
console.log(result); // Output: 5

JavaScript, like Python, treats functions as first-class citizens and readily supports higher-order functions. The JavaScript snippet demonstrates the same applyOperation, add, and subtract structure as the Python example. applyOperation accepts a function (operation) and calls it with arguments a and b. Because JavaScript is dynamically typed, there are no type annotations. The code is very concise and mirrors the Python example in its functional approach.

Go

package main

import "fmt"

func applyOperation(operation func(int, int) int, a int, b int) int {
    return operation(a, b)
}

func add(a, b int) int {
    return a + b
}

func subtract(a, b int) int {
    return a - b
}

func main() {
    result := applyOperation(add, 10, 5)
    fmt.Println(result) // Output: 15

    result = applyOperation(subtract, 10, 5)
    fmt.Println(result) // Output: 5
}

Go also supports higher-order functions, although with its characteristic explicitness due to static typing. In the Go snippet, applyOperation is again the higher-order function. However, the type of the operation parameter is explicitly declared: func(int, int) int. This signifies that operation must be a function that takes two int arguments and returns an int. This explicit type declaration is a key difference from Python (with optional type hints) and JavaScript (dynamically typed). The add and subtract functions are defined with their types, and applyOperation calls the provided function just like in the other languages. While all three languages achieve the same result, Go's static typing makes the function signatures more verbose. This reinforces Go's emphasis on explicitness and compile-time type safety.

3. Closures

Closures are a powerful feature often used in conjunction with higher-order functions. A closure is a function that "remembers" its surrounding environment (its lexical scope) even after the outer function that created it has finished executing. This means the inner function can access and modify variables defined in the outer function's scope, even if the outer function has returned. This ability to "capture" state is crucial for many functional programming patterns.

Python

def createCounter():
    count = 0

    def counter():
        nonlocal count  # count is not a local variable,
        # it refers to the count variable in the outer scope
        count += 1
        return count

    return counter


counter = createCounter()
print(counter())
print(counter())

The Python snippet demonstrates a classic closure example with createCounter. createCounter is a function that returns another function, counter. The key here is the nonlocal count declaration within counter. Because Python has stricter scoping rules, you need to explicitly tell the inner function (counter) that count is not a local variable within counter itself, but rather refers to the count variable in the enclosing *scope of createCounter. Without nonlocal, Python would create a new, local count variable inside counter, and the outer count would remain unchanged. The returned counter function *"closes over" the count variable, maintaining its state between calls.

JavaScript

const createCounter = () => {
  let count = 0;
  return () => {
    count++;
    return count;
  };
};

const counter = createCounter();
console.log(counter());
console.log(counter());

JavaScript handles closures very naturally. In the JavaScript snippet, createCounter also returns an anonymous function (the closure). This inner function increments and returns the count variable. Crucially, JavaScript's scoping rules automatically allow the inner function to access and modify the count variable from the createCounter scope, even after createCounter has completed. There's no need for a special keyword like Python's nonlocal; the closure behavior is implicit. This makes the JavaScript code very concise.

Go

package main

import "fmt"

func createCounter() func() int {
    count := 0
    return func() int {
            count++
            return count
    }
}

func main() {
    counter := createCounter()
    fmt.Println(counter())
    fmt.Println(counter())
}

Go's closure mechanism is similar to JavaScript's. The Go snippet defines createCounter, which returns an anonymous function that increments and returns the count variable. Like JavaScript, and unlike Python, there's no need for any special declaration to indicate that count is from the outer scope. The inner function automatically has access to and can modify count. The returned function "closes over" the count variable, preserving its state between invocations. Go's approach, like JavaScript's, is straightforward and doesn't require extra keywords for closure behavior. The syntax, returning a func() int, clearly expresses that createCounter returns a function that takes no arguments and returns an integer.

4. Partial Application

Partial application is a technique for creating new functions from existing ones by pre-filling some of their arguments. It's a way to specialize a general function into a more specific one. Instead of calling a function with all its arguments at once, you "fix" some of the arguments, creating a new function that expects only the remaining arguments. This can lead to more reusable and readable code.

Python

def createGreeting(greeting: str):
    def greetingFn(name: str) -> str:
        return f"{greeting} {name}"

    return greetingFn


firstGreeting = createGreeting("Well, hello there ")
secondGreeting = createGreeting("Hola ")
print(firstGreeting("Remi"))
print(secondGreeting("Ana"))

In the Python snippet, createGreeting is a function that demonstrates partial application. It takes a greeting string as input and returns a new function (greetingFn). This returned function takes a name string and combines it with the pre-filled greeting. When you call createGreeting("Well, hello there "), you're not getting the final greeting string; you're getting a new function (firstGreeting) that has the "Well, hello there " greeting already "baked in." You can then call firstGreeting with different names to get the complete greeting. The same principle applies to secondGreeting, prefilling a different initial greeting. The type hints help show the flow: createGreeting takes a string and returns a function that takes a string and returns a string.

JavaScript

const createGreeting = (greeting) => {
  return (name) => {
    return `${greeting} ${name}`;
  };
};

const firstGreeting = createGreeting("Well, hello there ");
const secondGreeting = createGreeting("Hola ");
console.log(firstGreeting("Remi"));
console.log(secondGreeting("Ana"));

The JavaScript snippet achieves the same result using a concise arrow function syntax. createGreeting takes a greeting and returns another arrow function that takes a name. This inner function uses template literals (backticks) to create the final greeting string. Like the Python example, calling createGreeting with a greeting creates a new, specialized function (firstGreeting, secondGreeting) with that greeting pre-applied. The nested arrow functions clearly illustrate the process of creating a function that returns another function.

Go

package main

import "fmt"


func createGreeting(greeting string) func(string) string {
    return func(name string) string {
            return fmt.Sprintf("%s %s", greeting, name)
    }
}

func main() {
    firstGreeting := createGreeting("Well, hello there ")
    secondGreeting := createGreeting("Hola ")
    fmt.Println(firstGreeting("Remi"))
    fmt.Println(secondGreeting("Ana"))
}

The Go snippet implements partial application in a similar manner. createGreeting takes a greeting string and returns a function that takes a name string and returns the combined string. Go's explicit type signature, func(string) string, clearly indicates that createGreeting returns a function. The use of fmt.Sprintf is Go's way of formatting strings, analogous to Python's f-strings and JavaScript's template literals. The result is the same: firstGreeting and secondGreeting become specialized functions with their respective greetings pre-filled. Go's syntax, while slightly more verbose due to type declarations, achieves the same functional goal.

5. Currying

Currying is a technique closely related to partial application, but with a subtle, yet important, difference. While partial application allows you to pre-fill any number of arguments, currying transforms a function that takes multiple arguments into a sequence of functions, each taking a single argument. Each function in the sequence returns the next function in the sequence, until all arguments have been supplied, at which point the final result is returned. Currying isn't built-in to any of these languages; we need to implement a curry function ourselves.

Python

def curry(fn):
    def curried(*args):
        if len(args) >= fn.__code__.co_argcount:
            return fn(*args)
        else:
            return lambda *args2: curried(*(args + args2))

    return curried


def add(a: int, b: int, c: int) -> int:
    return a + b + c


result = curry(add)(1)(2)(3)
print(result)  # Output: 6

The Python snippet implements a general-purpose curry function. This function is more complex than the previous examples because it needs to handle functions with an arbitrary number of arguments. It uses fn.__code__.co_argcount to determine the number of arguments the original function (fn) expects. The inner curried function uses *args to collect arguments. If enough arguments have been collected (the length of args is greater or equal to the number of arguments that fn expects), it calls the original function fn with those arguments. Otherwise, it returns a new lambda function that takes more arguments (*args2), combines them with the existing arguments (args + args2), and recursively calls curried again. This recursive process continues until all arguments are provided. The add function, which takes three arguments, is then curried and called with one argument at a time: curry(add)(1)(2)(3).

JavaScript

function curry(fn) {
  return function curried(...args) {
    if (args.length >= fn.length) {
      return fn.apply(this, args);
    } else {
      return (...args2) => curried.apply(this, args.concat(args2));
    }
  };
}

function add(a, b, c) {
  return a + b + c;
}

const result = curry(add)(1)(2)(3);
console.log(result); // Output: 6

The JavaScript snippet provides a similar curry function implementation. It uses fn.length to get the number of arguments the original function expects. The curried function uses the rest parameter syntax (...args) to gather arguments. If enough arguments are present, it calls the original function fn using apply (to handle the this context correctly). Otherwise, it returns a new function that takes more arguments (...args2), concatenates them with the existing arguments using concat, and recursively calls curried. Like the Python version, this allows us to call a curried function with one argument at a time, as shown with curry(add)(1)(2)(3). The Javascript and Python versions are strikingly similar.

Go

The Go snippet presents a significantly more complex implementation of curry. This is where the differences between Go's static typing and the dynamic typing of Python and JavaScript become most apparent. Because Go is statically typed, creating a generic curry function that works with functions of any arity (number of arguments) and any type requires using the reflect package. Reflection allows us to inspect and manipulate types at runtime, which is necessary because the curry function doesn't know the types of the function it's currying beforehand.

package main

import (
    "fmt"
    "reflect"
)


func curry(f interface{}) interface{} {
    ft := reflect.TypeOf(f)
    if ft.Kind() != reflect.Func {
        panic("curry: argument must be a function")
    }

    numArgs := ft.NumIn()
    args := make([]reflect.Value, 0, numArgs)

    var curried func(x reflect.Value) interface{}
    curried = func(x reflect.Value) interface{} {
        args = append(args, x)
        if len(args) == numArgs {
            return reflect.ValueOf(f).Call(args)[0].Interface()
        } else {
            return curried
        }
    }

    return curried
}

func add(a, b, c int) int {
    return a + b + c
}

func main() {
    curriedAdd := curry(add)

    add1 := curriedAdd.(func(reflect.Value) interface{})(reflect.ValueOf(1))
    add12 := add1.(func(reflect.Value) interface{})(reflect.ValueOf(2))
    result := add12.(func(reflect.Value) interface{})(reflect.ValueOf(3)).(int)

    fmt.Println(result) // Output: 6
}

The curry function first checks if the input f is actually a function using reflect.TypeOf(f).Kind() != reflect.Func. It then determines the number of expected arguments using ft.NumIn(). It uses a slice args (of type reflect.Value) to store the accumulated arguments. The curried function (a closure) is defined recursively. When called with an argument x, it appends x to args. If enough arguments have been collected, it calls the original function using reflect.ValueOf(f).Call(args)[0].Interface(). This line is crucial: it converts the function f to a reflect.Value, calls it with the collected arguments, extracts the result (which is also a reflect.Value), and then converts it back to a regular Go interface{} using .Interface(). If not enough arguments have been collected, it returns itself (curried), continuing the currying process.

The main function shows how to use the curried function. Because the curry function returns the most generic type interface{}, we need multiple type assertions (e.g., .(func(reflect.Value) interface{})) to convert the intermediate curried functions to their correct types before we can call them. This is much more verbose than the Python and JavaScript examples, highlighting the added complexity of implementing currying in a statically-typed language without generics (prior to Go 1.18). The final result is retrieved and printed, demonstrating that the currying works, but at the cost of significantly more complex code. This example clearly shows that functional programming patterns like currying, while possible in Go, are often more natural and concise in dynamically typed languages.

6. Immutability

Immutability is a core principle of functional programming. An immutable object is one whose state cannot be changed after it's created. This contrasts with mutable objects, which can be modified in place. Immutability simplifies reasoning about code, prevents unintended side effects, and is crucial for concurrent programming (as immutable data is inherently thread-safe). Different languages have varying levels of built-in support for immutability.

Python

import copy

points1 = [{"x": 1, "y": 2}, {"x": 3, "y": 4}]

# Shallow Copy
points2 = copy.copy(points1)
points2.append({"x": 5, "y": 6})  # Modifies only points2
points2[0]["x"] = 10  # Modifies the object in both lists

print(points1)  # Output: [{'x': 10, 'y': 2}, {'x': 3, 'y': 4}] (affected!)
print(points2)  # Output: [{'x': 10, 'y': 2}, {'x': 3, 'y': 4}, {'x': 5, 'y': 6}]

# Deep Copy
points3 = copy.deepcopy(points1)
points3[0]["x"] = 20  # Modifies only points3

print(points1)  # Output: [{'x': 10, 'y': 2}, {'x': 3, 'y': 4}] (unaffected)
print(points3)  # Output: [{'x': 20, 'y': 2}, {'x': 3, 'y': 4}]

Python's built-in data structures, like lists and dictionaries, are mutable. This means you can modify them directly after creation. The Python snippet highlights the importance of understanding the difference between shallow and deep copies when working with nested mutable objects.

Shallow Copy (copy.copy()): A shallow copy creates a new top-level object, but the elements within that object are still references to the original objects. So, if you have a list of dictionaries, a shallow copy will create a new list, but the dictionaries inside the new list will be the same dictionaries as in the original list. Modifying a nested object in the shallow copy will affect the original object as well. As shown, appending to points2 affects only the copy because append creates a new array, but modifying points2[0]["x"] modifies the underlying object referenced by both points1 and points2.
Deep Copy (copy.deepcopy()): A deep copy recursively creates new copies of all objects, including nested ones. This means modifying a nested object in a deep copy will not affect the original object. As shown, after a deep copy, modifying points3[0]["x"] only affects points3, leaving points1 unchanged. You need to explicitly use copy.deepcopy() to achieve true immutability with nested mutable objects in Python.

JavaScript

const points1 = [{ x: 1, y: 2 }, { x: 3, y: 4 }];
const points2 = [...points1]; // Creates a shallow copy

points2.push({ x: 5, y: 6 }); // Modifies only points2
points2[0].x = 10; // Modifies the object in both arrays

console.log(points1); // Output: [{ x: 10, y: 2 }, { x: 3, y: 4 }] (affected!)
console.log(points2); // Output: [{ x: 10, y: 2 }, { x: 3, y: 4 }, { x: 5, y: 6 }]

JavaScript, like Python, has mutable objects (arrays and objects) by default. The JavaScript snippet uses the spread operator (...) to create a shallow copy of an array of objects.

Spread Operator for Arrays: The spread operator, when used with an array, creates a shallow copy. Similar to Python's copy.copy(), it creates a new array, but the objects within the array are still references to the same objects in the original array. Appending to points2 doesn't modify points1, as a new array instance is created, but changing points2[0].x does modify the corresponding object in points1 because it's a shared reference.
Deep Copying in JavaScript: JavaScript doesn't have a built-in deep copy function like Python's copy.deepcopy(). You typically need to use a custom function or a library (like Lodash's _.cloneDeep) to perform a deep copy. One common (but potentially problematic) approach is to use JSON.parse(JSON.stringify(object)), but this only works for objects that can be safely serialized to JSON (no functions, circular references, etc.). The lack of a standard, built-in deep copy mechanism is a notable weakness of JavaScript in terms of supporting immutability.

Go

package main

import "fmt"

type Point struct {
    X int
    Y int
}

func main() {
    points1 := []Point{{1, 2}, {3, 4}}
    points2 := points1 // Creates a copy of the slice header and underlying array

    // Appending creates a new slice, doesn't modify points1
    points2 = append(points2, Point{5, 6})

    // Modifying an element in points2 creates a copy of that element.
    points2[0].X = 10

    fmt.Println(points1) // Output: [{1 2} {3 4}] (original unaffected)
    fmt.Println(points2) // Output: [{10 2} {3 4} {5 6}]
}

Go takes a different approach to immutability. Go's structs are value types. When you assign a struct to a new variable or pass it to a function, a copy of the struct is created. This promotes immutability by default.

Value Types: In the Go snippet, Point is a struct. When points2 := points1 is executed, points2 receives a copy of the slice header. Importantly, in this case, the underlying array elements (the Point structs) are also copied because they are value types.
append: The append function in Go is designed to work well with immutability. When you append to a slice, Go might create a new underlying array if the existing array doesn't have enough capacity. This means that append often returns a new slice, leaving the original slice untouched. As demonstrated, points2 = append(points2, Point{5, 6}) creates a new slice for points2, leaving points1 unmodified.
Modifying Struct Fields: Because of the value semantics of structs, changing a field within the struct inside a slice in Go doesn't change the value of the struct in another.
In the example provided, modifying points2, does not affect points1.

Go's design, with its emphasis on value types for structs and the behavior of append, encourages immutability. While you can use pointers to create mutable behavior in Go, the language's default behavior for structs promotes immutability, making it easier to write code with fewer side effects. This is a significant advantage of Go for functional programming.

7. Map, Filter, Reduce

Map, filter, and reduce are fundamental higher-order functions in functional programming that operate on collections of data (like lists or arrays). They provide a concise and declarative way to transform and process data without using explicit loops.

Map: Applies a given function to each element of a collection, producing a new collection with the transformed elements. The original collection remains unchanged.
Filter: Creates a new collection containing only the elements from the original collection that satisfy a given condition (a predicate function).
Reduce: Combines all elements of a collection into a single value using a specified function. This function takes an accumulator and the current element, updating the accumulator with each iteration.

Python

from functools import reduce

# Map: Square each number
numbers = [1, 2, 3, 4, 5]
squares = list(map(lambda n: n * n, numbers))
print("Squares:", squares)

# Filter: Get even numbers
evens = list(filter(lambda n: n % 2 == 0, numbers))
print("Evens:", evens)

# Reduce: Sum all numbers
sum_of_numbers = reduce(lambda acc, n: acc + n, numbers, 0)  # 0 is the initial value
print("Sum:", sum_of_numbers)

Python has built-in support for map, filter, and reduce.

map: The map function takes a function and an iterable (like a list) as arguments. In the example, lambda n: n * n is an anonymous function (a lambda) that squares a number. map applies this function to each element of the numbers list. The result of map is an iterator, so we use list() to convert it to a list for printing.
filter: The filter function also takes a function and an iterable. The function (lambda n: n % 2 == 0) acts as a predicate, returning True for even numbers and False otherwise. filter returns an iterator containing only the elements for which the predicate returns True. Again, we use list() to convert it to a list.
reduce: reduce is not directly built-in; it's part of the functools module. It takes a function, an iterable, and an optional initial value. The function (lambda acc, n: acc + n) takes the accumulator (acc) and the current element (n), returning the updated accumulator. reduce applies this function cumulatively to the items of the sequence, from left to right, so as to reduce the sequence to a single value. In the snippet, it calculates the sum of all numbers in the list.

JavaScript

// Map: Square each number
const numbers = [1, 2, 3, 4, 5];
const squares = numbers.map(n => n * n);
console.log("Squares:", squares);

// Filter: Get even numbers
const evens = numbers.filter(n => n % 2 === 0);
console.log("Evens:", evens);

// Reduce: Sum all numbers
const sum = numbers.reduce((acc, n) => acc + n, 0); // 0 is the initial value
console.log("Sum:", sum);

JavaScript also provides map, filter, and reduce as built-in methods on arrays. This makes the syntax very concise and readable.

map: The map method is called directly on the numbers array. It takes a callback function (n => n * n) that's applied to each element, creating a new array (squares) with the results.
filter: The filter method, similarly, is called on the array. It takes a predicate function (n => n % 2 === 0) and returns a new array (evens) containing only the elements that satisfy the predicate.
reduce: The reduce method is also called on the array. It takes a callback function ((acc, n) => acc + n) and an initial value (0). The callback function takes the accumulator (acc) and the current element (n), returning the updated accumulator. reduce iterates through the array, accumulating the result into the sum variable. The JavaScript syntax for these operations is very clean and directly integrated into the array object.

Go

package main

import (
    "fmt"
)

func Map[T, U any](slice []T, f func(T) U) []U {
    result := make([]U, len(slice))
    for i, v := range slice {
        result[i] = f(v)
    }
    return result
}

func Filter[T any](slice []T, f func(T) bool) []T {
    var result []T
    for _, v := range slice {
        if f(v) {
            result = append(result, v)
        }
    }
    return result
}

func Reduce[T, U any](slice []T, initial U, f func(U, T) U) U {
    result := initial
    for _, v := range slice {
        result = f(result, v)
    }
    return result
}

func main() {
    numbers := []int{1, 2, 3, 4, 5}

    // Map: Square each number
    squares := Map(numbers, func(n int) int { return n * n })
    fmt.Println("Squares:", squares)

    // Filter: Get even numbers
    evens := Filter(numbers, func(n int) bool { return n%2 == 0 })
    fmt.Println("Evens:", evens)

    // Reduce: Sum all numbers
    sum := Reduce(numbers, 0, func(acc int, n int) int { return acc + n })
    fmt.Println("Sum:", sum)
}

Go, unlike Python and JavaScript, does not have built-in map, filter, and reduce functions. However, you can easily implement them using Go's for...range loops and functions. The Go snippet shows generic implementations of Map, Filter, and Reduce using Go 1.18+ generics.

Map: The provided Map function takes a slice of type T, a function that transforms a T to a U, and it returns a slice of type U. The types T and U can be any types. It iterates through the input slice, applies the provided function f to each element, and stores the result in a new slice.
Filter: The Filter function takes a slice of type T and a predicate function (a function that returns a boolean). It iterates through the slice, and for each element where the predicate function returns true, it appends the element to a new slice.
Reduce: The Reduce function takes a slice of type T, an initial value of type U, and a function which takes a value of type U and a value of type T, returning another U.

While Go requires more code to achieve the same functionality as Python and JavaScript's built-ins, the generic implementations provide flexibility and type safety. The use of anonymous functions (like func(n int) int { return n * n }) makes the code resemble the lambda expressions used in Python and JavaScript.

8. Function Composition

Function composition is the process of combining two or more functions to create a new function. The output of one function becomes the input of the next, forming a pipeline of operations. This is a powerful way to build complex logic from simpler, reusable building blocks, enhancing code modularity and readability. It avoids creating intermediate variables and nested function calls.

Python

from functools import reduce


def compose(*funcs):
    return lambda x: reduce(lambda acc, f: f(acc), reversed(funcs), x)


def add_one(x):
    return x + 1


def square(x):
    return x * x


def multiply_by_two(x):
    return x * 2


composed = compose(square, multiply_by_two, add_one)  # Order is correct
result = composed(5)  # ((5 + 1) * 2)^2 = 144
print("Composed result:", result)

The Python snippet defines a compose function that takes a variable number of functions (*funcs) as arguments. It returns a new function (a lambda) that takes an initial value x. Inside the lambda, it uses reduce to apply the functions in sequence. The trick here is reversed(funcs). reduce normally applies functions from left to right, but in function composition, we usually want the rightmost function to be applied first. reversed(funcs) reverses the order of functions, so reduce effectively applies them from right to left. The functions add_one, square, multiply_by_two demonstrates what functions can be composed. The order matters in composition. The comment ((5 + 1) * 2)^2 = 144 shows how the functions are applied step by step, starting with add_one.

JavaScript

const compose = (...funcs) => x => funcs.reduceRight((acc, f) => f(acc), x);

const addOne = x => x + 1;
const square = x => x * x;
const multiplyByTwo = x => x * 2;

const composed = compose(square, multiplyByTwo, addOne); // Order is correct
const result = composed(5); // ((5 + 1) * 2)^2 = 144
console.log("Composed result:", result);

The JavaScript snippet defines a compose function using arrow function syntax. It's very concise. ...funcs collects all function arguments into an array. The returned function takes an initial value x and uses funcs.reduceRight((acc, f) => f(acc), x). The reduceRight method is the key here; it's a built-in array method that applies a function against an accumulator and each element of the array (from right to left), reducing it to a single value. This achieves the correct order of function application directly, without needing to reverse the function list like in Python.

Go

package main

import "fmt"

func compose[T any](funcs ...func(T) T) func(T) T {
    return func(x T) T {
        result := x
        for _, f := range funcs {
            result = f(result)
        }
        return result
    }
}

func addOne(x int) int {
    return x + 1
}

func square(x int) int {
    return x * x
}

func multiplyByTwo(x int) int {
    return x * 2
}

func main() {
    composed := compose(addOne, multiplyByTwo, square)
    result := composed(5) // ((5 + 1) * 2)^2 = 144
    fmt.Println("Composed result:", result)
}

The go snippet defines a compose function takes advantage of Go 1.18+ generics.
It is defined to take a variadic number of functions (funcs ...func(T) T). The T represents any data type. The key difference is in how the functions are applied. It uses a simple for...range loop to iterate through the funcs slice in the order they were provided. Unlike Python and JavaScript, this Go compose function applies functions from left to right. This is a deliberate choice to make the code simpler, and in the provided main() function, this is accounted for. The composed variable receives the composition, but the functions are listed in the reverse order (addOne, multiplyByTwo, square) compared to what would be mathematically expected. The final call to composed(5) produces correct results.

Conclusion

Each of these three languages brings its own unique approach to functional programming. Python and JavaScript, with their dynamic typing and built-in support for many functional features, offer a relatively lower barrier to entry. Go, on the other hand, while requiring a bit more effort to implement some functional concepts, provides strong immutability support and explicitness, which can be advantageous in certain scenarios.

Subscribe for More!

If you enjoyed this comparison, be sure to subscribe to my YouTube channel for more content on programming languages, software development, and other tech topics.

Let me know in the comments which language you prefer for functional programming and why!

Let's Talk Dev - YouTube

youtube.com

About me

I'm Mihai Farcas, a software engineer with a few years of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Secure Self-Hosting with Cloudflare Tunnels and Docker: Zero Trust Security

Mihai Farcas — Wed, 08 Jan 2025 11:07:20 +0000

For many software engineers, the allure of self-hosting is undeniable. It represents autonomy, a playground for experimentation and helps you learn about the infrastructure that makes the internet work.

However, the freedom of self-hosting comes with a critical responsibility: security. Exposing your home network to the internet is like opening your front door to everyone. Without proper protection, your home setup can quickly become a target.

This article explains the key methods and tools for securing your self-hosted applications, changing it from a weak spot into a secure setup. We'll go through DNS, look at the threat of DDoS attacks, and show how Cloudflare Tunnels, especially with Docker, provide a strong solution for achieving zero-trust security for your self-hosted environment.

To complement this written guide, I've created two accompanying YouTube videos:

This video delves into the underlying concepts of DNS, DDoS attacks, reverse proxies, and how Cloudflare's infrastructure works to mitigate these threats.

This video provides a hands-on walkthrough, demonstrating how to set up Cloudflare Tunnels with Docker, securing a sample web application step-by-step.

Why Self-Hosting Needs Special Attention

When you self-host a website, you're essentially making your home network a part of the public internet. This drastically increases your attack surface. Let's look at some key implications:

Your Public IP Address: This is your home network's "address" on the internet. Traditionally, to make your website accessible, you'd point your domain's DNS records to this IP. This direct association creates a clear target for malicious actors.
Open Ports: To serve web traffic, you typically need to open ports 80 (HTTP) and 443 (HTTPS) on your router, forwarding them to your web server. Open ports are like open doors, inviting potential intruders to probe your network for weaknesses.
Dynamic IP Addresses: Most residential ISPs assign dynamic IP addresses, which change periodically. This makes self-hosting less reliable because your website's DNS records need to be updated constantly to point to the correct IP. If they're not, your site can become unreachable. We'll see how to solve this problem later on.

What is DNS and how does it work?

Domain Name System (DNS) is like the internet's phone book. It's the technology that translates human-friendly website names (like www.example.com) into the numerical IP addresses that computers use to communicate. Without DNS, browsing the web would be incredibly difficult.

However, for self-hosting, the traditional DNS system has a weakness: it can expose your home IP address. When someone looks up your domain, the DNS lookup process eventually leads back to your home's IP address, if you are using a basic self hosting setup.

DDoS Attacks: The Digital Siege

Once a malicious actor gets hold of your home IP address, which as we saw, can be exposed through the DNS resolution process, they can launch a Distributed Denial of Service (DDoS) attack.

DDoS attacks are a major threat to self-hosted websites. In a DDoS attack, attackers use a network of infected computers (called a "botnet") to flood your server with traffic. This overwhelms your server's resources, making your website slow or completely inaccessible to legitimate users.

For self-hosted sites, a DDoS attack can be devastating. Not only can it take your website offline, but the flood of traffic can also disrupt your entire home network, affecting other services and even your household's internet access.

If you're interested in diving deeper into topics like this, including software engineering, self-hosting, home labs, Docker, Kubernetes, and other DevOps practices, head over to the Let's Talk Dev YouTube channel.

Let's Talk Dev - YouTube

youtube.com

Cloudflare: Your First Line of Defense

Cloudflare, at its core, is a Content Delivery Network (CDN) with a strong focus on security. It acts as an intermediary between your users and your origin server, providing numerous benefits:

Reverse Proxy: Cloudflare operates as a reverse proxy, meaning all traffic to your website flows through its network first. This masks your origin server's IP address, shielding it from direct exposure.
DNS Resolution Through Cloudflare: When you use Cloudflare's DNS services, the resolution process is handled by their vast network of globally distributed DNS servers. This not only improves performance but also adds another layer of obfuscation, preventing attackers from easily discovering your home IP through DNS queries.
Basic DDoS Mitigation: Cloudflare's network is designed to absorb and filter malicious traffic. Their anycast network distributes traffic across numerous data centers, making it difficult for attackers to overwhelm a single point. It also identifies and blocks known malicious traffic patterns, preventing them from reaching your server.

Limitations of Traditional Cloudflare Protection for Self-Hosting

While Cloudflare's basic DNS and DDoS protection offer a substantial improvement, they are not a complete solution for self-hosting scenarios. Here's why:

To allow Cloudflare to communicate with your web server, you still need to open ports 80 and 443 on your router and forward them to your server. This keeps a potential vulnerability open. Attackers can directly target those open ports, attempting to exploit any weaknesses in your web server (i.e. Nginx) or other services running on your network.

This also doesn't get rid of the dynamic IP address issue. If your home IP address changes, your website becomes inaccessible until you manually update your DNS records on Cloudflare. This manual intervention is prone to errors and can lead to downtime. There are more automated solutions out there, however they all rely on making the change on a schedule dinterval, which still leads to downtime.

Also, while Cloudflare hides your IP from direct DNS queries, determined attackers might still uncover it through other means, such as examining email headers or exploiting vulnerabilities in third-party services you use.

Cloudflare Tunnels: The Zero Trust Solution

Cloudflare Tunnels provide a paradigm shift in how you expose self-hosted services to the internet. Instead of opening inbound ports and relying on traditional DNS pointing to your home IP, Tunnels create a secure, outbound-only connection from your server to the Cloudflare network. This fundamentally changes the security model to one of "zero trust."

How Cloudflare Tunnels Work: A Deep Dive

cloudflared Daemon: You install a lightweight agent called cloudflared on your server (or within a Docker container, as we'll see later). This daemon is responsible for establishing and maintaining the secure tunnel.
Outbound-Only Connection: cloudflared initiates an outbound connection to Cloudflare's edge network. This is crucial because it eliminates the need to open any inbound ports on your router, drastically reducing your attack surface.
Tunnel Creation: You create a tunnel in the Cloudflare dashboard, giving it a unique name.
Service Configuration: You configure the tunnel to route traffic to specific services running on your local network. For instance, you can specify that traffic for www.example.com should be routed to your web server running on port 80. So you can choose which services are accessible through the tunnel and which aren't.
DNS Integration: Finally, when creating the tunnel, DNS records in Cloudflare are automatically configured to point to the Cloudflare network, specifying the tunnel to be used for each service. So even if your home IP changes, the tunnel will still be opened and connected to Cloudflare's network.

To recap, the benefits of using Cloudflare Tunnels are:

Not reliant on opened ports
Dynamic IP resilience
Granular access control
Better security
Simplified management

Docker and Cloudflare Tunnels

You can run the cloudflared daemon within a separate Docker container alongside your application containers.

You can also use cloudflared in a docker-compose.yml. Docker Compose simplifies the process of defining and managing multi-container applications. You can define your web application, database, and cloudflared container in a single docker-compose.yml file, ensuring they call all communicate between each other easily through Docker's internal DNS.

Refer to my accompanying YouTube video for a detailed step-by-step guide on setting up Cloudflare Tunnels with Docker. The video covers:

Creating and managing tunnels through the Cloudflare dashboard
Installing and configuring cloudflared within a Docker container
Using docker compose (and Portainer) to expose a self hosted service to the internet!

The tldr; is:

cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run
    environment:
      - "TUNNEL_TOKEN=${TUNNEL_TOKEN}"

Embracing Secure Self-Hosting

Self-hosting offers a unique blend of control, flexibility, and learning opportunities. However, security should always be paramount. Cloudflare Tunnels, provide a robust and elegant solution for securing your self-hosted environment.

About me

I'm Mihai Farcas, a software engineer with a few years of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Kubernetes Debugging Made Easy with mirrord

Mihai Farcas — Fri, 25 Oct 2024 18:04:46 +0000

Developing and debugging applications in a Kubernetes cluster can be complex. However, mirrord, an open-source project by MetalBear, offers a solution to simplify this process.

The Use Case

Imagine you're a software engineer working on a complex project involving multiple interconnected microservices. You encounter a bug that only occurs in the staging environment. Reproducing this bug locally is a nightmare for two main reasons:

Running the application locally requires a complex setup with multiple microservices, making it difficult to replicate the staging environment accurately.
The bug may be data-dependent, and you lack the specific data present in the staging environment. Downloading this data from the staging database is a convoluted process.

This is where mirrord comes in!

What is mirrord?

mirrord is an open-source tool designed to simplify the development and debugging of applications running in Kubernetes clusters. It achieves this by enabling developers to work on their code directly within the cluster, eliminating the need for extensive local setups or continuous deployments to staging environments.

How does it work?

mirrord operates as a "mirror" (hence the name) between your local development environment and the Kubernetes cluster. It intercepts requests destined for your application pods in the cluster and duplicates them, sending a copy to your local machine.

This allows you to run and debug your code locally while interacting with real production data and services within the cluster. In essence, it's like having a magic portal that connects your local machine to the live Kubernetes environment without affecting actual users.

Example: Debugging a Production-Only Bug

The video demonstrates how mirrord can help debug an upper-environment-only bug. The application, written in Go, runs fine locally but displays an error in the production Kubernetes cluster. In the following video I show how to use the mirrord along with it's VS Code extension to debug the application. mirrord allows you to select a target to mirror (pod or deployment) and provides access to the same resources and environment variables as the remote application.

Keep in mind you have to have kubectl access to the Kubernetes cluster you want to target pods in.

Who is Mirrord for?

Developers Tired of the "Push-and-Pray" Development Cycle

If you're tired of the constant cycle of pushing code to a staging environment and praying it works, Mirrord is for you. With mirrord, you can see your code running in a near-production environment instantly, without waiting for deployments.

Teams Struggling with Complex Local Setups

Setting up a local environment that accurately mirrors a production Kubernetes cluster can be a real headache, especially in microservice architectures. mirrord eliminates this pain by allowing you to develop and debug directly in the cluster.

Developers Who Need to Debug with Production-Like Data

Debugging with real-world data is crucial for finding and fixing those tricky bugs that only show up in upper environments. mirrord lets you do this safely, without impacting your live application.

Anyone Facing Challenges in Reproducing and Fixing Environment-Specific Bugs

Some bugs just won't show up in your local environment, no matter how hard you try to replicate it. mirrord makes it easy to reproduce and fix these environment-specific bugs by giving you direct access to the target environment.

TLDR; mirrord is for any developer who wants to simplify Kubernetes development and debugging, improve their workflow, and ship higher-quality code faster.

For more details check out the documentation on the mirrord website along with the code repository I created to demonstrate mirrod's features.

About me

I'm Mihai Farcas, a software engineer with a few years of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Why Go is Popular Right Now and Why I Started Learning Go as a Node.js Developer

Mihai Farcas — Tue, 22 Oct 2024 07:28:06 +0000

As a Node.js developer for over a decade, I've built countless web applications, APIs, and microservices. Node.js has been my go-to language for its versatility and vast ecosystem. However, I've recently become increasingly interested in Go, particularly its performance, concurrency model, and growing popularity in the cloud-native space. This interest led me to start learning Go, and I'm thrilled to share my experiences and insights with you all.

Reasons for Go's Popularity

Go has been steadily gaining popularity among developers, and for good reason. It offers a unique blend of features that make it a compelling choice for building modern, high-performance applications.

Performance: Go's compiled nature and efficient garbage collection result in impressive execution speed, often outperforming interpreted languages like Node.js and Python.
Concurrency: Go's built-in concurrency features, through goroutines and channels, make it easier to write concurrent code, which is essential for building scalable applications.
Simplicity: Go's syntax is clean, minimal, and easy to learn, reducing cognitive overhead and promoting code readability.
Type Safety: Go's static typing helps catch errors during compilation, reducing runtime surprises and improving code reliability.
Tooling: Go's comprehensive standard library and rich ecosystem of third-party tools provide developers with the necessary resources to build and maintain robust applications.

Go's sweet spot lies in its ability to balance performance, concurrency, and simplicity. It's a language that allows you to write efficient, scalable code without sacrificing readability or ease of development.

Go's popularity has also been fueled by the rise of Kubernetes. As Kubernetes has become the de facto standard for container orchestration, Go has benefited from its close association. Kubernetes is written in Go, and many of its components and extensions are also built using Go.

Why I Started Learning Go

Beyond the technical benefits, I was drawn to Go's simplicity and elegance. Coming from the world of JavaScript with its occasional quirks and complexities, Go's minimalist syntax and clear design principles were a breath of fresh air. The language's focus on readability and maintainability aligned with my belief in writing clean, understandable code.

I've been writing code in a functional-lite style in Node.js, and Go allows me to continue with that as it has many of the traits that make this possible in JS. Go's support for first-class functions, closures, and immutability makes it well-suited for functional programming paradigms. This was a significant advantage, as I could leverage my existing functional programming skills while exploring Go's unique features. Check out my video about functional programming in JavaScript - many of the concepts apply to Go as well.

I was particularly interested in Kubernetes and the possibility of writing Kubernetes extensions and operators in Go. Kubernetes has become the de facto standard for container orchestration, and Go's close association with Kubernetes made it a natural choice for extending its functionality. The prospect of building custom Kubernetes tools and controllers in Go further fueled my interest in learning the language.

If you're interested in similar topics, check out my YouTube channel, where I share content about Kubernetes, functional programming, and many other software development topics:

youtube.com

Transitioning from Node.js to Go:

While I found several similarities between Go and Node.js, particularly in their approach to concurrency and support for functional programming paradigms, there are also some notable differences that shaped my transition experience. Initially, I felt a bit disoriented switching between the two languages, but as I gained more experience with Go, the transition became smoother.

Go's strict type system and compilation process were significant changes from Node.js with TypeScript. While TypeScript introduces static typing to JavaScript, Go's type system is more strict and enforced during compilation. This stricter approach reduces runtime errors and improves code reliability. Go's compilation process also differs from TypeScript's transpilation process. Go compiles directly to machine code, resulting in faster execution speeds compared to TypeScript, which is transpiled to JavaScript that then runs on a JavaScript engine.

A big difference was Go's minimalist approach to error handling. Unlike Node.js's reliance on exceptions, Go treats errors as values, requiring explicit handling. This approach, while initially surprising, encouraged me to write more robust and error-aware code. It also made me realize the importance of carefully considering error handling strategies in my Node.js projects. I must say that I much prefer Go’s approach to error handling!

Go's built-in support for concurrency through goroutines and channels was a significant advantage over Node.js's single-threaded model with its event loop and asynchronous callbacks. Goroutines, Go's lightweight concurrency units, allowed me to write concurrent code without the overhead of managing threads manually. They are managed by the Go runtime, and multiple goroutines can be multiplexed onto a smaller number of OS threads. This is unlike Node.js, where the developer has to make use of the event loop and manage asynchronous code and callbacks. Channels, the communication mechanism between goroutines, provided a safe and efficient way to synchronize data between concurrent processes. They can be used to pass data and also to signal that a certain task is done.

For other Node.js developers looking to learn Go, I recommend embracing the type system, understanding the concurrency model, and adopting Go’s error handling approach. There are plenty of resources available online, including tutorials, documentation, and community forums, to help you get started with Go. You can also check out my video about how I started learning Go:

Benefits of Learning Go

Learning Go has been a rewarding experience, and I encourage other Node.js developers to explore this powerful language. By taking this step, you'll be investing in your own growth and development as a software engineer. Here are some of the benefits I've gained from learning Go:

Improved performance and scalability of applications: Go's compiled nature and efficient memory management translate to faster execution speeds and reduced resource consumption. This can lead to significant improvements in application performance, especially for high-traffic web services and data-intensive applications.
Enhanced understanding of concurrency and parallelism: Go's built-in concurrency features, using goroutines and channels, provide an elegant and efficient way to handle concurrent operations. Learning Go can deepen your understanding of concurrency concepts.
Increased productivity and code maintainability: Go's simplicity, strong typing, and tooling contribute to increased developer productivity. The language's focus on readability and clarity makes it easier to write, understand, and maintain code, even in large and complex projects.
Exposure to a new programming language and its community: Learning a new language like Go exposes you to new ideas, paradigms, and approaches to problem-solving. It also opens doors to a vibrant and supportive community of Go developers, where you can learn, collaborate, and contribute.

Conclusion:

Go's popularity is a testament to its ability to address the challenges of building modern, high-performance applications. Its performance, concurrency model, simplicity, and tooling have made it a compelling choice for developers across various domains.

My journey into Go as a Node.js developer has been a rewarding experience. The transition, while initially challenging, has broadened my perspective and enhanced my skill set. I encourage other Node.js developers to consider learning Go and explore its potential for building robust and scalable applications.

About me

I'm Mihai Farcas, a software engineer with a few years of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Prompt Engineering and Other Bullshit Jobs in Tech

Mihai Farcas — Wed, 28 Aug 2024 20:31:22 +0000

In the tech industry, we love our buzzwords. "Prompt engineering" is the latest buzzword, a shiny new term for a role that shouldn’t and probably doesn’t exist. As usual, the internet and tech companies have latched onto this buzzword and are now creating entire "prompt engineering" teams.

I'm calling BS. Sure, there's a skill to getting chatbots to spit out what you want, but it's not that hard to do, nor does it deserve its own “role” in a company. It's more like knowing how to sweet-talk or clearly define what you want.

The Bullshit Job Phenomenon in Tech

Bullshit jobs are not a new phenomenon in tech. Long before "prompt engineer" became a thing, the tech world was already a breeding ground for pointless positions.

The Compliance Officer Who Clicks "Approve": In the wake of scandals and regulations, companies hired hordes of compliance officers. Many of them spent their days rubber-stamping documents, ensuring the illusion of oversight rather than actual scrutiny.

The "Innovation Strategist" Who Never Innovates: With titles like "Chief Innovation Officer" or "VP of Disruption," these folks were paid handsomely to brainstorm ideas that rarely see the light of day. Their real job? To make the company look forward-thinking.

The "Customer Experience Manager" Who Doesn't Talk to Customers: Tasked with improving the customer experience, these employees often have little contact with actual customers. Instead, they focused on internal metrics and reports, creating the illusion of progress without actually making a difference.

In David Graeber's book Bullshit Jobs, he describes the phenomenon of pointless jobs that exist only to make companies or individuals appear busy and important. Think of all those endless meetings that could've been an email. He argues that these jobs are not only useless but also soul-crushing for the people who hold them.

The rise of "prompt engineering" seems to fit Graeber's definition of a bullshit job perfectly. It's a job that exists solely because of the hype surrounding AI, not because there's any real need for it. It exists because it sounds cutting-edge and cool, not because it solves real problems.

What "Prompt Engineers" Actually Do (or Don't Do)

So, you're probably wondering, what do these so-called "prompt engineers" actually do all day? Well, the truth is, it's not as glamorous as it sounds. The reality is that much of what's touted as "prompt engineering" is just the same old stuff dressed up in fancy new tech jargon.

The fundamental skills remain the same. If you were a marketer before, you still need marketing expertise to craft effective prompts for AI. If you were a coder, you still need coding knowledge to guide the AI in generating functional code. AI is a tool, not a replacement for domain knowledge.

It boils down to crafting clear and specific instructions for AI models. Think of it like giving directions to a particularly literal-minded friend. You need to be explicit, avoid ambiguity, and anticipate potential misunderstandings. It's less about engineering and more about effective communication.

Of course, there are some nuances involved. Prompt engineers might experiment with different phrasing, iterate on instructions, and fine-tune parameters to optimize the AI's output. But let's be honest, it's not exactly rocket science. If you can write a clear email or follow a recipe, you've got the basic skills down.

You can confidently dismiss the "prompt engineer" fad. Prompting LLMs or AI is not a job; it's a skill, and a basic one at that. It certainly won't be a key differentiator in the job market.

Domain Expertise vs. Prompt Engineering: What Employers Really Want?

Let's cut through the BS. The real value in today's AI-driven world isn't in "prompt engineering" – it's in good old-fashioned domain expertise. AI is a tool, and like any tool, it's only as good as the person wielding it. You can give a monkey a paintbrush, but it won't create a masterpiece - actually never mind, that would probably sell for millions. Similarly, you can give someone with zero marketing experience the ability to prompt an AI, but they won't generate a winning campaign.

The hype around "prompt engineering" might be driven by the same factors that create bullshit jobs. It's a shiny new title that creates an illusion of specialized knowledge and importance, masking the reality that the core tasks remain unchanged. Companies might be tempted to hire "prompt engineers" to project an image of being at the forefront of AI innovation, even if the role itself adds little genuine value.

Employers ultimately care about results. They might think they need people with AI prompting skills, but what they really need is someone who can deliver. And delivering results requires experience, expertise, and intelligence. AI can assist in the process, but it can't replace the human element that drives success.

The future of work isn't about becoming a "prompt engineer." It's about becoming an expert in your field and learning how to leverage AI to enhance your skills and productivity. AI can automate mundane tasks, generate ideas, and provide insights, but it can't replace the critical thinking, creativity, and problem-solving skills that come with true expertise.

The Future of Work in the Age of AI

The future belongs to those who can adapt and evolve, not those who chase fleeting trends. Instead, invest in yourself and your skills. Focus on building your knowledge in your chosen field. The real winners in the age of AI will be those who combine their domain expertise, with their unique set of skills and experience and use AI as a tool to enhance these.

"Prompt engineering" is largely a myth. Don't be fooled by the hype. Focus on what you're good at, and let the AI tools help you where they actually can. The essence of meaningful work lies in its ability to create value, solve problems, and contribute to the world. AI can be a powerful ally in this endeavor, but it's the human element - our knowledge, creativity, and passion - that will ultimately define the future of work.

About me

I'm Mihai Farcas, a software engineer with a few years of experience under my belt. I'm passionate about writing code and love sharing knowledge with fellow developers.

My YouTube channel, "Let's Talk Dev," is where I break down complex concepts, share my experiences (both the good and the face-palm moments).

Let's Talk Dev - YouTube

youtube.com

Connect with me:

Website: https://mihai.ltd
YouTube: https://www.youtube.com/@letstalkdev
GitHub: https://github.com/mihailtd
LinkedIn: https://www.linkedin.com/in/mihai-farcas-ltd/

Simplify PostgreSQL Deployments with Kubernetes & GitOps (with Crunchy Data Operator)

Mihai Farcas — Mon, 22 Jul 2024 21:17:15 +0000

Ever felt frustrated with the complexity of running PostgreSQL on Kubernetes? Manually setting up data volumes, services, deployments, managing backups, managing secrets holding credentials, not to mention high availability... There is a lot of complexity in running stateful applications in Kubernetes. This is especially true if you're aiming to achieve this in a declarative GitOps way.

There is a way to simplify this process, to deploy PostgreSQL declaratively, and have a production-ready setup with just a few lines of declarative yaml.

That's where the Crunchy Data Postgres Operator comes in.
In this article, let's deploy PostgreSQL declaratively, creating a production-ready setup on Kubernetes.

If you'd rather watch than read:

Installing Crunchy Data Postgres Operator

To follow along, you need to have a kubernetes cluster running. On my local machine I will be using Rancher Desktop - see my video on that topic. Or you can do so in the cloud or even in your own homelab, and wouldn’t you know, I have a video on how to easily set up a kubernetes homelab as well.

Let’s get back to the task at hand. Installing PGO is not that complicated, however it presented a few challenges when I initially started out, especially since I was a beginner in Kubernetes back then. So I am aiming to simplify this process for you.

To help us out Crunchy has prepared a github repo with code examples. You can find that in the quick start guide from the documentation.

Let’s clone that repo locally and see what’s inside.

There are a couple of ways to install PGO, or actually most things in kubernetes. One is through Helm and one is through Kustomize.

I will use Kustomize, it is the closest thing to native kubernetes manifests and I believe the easiest to figure out what exactly is being installed.

You'll want to check out the folder conveniently named install. And yet again, there are a couple of ways of installing it. One is the single namespace install, where PGO will manage Postgres instances in, well, a single namespace, and the other one is a cluster-wide installation where PGO can manage postgres instances in any namespace in the cluster. The main difference is in the permissions you give PGO within your cluster.

This type of cluster-wide operator is important and we will see that later on we'll talk about the interesting topic of Platform Development.

The cluster-wide installation manifests can be found in the default folder.

Here we can check the manifest file, it references other manifests, but we can understand what it’s trying to do: install a CRD or a custom resource definition, which is how you extend the kubernetes API, it applies some role based access controls (RBAC), and some thing called “manager” which is just a deployment, a pod that will run an image with the code that makes all of this possible.

OK let’s try to apply these manifests, kubectl apply -k ./kustomize/install/default and here we get the first error. The annotation is too long. To fix it you just need server-side apply. I added the --force-conflicts flag as well but that’s optional. Here is the final command:

kubectl apply -k ./kustomize/install/default --server-side --force-conflicts

And that’s it, we now have the Crunchy Data Postgres Operator installed!

Deploying PostgreSQL using PGO

In the examples repository you can find manifests that showcase the options you have when deploying PostgreSQL. Let's take a look at /kustomize/postgres/postgres.yaml.

With PGO installed we can now create a custom resource of kind PostgresCluster.
In the manifest we can define the Postgres image and version to use, in this case version 16.
We can have multiple instances in the same manifest and each instance can be a replica set with multiple replicas.
For example here there is a single instance named instance1.
We need to allocate some storage - 1 gb should be enough.

Another required field to have a minimal postgres cluster is the backup configuration. It’s nice that they "force" you to have at least a minimal backup configuration.

In a production scenario the backups should be stored at least on a separate drive or even better, offsite or in the cloud.

There are a bunch of options you can configure here, and after we apply the manifest, PGO will take care of backups automatically.

As you can see there are a few pods that started, you can see one pod for that postgres instance. There is also a backup job that ran immediately and now it’s stopped. It also created some kubernetes services so you can connect to this postgres instance.

Speaking of connecting to postgres, one of the best things about this operator is that it manages credentials in kubernetes secrets automatically!

You should see a secret for each user configured for the database. Let’s check one of these secrets out to see what’s in there: a few properties, basically everything you need to successfully connect to the database!

No need to manually configure secrets, this is all done for us!

Actually let me show you how easy it is to just create a user and a new database.
There is a users key in the manifest, and we can give it a name, we can specify the databases this new user has access to. The nice thing is that if the database doesn’t exist PGO will create it. Let’s call it testdb. And we can give this new user SUPERUSER access:

  users:
    - name: test
      databases:
        - testdb
      options: SUPERUSER

Now it’s as simple as applying this new manifest and there we go, a new secret has been created for this new user with all the credentials.
More importantly behind the scene, all the required operations were done for us, creating the database, creating the user and so on. And the beauty of it all is that it’s all declarative!

Deploying PGAdmin

I’d really love to test all of this in a visual way, if only there was a UI interface to see what’s going on in a Postgres database. Oh wait, PGO can also manage a PGAdmin installation for us! Let’s check out the manifest for that: ./kustomize/pgadmin/pgadmin.yaml

As you can see the other custom resource that this operator installed is of kind PGAdmin.
Let’s just apply this example manifest. We can see a pod PGAdmin was created, let’s port forward and open it in a browser.

Credentials for the PGAdmin web interface are also stored in a kubernetes secret automatically.

High Availability

Scaling a PostgreSQL instance with PGO is as easy as flipping an integer:

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo-ha
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-16.3-1
  postgresVersion: 16
  instances:
    - name: pgha1
      replicas: 2

Just change the number of replicas to whatever you need, and PGO will take care of it. See ./kustomize/high-availability/ha-postgres.yaml for a more complete example that also includes pgbouncer.

What is a Kubernetes Operator?

Kubernetes is great at managing stateless applications, it has everything you need out of the box. But stateful applications like PostgreSQL, which store persistent data and require special care and procedures to run, that’s a bit more tricky. This is where Kubernetes Operators come in. They are software extensions that enhance Kubernetes' capabilities, specifically designed to automate the management of complex, stateful applications like PostgreSQL databases.

Like we saw earlier, operators extend the kubernetes API with new types of resources, in this case we had the PostgresCluster and the PGAdmin resource types.

The operators usually also run a container in the background and can handle certain administrative tasks for you, for example they can scale Postgres instances, automate backup and restores, disaster recovery etc.

And most importantly they can do so in a declarative way!

Platform Development

This leads me to the other topic I wanted to cover in the video and that is Platform Development.

This is a concept where you have a platform team that manages a Kubernetes cluster that has all of these operators installed.

This platform then enables self-provisioning and managing of resources without complex scripting, manual actions - it’s all done through declarative configuration!

This is especially important for a few use cases, such as:

Spinning up new environments like staging or test environments
Accelerating development cycles and productivity
Faster iteration on new ideas
Implementing GitOps principles ensuring consistency, repeatability and auditability.

So there you have it! The Crunchy Data Postgres Operator takes the complexity out of running PostgreSQL on Kubernetes. Head over to their GitHub page and give it a try. I'd love to hear about your experiences in the comments below!

Don't forget to subscribe to my youtube channel for more content like this!

Let's Talk Dev - YouTube

youtube.com

DEV Community: Mihai Farcas

Do You Need Rancher Desktop (or Docker Desktop) on Linux? My CachyOS Setup

1. The Peculiar Architecture of Docker Desktop on Linux

2. Where Rancher Desktop on Linux Makes Technical Sense

1. Disposable, Multi-Version Kubernetes Sandboxes

2. Fleet Parity Across Mixed-OS Engineering Teams

3. Isolated Sandboxing for Untrusted Containers

4. The Headless 2.0 Architecture

3. My Daily Driver Container Setup on CachyOS

Step 1: Installing Native Docker Engine on Arch / CachyOS

Step 2: Filesystem Integration with Btrfs

Step 3: Installing Native K3s and Running at Startup

Step 4: Real-World Resource Consumption: Why Idle K3s Stays On

Step 5: Bringing Down and Bringing Back Up K3s Without Losing Volumes

Where Data Actually Lives

Safe Shutdown Procedure

Bringing the Cluster Back Up

Step 6: Terminal-First Observability with lazydocker

4. Comparing the Architectural Options on Linux

5. Which Path Should You Choose?

Related Guides & Architectural Reviews

About the author

n8n + Argo = ❤️: Offloading CPU-Heavy Steps to Argo Workflows

What does the lab run?

What breaks when a Code node does heavy work?

Can you tune your way out?

How does the offload work?

How does n8n authenticate to Argo?

What did offloading change?

What does offloading cost?

When should a step leave n8n?

Key takeaways

About the author

Mount Local Storage to Kubernetes Pods: An Easy Tutorial Using K3s and the Local Path Provisioner

The Ephemeral Container Problem

The Kubernetes Storage Hierarchy

1. PersistentVolume (PV)

2. PersistentVolumeClaim (PVC)

3. StorageClass

The Homelab Storage Dilemma: Distributed SAN vs. Local Path

How the Local Path Provisioner Works Under the Hood

The Lifecycle Flow

Why WaitForFirstConsumer Is Non-Negotiable

Distribution Support: Does Your Cluster Include It?

Installing Local Path Provisioner on Any Cluster

Hands-On Walkthrough: Deploying a Stateful Pod

Step 1: Create a PersistentVolumeClaim

Step 2: Deploy the Stateful Pod

Step 3: Verify Persistence Across Restarts

Step 4: Verify Host Directory Cleanup

Operational Caveats & Architectural Boundaries

Key Takeaways

About the author

I Hired Claude, But Slower and More Expensive

What the interview measured

Debating a proxy

Why do I need you?

Trust, once it's gone

Why you can't just fix it quickly

What changed

The $3/Month Enterprise-Ready Automation Stack: Zero-Trust n8n With One Command (n8n, Cloudflare, UpCloud, Pulumi)

The Problem With Self-Hosted Automation

What You Get

Why Zero-Trust Matters Here

The 6-Pillar Stack

How It Wires Together

1. Pulumi Creates the Cloudflare Tunnel

2. The Tunnel Token Gets Fetched via API

3. DNS Points to the Tunnel

4. Cloud-Init Bootstraps the Server

5. Three Containers, One Compose File

The Setup (5 Minutes)

Prerequisites

Deploy

Tear Down

What About Persistence?

What About n8n Cloud?

The Full Lifecycle

Automate Your Homelab Like a Pro with Ansible!

Why Ansible for Your Homelab (and Beyond)?

Step 6: Terminal-First Observability with `lazydocker`

Why `WaitForFirstConsumer` Is Non-Negotiable