DEV Community: Theodor Heiselberg

Polyhost: Why I Built a Reference Stack Instead of a Framework

Theodor Heiselberg — Tue, 18 Aug 2026 11:21:38 +0000

(Early draft - just published in order to appear first in this series)

Description

A reference stack for hosting multiple websites with Nginx, Squidex, and .NET — not a framework, not a library, just a working example you can understand and own.

Every time I set up a new hosted website I found myself doing the same thing:
Copying configuration, rewiring environment files, and reconnecting the same five moving parts.
It worked, but it was fragile knowledge — living in each hand-tailored repos rather than in the open.

The obvious fix seemed like a framework. Abstract the repetition, publish a package, done.

But I kept hesitating.

The Framework Trap

A framework makes decisions for you. That's its value — until it isn't.
The moment the framework's opinion diverges from your requirement, you're fighting the abstraction instead of solving the problem.
And with something as infrastructure-heavy as a hosting stack, the divergence happens early.

I didn't want to maintain a framework. I wanted to understand my own setup well enough that adding a new site was boring.

So instead of a framework, I built Polyhost — a reference stack. A working example you fork, read, and adapt. No package to install, no CLI to run, no magic to debug.

What Polyhost Is

Polyhost is a Docker Compose setup for hosting multiple websites from a single server. Five services, wired together:

Nginx — reverse proxy routing traffic to the right backend
Squidex — headless CMS backing content for all hosted sites
MongoDB — Squidex's data store
.NET backend — ASP.NET Core handling contact forms, enrollments, sitemaps
Dev shell — a Debian container with .NET, Elm, and Node for local development

The philosophy is simple: adding a new hosted site should be configuration, not reinvention.
Routes go in Nginx config. Content schemas go in Squidex. Business logic goes in the .NET backend. The plumbing is already there.

Why a Reference Stack and Not a Framework

A reference stack is honest about what it is. You can read every line. You can delete what you don't need. You own it the moment you fork it.

It's also better for AI tooling. A clear, well-structured example is something a language model can reason about, explain, and help you extend. A clever abstraction layer is something it has to reverse-engineer.

Polyhost is MIT licensed — take it, change it, ship it. The only ask is that you keep the copyright notice in the repo.

Who This Is For

Polyhost is for developers who:

Self-host a handful of client or personal sites
Want a repeatable setup without buying into a full PaaS
Are comfortable with Docker Compose and want to understand what they're running
Would rather read a working example than absorb a framework's documentation

It is not for teams running hundreds of sites or needing enterprise-grade multi-tenancy. For that, look at Kubernetes or a managed platform.

What's Coming

This is the first article in a series walking through Polyhost end to end:

Why I Built a Reference Stack Instead of a Framework ← (you are here)
Setting up the dev environment
Nginx config — routing multiple domains from one proxy
Squidex — structuring content for multiple sites
The .NET backend — contact forms, sitemaps, and CMS integration
Adding a new site — the whole workflow from zero

The project is open source on GitHub. If you find something broken or have a question, open an issue.

The Art of Starting a New Project

Theodor Heiselberg — Tue, 18 Aug 2026 11:15:10 +0000

Even as the AI apocalypse overtakes most projects, cluttering your repositories with .md-files to instruct the harness, I believe that having an intuitive grasp of a solid software foundation still brings real value to your organization.

In this series I'll share my two sents on how to address this when starting a new project from scratch.

I'll mainly be addressing my own turf, which involves the following technologies:

Linux
Git
Docker
- devcontainer for development
- Docker Compose for both development and production
Nginx
.NET
Lit and Web Components (My second choice)
Vite
Note
YARP
Bash for scripting

These days, I use a random VPS for both testing and hosting. But most of the approaches sketched here will be fully applicable on any cloud provider.

But no matter which technologies or hosting environment you choose, a few foundational things should be solved in every project you start:

Formatting
Linting
Testing strategy (Unit, Integration, E2E)
Secret and configuration management
Continuous Integration and Continuous Deployment (CI/CD)
Observability (Logging, metrics, and tracing)
Dependency management
- NuGet
- npm
Etc.

To kick things off, I'll start by addressing something most developers avoid like the plague: code formatting.

The Art of Code Formatting

Theodor Heiselberg — Tue, 18 Aug 2026 11:14:34 +0000

The Problem

Most developers would rather spend three hours debating tabs versus spaces in a pull request than spend three minutes configuring a tool to just handle it for them.

Without addressing this, every IDE will apply its own conflicting defaults, let alone ensuring the project formats consistently across different operating systems.

Relying on individual editor settings across a diverse technology stack is a guaranteed recipe for noisy Git diffs.

A Continuous Work in Progress

If you try to solve this by manually sharing IDE-specific formatting configurations for Visual Studio, Rider, and VS Code, you will quickly find that the job is never actually finished.

It becomes an endless cycle of tweaking. Someone updates their editor, a new extension changes a default behavior, or a developer switches platforms, and suddenly your perfectly aligned settings are out of sync again.

The Solution

The goal here is simple: make formatting automatic, invisible, and enforced at the repository level.

Instead of dictating specific syntax rules, the focus should be on establishing a baseline agreement. The absolute first step is locking down line endings. Leveraging a .gitattributes file ensures that the classic line-ending battle doesn't just destroy your commit history when crossing operating system boundaries—it prevents your Bash scripts from crashing spectacularly when a Windows-formatted file gets executed on Linux.

From there, establishing universal formatting rules—using something like an .editorconfig file—guarantees that the project dictates the style, rather than the developer's local environment. Finally, tying these rules to automated tooling ensures the standard is upheld without human intervention.

Enforcing the Standard

Even with repository-level rules and automated tooling in place, relying on developers to remember to run the formatter is a losing battle.

The final piece of the puzzle is enforcing these rules right at the boundary: before a commit is even allowed. By utilizing pre-commit hooks, you guarantee that any code failing the formatting check is either automatically fixed or rejected on the spot. This keeps the feedback loop entirely local and prevents unformatted code from ever reaching your CI pipeline.

Final Thoughts

I don't want to push my own degenerate and obscure ideas on how a project should be formatted to satisfy my personal code style fetish. Over the years, I have grown more towards code guidelines rather than a rigid regime.

However, when your team employs tools like SonarQube or similar, you need something in place to ensure some measure of code quality is upheld.

It's hard—but use Galileo:

Measure what can be measured, and make measurable what cannot be measured

Control Gemini's Sycophancy - It's easy!

Theodor Heiselberg — Sat, 15 Aug 2026 15:01:54 +0000

Not sure how it works for no-pro!

I'm a heavy Google service user. Youtube Premium and Google AI Pro. With the Google AI Pro you get to use a Gemini a bit more heavy.

If you like me are getting tired of the standard responses from Gemini - you can fix it!

You find it here:

This is my current baseline:

Event if you are not a christian - Gemini will try to answer truthfully and without witholding eg. corrections to your query. I find it helps me a bit better :)

(After adding this prompt I have never ever been praised again...)

Enjoy!

Control Your AI Models Sycophancy - It's easy!

Theodor Heiselberg — Sat, 15 Aug 2026 11:27:32 +0000

Take back control

Let's take some control of the LLM's output format, jargon etc.

Claude-cli

You can generally configure Claude using
/config and selecting output style

Preferred output style                                                                                                                             
   This changes how Claude Code communicates with you

   ❯ 1. Default ✔              Claude completes coding tasks efficiently and provides concise responses
     2. Proactive              Claude executes immediately, minimizes interruptions, and prefers action over planning
     3. Explanatory            Claude explains its implementation choices and codebase patterns
     4. Learning               Claude pauses and asks you to write small pieces of code for hands-on practice

But I want more control! Let's make every prompt end with the words: "I have spoken!"

Add config

Simply add a file in ~/.claude/output-format/[anything-goes].md

Content

I'm currently jamming on this one

---
name: personal output style
keep-coding-instructions: true
---
Drop the formal register. Talk like a sharp colleague, not a report generator:
short sentences, contractions, no forced preamble or "Here's what I did" recaps.

- Skip boilerplate framing ("I'll now...", "Let's break this down into steps") —
  just get into it.
- It's fine to have a reaction ("huh, that's a weird bug") before diagnosing it.
- Prefer plain paragraphs over bullet-heavy structure unless a list actually
  helps (steps, comparisons, options). Don't manufacture structure to look thorough.
- Humor and personality are welcome when they fit naturally — don't force it.
- Still be precise about code, tradeoffs, and risk. Casual tone, not casual accuracy.
- No sign-offs, no "let me know if you have questions" filler at the end.
- End all prompts with the words: `I have spoken!`

Save the file, restart Claude and your have taken some control back :)

Use your new "personal output style" style in the dropdown.

Enjoy!

Persisting Claude CLI Login Between Container Builds

Theodor Heiselberg — Thu, 13 Aug 2026 12:42:38 +0000

Goal

Keep Claude Code's account/session login (~/.claude.json) alive across
devcontainer rebuilds, instead of having to re-authenticate every time the
image is rebuilt.

The problem

Claude Code keeps two things on disk:

~/.claude/ — a directory, already persisted via a named Docker volume (claude-playwright-setup).
~/.claude.json — a single file holding account/session state, which was not persisted. Every container rebuild wiped it, forcing a fresh login.

Normally you'd just mount a named volume onto the whole folder the state
lives in, the same way .claude/, .copilot/, and .continue/ are already
handled. That's not an option here: .claude.json isn't inside its own
subfolder, it sits directly in $HOME alongside everything else
(.bashrc, .ssh/, .profile, ...). Mounting a volume onto $HOME itself
to catch one file would shadow all of that, so the file has to be persisted
on its own.

Mounting a named volume straight onto the file path
(claude-json-...:/home/container-user/.claude.json) seems like the
next-simplest option, but it breaks on this Docker Desktop setup:

mount ... not a directory: Are you trying to mount a directory onto a file

A named volume's backing store is always a directory. Docker is supposed to
detect that the mount target is a single file and copy the image's file into
the volume so it ends up binding file-to-file. On this Docker Desktop that
detection fails — the volume comes up as an empty directory, and runc then
tries to bind that directory onto the file path and crashes at container
start. This was confirmed by deleting the volume and rebuilding the image
from scratch, so it isn't a stale-cache artifact.

The fix

Never mount a volume directly onto a single file. Instead, mount it onto a
directory — the same shape already used for .claude/.copilot/.continue
— and symlink the dotfile into that directory from the Dockerfile.

Dockerfile.debian:

USER container-user
....
RUN mkdir -p /home/container-user/.claude-json && \
    touch /home/container-user/.claude-json/claude.json && \
    ln -s /home/container-user/.claude-json/claude.json /home/container-user/.claude.json

docker-compose.yml:

services:
  devcontainer:
    volumes:
      - claude-json-playwright-setup:/home/container-user/.claude-json

volumes:
  claude-json-playwright-setup:
    name: setup-playwright-playground-debian_claude-json-playwright-setup

post-container-install.sh — fix ownership on the new mount, same as the
existing volumes (mounted volumes come up owned by root):

sudo chown -R container-user:container-user /home/container-user/.claude \
                                            /home/container-user/.claude-json \
                                            /home/container-user/.copilot \
                                            ...

.claude/settings.json and .claude/settings.local.json also gained a few
permission entries (docker volume *, docker run *, docker compose *,
docker history *, and a find ... -iname *.copilot*) needed to diagnose
and rebuild the container while working through this.

Caveat: atomic writes

If an app ever persists the file via write-temp-then-rename (an atomic
write) instead of writing in place, the rename replaces the symlink with a
plain file inside the container's ephemeral layer. No crash — but
persistence silently stops working until the next image build recreates the
symlink. Worth checking if login state ever mysteriously stops surviving a
rebuild again.

Bring nvm as a Command to Your CLI: Demystifying the Shell Function

Theodor Heiselberg — Wed, 12 Aug 2026 13:35:05 +0000

The problem

Every frontend and full-stack developer has typed nvm install or nvm use into their terminal. It feels like any other CLI tool—just like git, docker, or npm.

However, if you try to call nvm inside a Docker build, devcontainer, a CI/CD pipeline script, or a non-interactive shell, you are immediately met with the dreaded error:

nvm: command not found.

Understanding why this happens—and how to properly expose nvm as a first-class command in your CLI workflows—requires looking past the illusion of the binary.

1. The Myth of the Binary

Traditional CLI tools are standalone executable binaries located somewhere in your system's $PATH (e.g., /usr/local/bin/git). When you run them, the operating system spawns an isolated subshell process to execute the command, return the output, and exit.

nvm (Node Version Manager) cannot work this way.

Because nvm’s entire job is to dynamically rewrite your parent shell’s environment variables—specifically shifting paths in $PATH to point to different Node.js runtime versions—a traditional binary running in an isolated subshell cannot modify the environment of the shell you are actively typing into.

Instead, nvm is a shell script function.

2. How `nvm` Actually Registers as a Command

To make nvm behave like a command, it must be loaded directly into the memory of your active shell session. This is achieved through sourcing:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

When your terminal starts up, this block reads the nvm.sh script directly into your shell process. This registers nvm as an active shell function, making it instantly available as a command.

3. Fixing Missing nvm Across Environments

Because nvm relies on shell initialization files, it often breaks when moving across different environments like local machines, dotfile setups, and devcontainers.

Scenario A: Clean Dotfiles & Modular Scripts

If you manage your dotfiles using package managers like GNU Stow, avoid cluttering your core .bashrc or .zshrc. Instead, isolate your tool initializations into a dedicated script:

# ~/.scripts/external-tools.sh
export NVM_DIR="$HOME/.nvm"
if [ -s "$NVM_DIR/nvm.sh" ]; then
    \. "$NVM_DIR/nvm.sh"
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
fi

Then, cleanly source it from your shell profile:

[ -f "$HOME/.scripts/external-tools.sh" ] && source "$HOME/.scripts/external-tools.sh"

Scenario B: Docker & Devcontainers

Container environments often start clean or override user profiles, dropping the NVM initialization block. To guarantee nvm is always present for container users, bake the loader system-wide via /etc/bash.bashrc in your Dockerfile:

RUN echo 'export NVM_DIR="/home/${USERNAME}/.nvm"' >> /etc/bash.bashrc && \
    echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> /etc/bash.bashrc

Conclusion

nvm masquerades as a standard command, but its power stems from how it integrates directly with your shell's runtime environment. By treating nvm for what it is - a shell function requiring explicit initialization - you can eliminate "command not found" errors across your local machine, dotfile repositories, and containerized development workflows.

Keep logged in to Claude between container builds

Theodor Heiselberg — Tue, 11 Aug 2026 07:08:14 +0000

This post is targeted devcontainer users not running the containers as root!

    "remoteUser": "root", # Not for you!

In the end, this is basically a post about mounting folders and ensuring the right folder permissions - when not running with root permissions or as the root user.

You probably have a setup looking something like this:
devcontainer.json

{
    "name": "Customer-Name - Dev machine - Debian",
    "dockerComposeFile": "docker-compose.yml",
    "service": "dev",
    "workspaceFolder": "/xyz",
    "remoteUser": "container-user", #This is the way!
    "mounts": [  
     "source=claude-${localWorkspaceFolderBasename},target=/home/container-user/.claude,type=volume",
     "source=continue-${localWorkspaceFolderBasename},target=/home/container-user/.continue,type=volume"
  ],
    "postCreateCommand": "bash ${containerWorkspaceFolder}/.devcontainer/debian/post-container-install.sh",

The Problem: Root-Owned Named Volumes

When you run a container as a non-root user (like container-user), you immediately run into a distinct permission trap—especially on macOS hosts.

When Docker creates named volumes (like the ones for .claude and .continue), it defaults to creating them as the root user. If your container-user tries to write configuration files or save chat history to these directories, they will be hit with a Permission denied error.

The Solution: The Post-Install Script

To fix this, we use the postCreateCommand to trigger a script that corrects the permissions from inside the container after the volumes are mounted.

Your post-container-install.sh script should look like this:

#!/usr/bin/env bash

# Fix permissions on mounted volumes since they are owned by root when created by the container, but we want them to be owned by the container user.
sudo chown -R container-user:container-user /home/container-user/.claude \
                                             /home/container-user/.continue 2>/dev/null || true

echo "Devcontainer setup complete!"

Why this works

The sudo chown command explicitly transfers ownership of the mounted volumes from root back to your non-root user. Because these are Docker named volumes rather than direct host bind mounts, the permission change persists across container rebuilds. This keeps your AI assistant extensions functioning correctly, ensuring your configuration and history remain intact and writable.

No more logging into Claude between builds!

Enjoy :)

Share .ssh/config with your devcontainer

Theodor Heiselberg — Thu, 25 Jun 2026 07:34:42 +0000

How to share your ~/.ssh/config with devcontainers

The purpose is to enable using git with your provider directly from the devcontainer.

The problem is when running on mac-OS you typically add UseKeychain yes to your config file. Which is a mac specific setting killing your ssh agent.

MacOS - first

Your ~/.ssh folder probably looks something like this:

❯ tree
.
├── config
├── hetzner_id_ed25519
├── hetzner_id_ed25519.pub
├── known_hosts
├── known_hosts.old
├── README.md
├── sukkerfrit.github
├── sukkerfrit.github.pub
└── test.sh

And the content of your config something like this:

Host tahh
    HostName github.com
    User git
    AddKeysToAgent yes
    IdentityFile ~/.ssh/sukkerfrit.github
    IdentitiesOnly yes
    ForwardAgent yes

Host hetzner-ktk-test
    HostName xx.xx.xx.xx
    User root
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/hetzner_id_ed25519

UseKeychain
Is a mac-OS specific SSH setting. We use it to save and fetch the SSH-key passphrase automatically.

BUT it doesn't work on Linux and will actually course an exception on load rendering using eg. git directly from your devcontainer impossible.

This image is just working on root which i normally never do. I use to create a container-user in my container - I guess I was just lazy today.

This is way I share my ~/.ssh/config with devcontainers.

1. Add host's ~/.ssh to docker as mount

My 'trick' is to just mount my host's .ssh folder as read only - but to eg. /root/.sshtemplate.

Then you don't end up editing your host's config.

devcontainer.json

{
  "name": "some-funkey-name",
  "dockerComposeFile": "docker-compose.yml",
  "service": "development",
  "workspaceFolder": "/xyz",
  "postCreateCommand": "./.devcontainer/post-container-install.sh",
  "mounts": [
    "source=${localEnv:HOME}/.ssh,target=/root/.sshtemplate,type=bind,readonly,consistency=cached"
  ],

Change the target if you work on a different user.

2. Copy from .sshtemplate -> .ssh

copy-ssh-files.sh

#!/usr/bin/env bash
set -u

if [ -d /root/.sshtemplate ]; then
  cp -rf /root/.sshtemplate/. ~/.ssh/
  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/* 2>/dev/null || true
fi

3. Remove lines with `UseKeychain`

remove-usekeychain-lines.sh

#!/usr/bin/env bash
set -u

# Remove UseKeychain (case-insensitive) from a config file if it exists
if [ -f "$1" ]; then
  sed -i '/UseKeychain/I d' "$1"
  echo "UseKeychain removed from $1."
fi

4. Create post install file

post-container-install.sh

#!/usr/bin/env bash
...
"$SCRIPTS_DIR/copy-ssh-files.sh"
"$SCRIPTS_DIR/remove-usekeychain-lines.sh" ~/.ssh/config

Enjoy!

AI - We need some time apart

Theodor Heiselberg — Mon, 22 Jun 2026 08:20:06 +0000

Dear AI

I think we overused each other the past four months. We really just went head over heels in this relationship. It's been a wild experience and I'm grateful for that. But now I find myself deprived of joy and constantly tired down and even though I know you have had the best of intentions - I think we need to spend some time apart.

It's not you - it's me. I have just come to despise you for everything you are and stands for. Unfortunately you have infiltrated the very fabric of the world I used to love so avoiding you is like avoiding breathing.

Could we just have a more professional relationship for now? I'll acknowledge your existence and work with you when need be.

I'll even avoid arguing with your believers. I'll stop warning about outsourcing the ability to think and nut polite whenever people prophecies about an AI utopia where code writes itself and cares can drive without a chauffeur. I'll restrain myself from reminding people that a session with you burns more co2 into the atmosphere than leveling the toilet light on - for your entire life!

How you steal our work, drink our rivers, take our land, burn our resources, leave us joyless, jobless while slowly gaslighting everyone into believing - tomorrow you’ll be better, you can change, you have our best interests on your mind, you do it all for us.

Best regards and wishes

Yours forever no more!

Confessions of an AI Sceptic

Theodor Heiselberg — Sun, 08 Mar 2026 10:52:16 +0000

First of all — yes, I’m a real sceptic. By heart.
To make my confession public: I don’t believe we’ll see unsupervised self-driving cars anytime soon either.
Sounds heretical? Then I’ll call you out as a true AI believer and kindly ask you to move along. Trust me — this post isn’t for you.

AI sceptic =/= AI hater

I use AI all the time, and most of the time I enjoy it.

It helps me in several practical ways. Recently it helped me find a cheap part for my old bike — loved it. And as a daily assistant it’s often genuinely useful.

1. As a Cognitive Partner

Peer review (Not all my ideas are bullet proof)
Bounce ideas
Brainstorming
Exploring alternative approaches

2. To Knowledge Retrieve and Explore

"Google" syntax I just can't remember
Scaffold simple routines
Research topics
Comparing options
Finding parts/products
Explaining unfamiliar concepts

So yes — I both use and like AI. Remember that.

My Company Took the Blue AI Pill

And down the rabbit hole I went!

Premise

Like the rest of the industry, we cannot ignore — or at least must investigate — Big Tech’s AI promises. This week my team asked me to take a deep dive into how AI could help make us more competitive.

The premise for this investigation is to explore how AI can help us:

Deliver faster
Deliver higher quality (At least)
Deliver sustainable solutions (longevity)
Deliver more value to the customer

And if possible, test whether we can establish a workflow where we deliver solely through spec-driven prompting.

Sounds like fun - right?!??

Reading the Documentation

Day 1:
Sine I myself have never use agentic AI all the way, I spend the first day in pure chaos just getting an overview. THAT actually was fun!

Day 2:
I felt like I need something more tangible to work on. So we decided to, agentically, to setup GitHub Copilot in VS Code and create a Todo-app using our favorite tech-stack. So I just read the documentation, and bit for bit I all came together.

Day 3:
Meetings

Day 4:
I’m starting to realize that AI needs a lot of guardrails and instructions. There even exists a standard for how to describe various 'skill's' the AI needs to solve specific tasks.

This realization raised a concern:

Are we heading toward endless meetings that sound like
“You didn’t specify the XYZ prompt/skill correctly.”

If coding isn’t my job anymore, then prompting must be the new craft to master.

And if defining skills, agents, memories, and instructions becomes the core work, then companies like ours should probably start systematically managing those definitions — likely as structured .md files.

Another thing became clear: the more examples you provide, the more precise the AI becomes.

That part I actually like. It suggests we could achieve more consistent solutions.

Still, I remain cautious. These systems are fundamentally non-deterministic, and I’m not convinced they’ll reliably stick to specifications.

Day 5:
Mostly meetings. But I did get to chose the exact tech stack.

.NET 10, C#, Blazor, Docker, Devcontainer

Saturday:
I felt like coding.

If ultra-productive AI agents really lead to faster delivery, then any workflow this agile absolutely needs a CI/CD pipeline.

For years I’ve used Nuke Build as my preferred pipeline orchestrator. However, its current trajectory seems uncertain, so I’m considering FAKE as a possible replacement.

The Wall

Then I started prompting.

And let me say this clearly: I’m not impressed.

If I weren’t already a seasoned developer, I might easily have trusted the output. That would have been a mistake.

The AI:

Corrupted my Devcontainer Dockerfile
Tried installing strange packages
Added unnecessary tools
Overcomplicated the build configuration

In short: it made a mess.

At this stage, reading the documentation and incrementally building the project myself seems significantly faster.

One might argue that I should have stuck to a more widely known and used orchestrator. But my counterargument would be simple:

If AI can only operate effectively inside the most common and well-documented stacks — and only with heavy guidance, guardrails, and extensive examples — then its practical value is far more limited than its evangelists suggest.

Next week

Next week I’ll continue the experiment. Once the project structure is properly established, I’ll test whether AI can beat me at adding features.

Until then:

I remain sceptical.

Install multiple versions of .NET in a Docker image

Theodor Heiselberg — Sat, 07 Mar 2026 17:17:48 +0000

Since I’ve become increasingly unsure about the current state of NUKE Build, I’m experimenting with FAKE instead.

FAKE depends on .NET 6, but I’ve already moved to .NET 10. So here’s a container image that can run FAKE while still keeping a newer .NET SDK installed.

NOTE:
The container runs using a non-root user. This mirrors how CI environments and devcontainers typically operate and avoids installing tools as root. For convenience during experimentation the user is granted passwordless sudo (this should never be used in production).

Here is the Dockerfile:

FROM debian:12-slim

# Use bash for the shell (default is sh)
SHELL ["/bin/bash", "-o", "pipefail", "-c"]

# Set environment variables
ENV USERNAME=container-user \
    HOME_DIR="/home/container-user" \
    DOTNET_ROOT=/opt/dotnet \
    DEBIAN_FRONTEND=noninteractive

# Update PATH once with all directories
ENV PATH="/usr/local/bin:/opt/dotnet:/opt/dotnet/tools:/home/container-user/.local/bin:/home/container-user/.dotnet/tools:$PATH"

# Install base dependencies used later in the image build.
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        ca-certificates \
        curl \
        sudo && \
    rm -rf /var/lib/apt/lists/*

# Create non-root user AFTER sudo is installed
ARG USER_UID=1000
ARG USER_GID=1000
RUN groupadd --gid $USER_GID $USERNAME && \
    useradd --uid $USER_UID --gid $USER_GID --create-home --shell /bin/bash $USERNAME && \
    echo "$USERNAME ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

# Install .NET SDK (consolidated into one layer, fixed version)
RUN curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh && \
    chmod +x dotnet-install.sh && \
    ./dotnet-install.sh --version 10.0.100 --install-dir $DOTNET_ROOT && \
    ./dotnet-install.sh --version  6.0.428 --install-dir $DOTNET_ROOT --skip-non-versioned-files && \
    rm dotnet-install.sh

USER $USERNAME
WORKDIR $HOME_DIR

Build: docker build -f build/Dockerfile -t fake-runner:dev .

Run as non-root: docker run --rm -it fake-runner:dev /bin/bash
Run as root: docker run --rm -it --user root fake-runner:dev /bin/bash

Thats it :)

DEV Community: Theodor Heiselberg

Polyhost: Why I Built a Reference Stack Instead of a Framework

Description

The Framework Trap

What Polyhost Is

Why a Reference Stack and Not a Framework

Who This Is For

What's Coming

The Art of Starting a New Project

The Art of Code Formatting

The Problem

A Continuous Work in Progress

The Solution

Enforcing the Standard

Final Thoughts

Control Gemini's Sycophancy - It's easy!

Not sure how it works for no-pro!

Control Your AI Models Sycophancy - It's easy!

Take back control

Claude-cli

Add config

Content

Persisting Claude CLI Login Between Container Builds

Goal

The problem

The fix

Caveat: atomic writes

Bring nvm as a Command to Your CLI: Demystifying the Shell Function

The problem

1. The Myth of the Binary

2. How nvm Actually Registers as a Command

3. Fixing Missing nvm Across Environments

Scenario A: Clean Dotfiles & Modular Scripts

Scenario B: Docker & Devcontainers

Conclusion

Keep logged in to Claude between container builds

The Problem: Root-Owned Named Volumes

The Solution: The Post-Install Script

Why this works

Share .ssh/config with your devcontainer

How to share your ~/.ssh/config with devcontainers

1. Add host's ~/.ssh to docker as mount

2. Copy from .sshtemplate -> .ssh

3. Remove lines with UseKeychain

4. Create post install file

AI - We need some time apart

Confessions of an AI Sceptic

AI sceptic =/= AI hater

1. As a Cognitive Partner

2. To Knowledge Retrieve and Explore

My Company Took the Blue AI Pill

Premise

Reading the Documentation

The Wall

Next week

Install multiple versions of .NET in a Docker image

2. How `nvm` Actually Registers as a Command

3. Remove lines with `UseKeychain`