DEV Community: Theodor Heiselberg

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

AI, Cognitive Debt, and Ownership

Theodor Heiselberg — Wed, 04 Mar 2026 07:43:56 +0000

This post is inspired by the reflections shared in this talk:
The Dark Side of AI Code Generation

Lately at work we are, like the rest of the world, embracing AI and incorporating it into our daily lives and workflows.

But uncritical usage of AI has a dark side!

The dark side

When Using AI, You Risk Building Knowledge Gaps
AI-Generated Code Can Train You to Accept Complexity You Don’t Understand

AI increases output. That is not the same as increasing understanding.

If we repeatedly merge code we did not fully reason about, we accumulate something more dangerous than technical debt:

We accumulate cognitive debt.

What Is Cognitive Debt?

Cognitive Debt is the interest you pay in time and stress when you have to re-learn your own system through code you never truly understood.

It compounds.

You pay the interest when:

Debugging production incidents
Refactoring fragile areas
Onboarding new developers
Explaining design decisions you cannot fully justify

AI is not the problem.

Unowned complexity is.

Shared Theory: The Real Asset

Every healthy engineering team shares a theory of the system:

How it works
Why decisions were made
Where the boundaries are
What must never break

This shared understanding is what allows teams to move fast safely.

If AI accelerates code production without strengthening shared theory, you are trading short-term speed for long-term fragility.

AI-PR Review Framework

AI should be used to increase shared understanding — not reduce it.

If you do not understand the code, you do not own it.

1. Review Like a Junior Developer

Read the PR as if you are new to the codebase.

Ask yourself:

Can I explain every single line to a colleague?
Do I understand why this approach was chosen?
Could I rewrite this without using AI?

If the answer to any of these is no, you are not done reviewing.

Read deeper.

Refactor it.

Simplify it.

The standard is this:

“I feel confident debugging this in production at 3 AM.”

If that sentence feels false, the code is not ready.

2. The PR Owner Must Document Decisions

The person who prompted or introduced AI-generated code must update a decision record (Confluence, ADR, etc.) with:

What the code solves
Why this design was chosen
Known edge cases
Trade-offs considered

This forces reasoning before merging.

3. Rotate Ownership of Critical Areas

Make sure everyone on the team can describe the system’s most critical components:

Create a list of critical areas
Rotate code walkthrough responsibility
Require reviewers to update the decision record during review

Examples of critical areas:

Authentication
Payments
Application pipeline (Program.cs, Startup.cs, middleware flow)
Infrastructure boundaries

If only one person understands a critical system, you are already in debt.

Guardrails for AI Usage

Practical constraints reduce risk:

Keep AI-assisted PRs small
Require tests before merge
Prefer AI for scaffolding and refactoring, not architectural decisions
Enforce clear architectural boundaries
Reject complexity you cannot explain

AI should increase clarity.

If it increases opacity, something is wrong.

The Debugging Confidence Standard

Speed without comprehension is fragile.

Before merging AI-generated code, ask:

Would I confidently debug this without asking AI to explain it back to me?

If the answer is no, the cost has only been postponed.

And postponed cost compounds.

Conclusion

AI is a powerful amplifier.

It can amplify:

Understanding
Discipline
Shared ownership

Or it can amplify:

Complexity
Fragility
Dependency

The difference is not in the tool.

It is in whether we refuse to merge what we do not understand.

How to Disable Github Copilot Autocomplete in vs code

Theodor Heiselberg — Thu, 05 Feb 2026 12:39:48 +0000

Why?

I actually like AI. I use it—like, all the time. But being a seasoned programmer, I have grown increasingly frustrated with the invasive suggestions popping up all over the second I start typing in my favorite IDE.

This is not a rant—BUT. Why, why, why isn't there just a button to turn off this noise?

Add this to your settings.json to silence Copilot's "help":

{
    "github.copilot.enable": {
        "*": false,
        "plaintext": false,
        "markdown": false
    }
}

(4)Creating the Pinnacle of Niche Software: Abandoning localhost:1234 - locally!

Theodor Heiselberg — Mon, 29 Dec 2025 16:34:33 +0000

About

The concrete implementation was made on MacOS, but it should be quite easy to alter and adopt this example to both Windows and Linux.

Exclusively tested with Vite 6+!

In this article we will implement the ideas presented here - Production Parity: Routing Local Traffic with a Reverse Proxy

The main idea is to achieve parity between our development setup and production.

You might think: 'Why would this be necessary?' - The argumentation for achieving environment parity is covered here: the-red-pill-of-software-delivery-unmasking-magic-code-and-building-for-reality

This article is a continuation of creating-the-pinnacle-of-niche-software-using-vite-plugin-elm-watch and the example created there will be extended in the branch named feature/use-custom-domain - Link!

Goals

Use a custom domain name and completely ditch the usage of localhost:port when working on our solution from the browser
Develop from a devcontainer
Enable HTTPS

Now let's go through how we achieve this fine objective :)

The moving parts

Next up we will setup the following:

Add nginx to the solution
Configure our hosts file
Configure nginx
Create and trust certificates

Reverse Proxy

First of all we need to add a reverse proxy like nginx to handle routing from a url/domain to the vite server. This won't break HRL and will bring all the benefits discussed earlier. I'll use nginx throughout this article.

If you are following along from the previous article, it should be quite straight forward to extend the the code in the following. A working example can be found here: Link! in the branch use-custom-domanin

Add nginx
First we'll add nginx to the docker-compose.yml

name: elm-first

services:
  dev: ..

  nginx:
    image: nginx:alpine
    container_name: elm-first-nginx
    ports:
      - "80:80"
      - "443:443"
    networks:
      - internal
    # volumes:
      # - ./nginx.conf:/etc/nginx/nginx.conf:ro
      # - ./ssl:/etc/nginx/certs:ro
    depends_on:
      - dev
volumes:
  elm-first-vite-example:

networks:
  internal:
    driver: bridge

Add endpoint to your hosts file

On mac it's simply done by:
> sudo vi /etc/hosts and add

127.0.0.1       happy.now www.happy.now
127.0.0.1       happy.dev

Save the file an restart the devcontainer.
I had some troubles with when the mappings in the hosts file were picked up by the browsers.

But now we can access the default nginx site by simply using: happy.now

Observe that using happy.dev will redirect to https://happy.dev

Next we'll route to our vite server running on port 3456

Serve the running vite sever

Add a custom nginx.conf touch .d evcontainer/nginx.conf

events {
    worker_connections 1024;
}

http {

    # Define resolver to handle host.docker.internal
    resolver 127.0.0.11;

    server {
        listen 80;
        server_name www.happy.dev happy.dev www.happy.now happy.now;
        # Proxy frontend requests to Elm dev server
        location / {
            set $frontend_upstream host.docker.internal:3456;
            proxy_pass http://$frontend_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            sub_filter '</head>' '<meta name="environment-name" content="local" /></head>';
            sub_filter_once on;
            # Only apply sub_filter to index.html
            # sub_filter_types text/html;
        }
    }

Uncomment in the docker-compose.yml

 volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

From the host machine! run: docker exec elm-first-nginx nginx -t
It the config is ok now run: docker exec elm-first-nginx nginx -s reload
Start the vite server by running: npm run dev
The vite server will bounce access from anything but localhost so update the allowedHosts whith:

allowedHosts: ["host.docker.internal", "www.happy.now", "happy.now", "www.happy.dev", "happy.dev"],

Reload the page and be a happy developer now!

Finally we will enable HTTPS.

Enable HTTPS

First we'll need to rearrage the project a bit. Start with stopping the devcontainer.

Rearrage nginx config

Add the missing nginx folder and add files.

project-root/
├── .devcontainer/
│   ├── ssl/
│   ├── devcontainer.json
│   ├── docker-compose.yml
│   ├── Dockerfile.devmachine
│       └── nginx/
|           ├── nginx.conf
|           └── conf.d/
|               └── proxy_elm_env.inc <-- NEW

The new configs should look like this:
nginx.conf

events {
    worker_connections 1024;
}

http {

    # Define resolver to handle host.docker.internal
    resolver 127.0.0.11;

    server {
        listen 80;
        server_name www.happy.dev happy.dev www.happy.now happy.now;
        # Proxy frontend requests to Elm dev server
        location / {
            include /etc/nginx/conf.d/proxy_elm_env.inc;
        }
    }

    server {
        listen 443 ssl;
        server_name www.happy.dev happy.dev;

        ssl_certificate     /etc/nginx/certs/happy.dev.crt;
        ssl_certificate_key /etc/nginx/certs/happy.dev.key;

        location / {
            include /etc/nginx/conf.d/proxy_elm_env.inc;
        }
    }
}

proxy_elm_env.inc

proxy_pass http://$frontend_upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
sub_filter '</head>' '<meta name="environment-name" content="local" /></head>';

Certificates

We need a certificate in order to use HTTPS. Here we'll create a self signed cert.

Let's use happy as our domain name.

Since we will be using squidex in the next article we create a cert which can handle both happy.dev and squidex.happy.dev.

Notes on TLD's
It's important to notice that some TLD's are special.
dev, app, and page will all have HTTPS enforced by the browser if used. Unlike test, localhost or local which, at least on MacOS, will be treated as safe

Method 1 (Not so good)

Using this method will require a cert for each domain name.
Eg. one for both happy.dev and squidex.happy.dev

cd /workspace/.devcontainer/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout happy.dev.key -out happy.dev.crt \
  -subj "/CN=happy.dev" \
  -addext "subjectAltName=DNS:happy.dev,DNS:*.happy.dev"

# Set proper permissions
chmod 644 squidex.happy.dev.crt
chmod 600 squidex.happy.dev.key

Repeat for the happy.dev domain. But I prefer to just use method 3.

Method 2 (Better)

Using this method will make you only need one certificate.

Create a req.cnf file in eg. the .devcontainer/ssh folder.

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = DK
ST = Central Denmark Region
L = Tilst
O = Kompromisløs
OU = IT
CN = happy.dev

[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = happy.dev
DNS.2 = squidex.happy.dev

Generate Private key: openssl genrsa -out happy.dev.key 2048
Generate Self-Signed Certificate: openssl req -x509 -new -key happy.dev.key -sha256 -days 365 -out happy.dev.crt -config req.cnf -extensions v3_req

chmod 644 happy.dev.crt
chmod 600 happy.dev.key

Trust the Certificate in macOS Keychain

To make browsers on your Mac trust your self-signed certificate, you need to add the certificate to your macOS system keychain and then explicitly set its trust level.

Most web browsers on macOS, including Chrome, Safari, and Firefox (by default), rely on the certificates stored in the system's Keychain Access utility.

Here is the step-by-step guide to get your browser to trust the happy.dev certificate:

Step 1: Open Keychain Access
Open Spotlight Search by pressing Cmd + Space.

Type Keychain Access and press Enter.

Step 2: Import the Certificate
In the Keychain Access application, make sure you have the login or System keychain selected on the left sidebar.

Go to the menu bar and select File > Import Items....

Navigate to the location of your happy.dev.crt file, select it, and click Open.

You may be prompted to enter your administrator password to add the certificate to the keychain.

Step 3: Set the Trust Level
In Keychain Access, find your imported certificate. It should be listed under its common name, which is likely happy.dev or a similar identifier.

Double-click the certificate to open its details window.

Expand the Trust section.

You will see a dropdown menu labeled "When using this certificate:". By default, it will say "Use System Defaults."

Change this dropdown to "Always Trust."

Close the window. You will be prompted to enter your administrator password again to save the changes.

Step 4: Restart Your Browser
After you've set the trust level, it's a good practice to completely quit and restart your web browser (e.g., Safari, Chrome, or Firefox). This ensures that the browser reloads the certificate trust settings from the system keychain.

Now, when you navigate to https://happy.dev, your browser should recognize the certificate as valid, and you will no longer see the "Your connection is not private" or security warning pages.

Update your hostfile

sudo vi /etc/hosts

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
....
127.0.0.1       happy.dev www.happy.dev        <-- ADD

Use a script to add cert

All the above steps can be automated using this script:

#!/bin/bash

# Example
# bash> setup-certs.sh happy.dev 365

# Default values
CERT_NAME="${1:-localhost}"
DAYS="${2:-365}"
CERT_DIR="${3:-.}"

# Generate private key
openssl genrsa -out "$CERT_DIR/$CERT_NAME.key" 2048

# Generate self-signed certificate
openssl req -x509 -new -key "$CERT_DIR/$CERT_NAME.key" -sha256 -days $DAYS \
  -out "$CERT_DIR/$CERT_NAME.crt" -config req.cnf -extensions v3_req

# Set proper permissions
chmod 644 "$CERT_DIR/$CERT_NAME.crt"
chmod 600 "$CERT_DIR/$CERT_NAME.key"

# Add certificate to macOS Keychain (macOS only)
if [[ "$OSTYPE" == "darwin"* ]]; then
  echo "Adding certificate to macOS Keychain..."
  sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain "$CERT_DIR/$CERT_NAME.crt"

  # Add domains to /etc/hosts
  echo "Adding domains to /etc/hosts..."
  HOSTS_ENTRY="127.0.0.1 $CERT_NAME squidex.$CERT_NAME"
  if ! grep -q "$CERT_NAME" /etc/hosts; then
    echo "$HOSTS_ENTRY" | sudo tee -a /etc/hosts > /dev/null
    echo "Added: $HOSTS_ENTRY"
  else
    echo "$CERT_NAME already in /etc/hosts"
  fi
fi

echo "✅ Certificate created!"
echo "Certificate: $CERT_DIR/$CERT_NAME.crt"
echo "Key: $CERT_DIR/$CERT_NAME.key"

If the file doesn't have execute rights:
bash setup-certs.sh happy.dev 365

I ran it from .devcontainer/ssh/

Notes for Linux users

host.docker.internal doesn't work out of the box like it does on macOS. You need to add this to the docker-compose.yml under the nginx service:

extra_hosts:
  - "host.docker.internal:host-gateway"

Conclusion

We now have a professional-grade development setup that eliminates the need for localhost entirely. By routing traffic through a reverse proxy with valid SSL handling, we have achieved production parity on our local machines.

Is this more effort than simply running a dev server on a random port? Yes. But the trade-off is significant:

Zero "Magic" Code: You no longer need if (development) { ... } blocks to handle URLs or protocol differences.

Security First: You catch CORS, HSTS, and SSL issues during development rather than at 2 AM during a production deployment.

Skill Mastery: You've moved beyond being a "local-only" developer to understanding the networking layers that power modern web applications.

Production Parity: Routing Local Traffic with a Reverse Proxy

Theodor Heiselberg — Mon, 29 Dec 2025 16:33:53 +0000

When building modern web applications, it’s common to have a frontend (like a Single Page Application) and a backend API running on different ports. This setup introduces friction—especially when it comes to routing and security during local development.

The Problem: Port Mismatch

Most frontend code expects to call the backend API at a specific route, such as /api/endpoint. However, locally, your backend might run on localhost:5130 while the frontend is served on localhost:9876. This mismatch leads to:

CORS Issues: Browsers block requests between different ports for security.
Environment-Specific Code: Needing logic to switch between local and production URLs.
Onboarding Complexity: New developers must manage multiple addresses and configurations.

The Solution: A Reverse Proxy

A reverse proxy like Nginx acts as a single entry point. By listening on a unified port (e.g., localhost:8314), it streamlines the workflow:

Uniform Routing: The frontend calls /api/... regardless of the environment
Transparent Forwarding: Nginx intercepts /api/ requests and forwards them to the backend servic
Local Parity: Your development environment architecture closely mirrors production

Configuration: The Hosts File

To use a custom domain (like myapp.test), you must update your local hosts file. This tells your OS to route traffic for that domain to your local machine.

On macOS: Edit /etc/hosts using >sudo nano /etc/hosts.

In Devcontainers: Ensure your Linux-based (Debian/Alpine) containers can resolve the host.

Add a line such as: 127.0.0.1 myapp.test

A Note on TLDs
Choosing the right Top-Level Domain matters:

.test / .localhost: Recommended. These are reserved for local use and testing.

.local: Can cause delays on macOS due to mDNS (Bonjour) conflicts.

.dev / .foo: These are on the HSTS Preload List, meaning browsers will force HTTPS. If you use these, you must configure SSL certificates in your proxy.

Benefits

Consistency: Frontend code remains identical across all environments
Simplicity: No more CORS headaches or complex URL configurations
Automation: Tools like site-config-loader work easily with Nginx to handle configurations for the frontend

A complete example on how I use this setup myself can be seen here: Link!

(3)Creating the Pinnacle of Niche Software: Using vite-plugin-elm-watch

Theodor Heiselberg — Mon, 22 Dec 2025 21:43:16 +0000

About

The problem we are trying to solve here is the usual.

Create a stable development environment
Enable Hot reloading
Simplify the development process and prepare for production

In this article we will go through how to use:

vite-plugin-elm-watch
site-config-loader
Add tailwind css to the project

Key takaways
A working example of this setup running in a devcontaner can be found here - Link! in the branch feature/add-tailwind

host: '0.0.0.0' or host: true is needed in order to run vite from a devcontainer - Documentation - Link!

import tailwindcss from '@tailwindcss/vite';
import { defineConfig } from 'vite';
import elm from 'vite-plugin-elm-watch';
import devMetaTagPlugin from './vite-plugin-dev-meta.mjs';

export default defineConfig(({ command }) => ({
  publicDir: 'public',

  build: {
    outDir: 'wwwroot',
    emptyOutDir: true,
  },

  plugins: [elm(), tailwindcss(), devMetaTagPlugin(command)],

  server: {
    open: true,
    port: 3456,
    host: '0.0.0.0', // Listen on all network interfaces to allow access from the host machine
    allowedHosts: ['host.docker.internal', 'localhost'],
  },
}));

First let's setup vite to handle building Elm

Here is the steps when starting from scratch

elm init
touch src/Main.elm
npm init
npm install vite-plugin-elm-watch --save-dev OR -D
npm install site-config-loader
touch index.html
! Emmet Abbreviation (To fill index.html)
touch src/main.js
Add to index.html

<body>
    <div id="app"></div>
    <script type="module" src="/src/main.js"></script>
</body>

Add to src/index.js

import Main from './Main.elm';
let app = Main.init({
  node: document.getElementById('app')
})

touch vite.config.mjs

import { defineConfig } from "vite";
import elm from 'vite-plugin-elm-watch';

export default defineConfig(({ command }) => ({
  publicDir: "public",

  build: {
    outDir: "wwwroot",
    emptyOutDir: true,
  },

  plugins: [elm()],

  server: {
    open: true,
    port: 3456,
    host: "0.0.0.0", // Listen on all network interfaces to allow access from the host machine
    allowedHosts: ["host.docker.internal", "localhost"],
  },
}));

npm install vite -D
npx vite

Environment Management with site-config-loader

Managing environment variables in a frontend application can be tricky. site-config-loader simplifies this by fetching configuration files based on the environment your site is running in.

To determine the environment, the loader looks for a tag. During development, we can use a custom Vite plugin to inject this tag dynamically.

1. Create Configuration Files

First, we need to store our environment-specific data. We’ll create a default config and a local override.

Bash

mkdir -p public/config
touch public/config/environmentVariables.json

public/config/environmentVariables.local.json
Add your variables to these files. For example:

public/config/environmentVariables.json

{
    "API_URL": "https://api.production.com",
    "FEATURE_FLAG": false
}

2. Inject the Environment Meta Tag

Since we want to control which configuration the loader picks up during development, we use Vite’s transformIndexHtml hook. By default, site-config-loader might fall back to local based on the URL, but using a meta tag gives us explicit control.

Create a small plugin file: vite-plugin-dev-meta.mjs

export default function devMetaTagPlugin(command) {
  // Only apply this transformation during local development ('serve')
  if (command !== 'serve') return null;

  return {
    name: 'html-transform-dev-only',
    transformIndexHtml(html) {
      return html.replace(
        '</head>',
        '<meta name="environment-name" content="local"></head>'
      );
    }
  };
}

3. Register the Plugin in Vite

Now, integrate the plugin into your vite.config.mjs to ensure the tag is injected when you run the dev server.

import { defineConfig } from 'vite';
import elm from 'vite-plugin-elm-watch';
import devMetaTagPlugin from './vite-plugin-dev-meta.mjs';

export default defineConfig(({ command }) => ({
  // ... other config
  plugins: [
    elm(),
    devMetaTagPlugin(command)
  ]
}));

4. Verify the Setup

Run your development server:

npm run dev
Open the browser console. You should see site-config-loader successfully detecting the environment and loading the merged configuration from your JSON files.

Adding tailwind

npm install -D @tailwindcss/cli @tailwindcss/vite tailwindcss
touch src/site.css
Add content to site.css

@import "tailwindcss";

body {
  @apply bg-pink-50 text-red-900 font-sans;
}

Add usage of tailwind to vite.config.mjs

import tailwindcss from '@tailwindcss/vite';
...
  plugins: [
    elm(),
    devMetaTagPlugin(command),
    tailwindcss()
  ],

Add the css to main.js

import './site.css';

Restart the vite server

Using Environment Variables in Elm

Since site-config-loader fetches your configuration asynchronously, we need to wait for the data to be ready before initializing the Elm application. We then pass the configuration into Elm using Flags.

Update src/main.js Modify your entry point to load the config first, then start Elm:

import '@fortawesome/fontawesome-free/css/all.min.css';
import { loadEnvironmentVariables } from 'site-config-loader';
import './kort-til-kort.css';
import Main from '/src/Main.elm';

const config = await loadEnvironmentVariables('clientsettings');

let app = Main.init({
  node: document.getElementById('app'),
  flags: {
    isDevelopment: config.isDevelopment,
    turnstileSiteKey: config.turnstile.sitekey,
    googleConfig: {
      mapsApiKey: config.googleConfigurations.mapsApiKey,
      mapId: config.googleConfigurations.mapId,
    },
    pixelId: config.facebookPixelId,
  },
});

Conclusion

There are quit a few moving parts need to get this up and going.

A Complete example can be found here: Link! in the branch feature/add-tailwind

Next up we will abandon using localhost entirely and use a custom domain name for development. This will also require adding quite a few moving parts, like a reverse proxy to our .devcontainer/docker-compose.yml.

I wrote about it previously here: Link!

(2)Creating the Pinnacle of Niche Software: The devcontainer

Theodor Heiselberg — Mon, 22 Dec 2025 21:31:43 +0000

The Elm development environment

I prefer as ultra stable, shareable and reproducible an environment as possible so my preferred approach is using a devcontainer.

Until recently I saw the .devcontainer as a intrinsically part of my project only containing the one true development container setup. Devs could use dotfiles to bring custom configs and setup that way.

However my perspective has changed recently and now I just add a folder with my own name to the .devcontainer folder and leave it up to each dev how they prefer to roll.

Here I'll share my current favorite setup when developing for Elm in the previously described tech stack. And it dose involve quite a few moving parts - so hold on!

Building the base container

The project for the base contaner - tailored for my needs - can be found here: elm-development-environment-builder
Don't get fooled by the name - it's tailored for my needs only - but do get inspired. :)

The devcontainer setup

Folder structure

I'm considering adding theodor to .gitignore but I'm undecided right now.

project-root/
├── .devcontainer/
│   ├── vanilla/                 # Basic example
│   └── theodor/                 # Personal environment config
│       ├── ssl/
│       │   ├── squidex.crt
│       │   └── squidex.key
│       ├── devcontainer.json
│       ├── docker-compose.yml
│       ├── Dockerfile
│       ├── Dockerfile.omnia
│       └── nginx.conf
├── backend/
├── backup/
├── build/
├── Documentation/
├── dotnet/
└── elm/

Comments

This setup fairly advanced!

Using custom domain locally - not localhost:port!
Using nginx - production like
Setting environment variables using nginx and site-config-loader!

devcontainer.json

{
  "name": "Dotnet 9/10 and Elm Dev Container (Debian + Compose)",
  // --- Use Docker Compose configuration ---
  // Point to your docker-compose file (relative to .devcontainer folder)
  "dockerComposeFile": "docker-compose.yml",
  // The name of the service defined in docker-compose.yml that VS Code should attach to
  "service": "dev",
  // The path inside the container where your project files are mounted by docker-compose.yml
  "workspaceFolder": "/workspace",
  "mounts": [
    "source=ktk-elm-devcontainer,target=/home/container-user/.elm,type=volume"
  ],
  "customizations": {
    "vscode": {
      "settings": {
        // Set bash as the default terminal (installed in Dockerfile)
        "terminal.integrated.defaultProfile.linux": "zsh"
        // Optional Neovim integration path:
        // "vscode-neovim.neovimExecutablePaths.linux": "/usr/bin/nvim"
      },
      "extensions": [
        "ms-vscode-remote.remote-containers",
        "Elmtooling.elm-ls-vscode",
        "ms-dotnettools.csharp",
        "william-voyek.vscode-nginx",
        "vscodevim.vim",
        "ms-dotnettools.csdevkit",
        "EditorConfig.EditorConfig",
        "humao.rest-client",
        "esbenp.prettier-vscode",
        "DotJoshJohnson.xml",
        "streetsidesoftware.code-spell-checker",
        "streetsidesoftware.code-spell-checker-danish",
        "bradlc.vscode-tailwindcss",
        "kamikillerto.vscode-colorize",
        "Ionide.Ionide-fsharp",
        "ms-azuretools.vscode-containers",
        "jebbs.plantuml",
        "task.vscode-task",
        "ecmel.vscode-html-css"
      ]
    }
  },
  // The user VS Code should run as inside the service container.
  // Should match the user the service runs as (container-user in this case).
  "remoteUser": "container-user",
  "portsAttributes": {
    "3033": {
      "label": "Elm"
    },
    "5130": {
      "label": "Backend"
    },
    "5140": {
      "label": "Gateway"
    },
    "8314": {
      "label": "Nginx"
    },
    "8376": {
      "label": "Squidex"
    },
    "9876": {
      "label": "Elm"
    }
  }
}

docker-compose.yml

services:
  # Define our main development service, let's call it 'dev'
  dev:
    # Instructions on how to build the image for this service
    build:
      # Use the current directory (.devcontainer) as the build context
      context: .
      # Specify the Dockerfile within the build context
      dockerfile: Dockerfile

    # Define volumes to mount
    volumes:
      # Mount the entire project directory (one level up from .devcontainer)
      # into the /workspace directory inside the container.
      # 'cached' optimizes mount performance on macOS/Windows.
      - ../..:/workspace:cached
      - ktk-elm-devcontainer:/home/container-user/.elm
      # --- Alternative for Neovim config ---
      # Instead of COPY in Dockerfile, you could mount it here:
      # Ensure the source path '../.nvim' exists in your project root.
      # - ../.nvim:/root/.config/nvim:cached
         # --- ADD THIS LINE ---
      # Mount the project's nvim config into the root user's config dir
      # Source: ./.config/nvim (relative to this docker-compose.yml file)
      # Target: /root/.config/nvim (where nvim looks when run as root)
      # - ./.config/nvim:/root/.config/nvim:cached
    # Command to run when the container starts.
    # 'sleep infinity' keeps the container running indefinitely so VS Code can attach.
    command: sleep infinity
    networks:
      - internal

    # Environment variables can be defined here if needed
    # environment:
    #   - DATABASE_URL=...

    # The service will run as 'root' because that's the last USER in the Dockerfile.
    # You could explicitly set 'user: root' here if desired.
  nginx:
    image: nginx:alpine
    container_name: ktk_nginx
    ports:
     - "80:80"
     - "443:443"
     - "8314:80"
    networks:
      - internal
    volumes:
      # - ../..:/workspace
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/nginx/ssl:ro
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      - dev
      - squidex
  mongo:
    image: "mongo:6"
    volumes:
      - ktk_mongo_data:/data/db
    networks:
      - internal
    restart: unless-stopped
  squidex:
    image: "squidex/squidex:7"
    ports:
      - "8376:5000"
    environment:
      - URLS__BASEURL=https://squidex.ktk.dk
      - IDENTITY__ALLOWHTTPSCHEME=false
      - EVENTSTORE__MONGODB__CONFIGURATION=mongodb://mongo
      - STORE__MONGODB__CONFIGURATION=mongodb://mongo
      - IDENTITY__ADMINEMAIL=sukkerfrit@gmail.com
      - IDENTITY__ADMINPASSWORD=0hSoS3cret!
      - ASPNETCORE_URLS=http://+:5000
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/healthz"]
      start_period: 60s
    depends_on:
      - mongo
    volumes:
      - ktk_squidex_assets:/app/Assets
    networks:
      - internal
    restart: unless-stopped

volumes:
  ktk-elm-devcontainer:
  ktk_squidex_assets:
  ktk_mongo_data:

networks:
  internal:
    driver: bridge

Dockerfile

FROM isuperman/elm-devcontainer-foundation:0.1.7
# Project specifics could be added here

Here is the config for running extremely production like!
I'm even using a custom domain for local development.
This setup make it possible to test routing, a tarpit and the likes.
nginx.conf

worker_processes 1;
events {
    worker_connections 1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # Define resolver to handle host.docker.internal
    resolver 127.0.0.11;

    server {
        listen 80;
        server_name localhost ktk.dk;

        location /api/ {
            set $backend_upstream host.docker.internal:5130;
            rewrite ^/api/(.*)$ /$1 break;
            proxy_pass http://$backend_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;

        }

        location /cms/ {
          set $backend_upstream host.docker.internal:5140;
          rewrite ^/cms/(.*)$ /$1 break;
          proxy_pass http://$backend_upstream;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection 'upgrade';
          proxy_set_header Host $host;
          proxy_cache_bypass $http_upgrade;
        }
        # Proxy frontend requests to Elm dev server
        location / {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            sub_filter '</head>' '<meta name="environment-name" content="local" /></head>';
            sub_filter_once on;
            # Only apply sub_filter to index.html
            # sub_filter_types text/html;
        }

        location = /robots.txt {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream/robots.txt;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
        }

        location = /humans.txt {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream/humans.txt;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
        }
    }
    server {
        listen 80;
        server_name squidex.ktk.dk;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name squidex.ktk.dk www.squidex.ktk.dk;

        ssl_certificate /etc/nginx/ssl/squidex.crt;
        ssl_certificate_key /etc/nginx/ssl/squidex.key;
        ssl_protocols TLSv1.2 TLSv1.3;

        location / {
            proxy_pass http://squidex:5000;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host $host;

            # WebSocket support
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';

            # Authentication flows
            proxy_cookie_path / /;
        }
    }
}

Conclusion

Here we see an example of how one could use a devcontainer to set up a development environment. Using this approach has definitely helped me a lot. This is very production-like, and by using most of these settings for a local docker-compose.yml, I am extremely confident when pushing my containers to production. To emphasize, I rarely have bugs in production due to this setup.

Next up we will focus on how to setup vite-plugin-elm-watch which will require some tingling in order to run inside a devcontainer.

Creating the Pinnacle of Niche Software: Consume Squidex Headless CMS Api's in ELM!

Theodor Heiselberg — Sun, 19 Oct 2025 12:11:28 +0000

There is a first time for everything, I guess

When choosing an extreme niche programming language like Elm, you are bound to do more work since many libraries simply don't exist for Elm - yet.

But the past years using Elm, I have learned more about how the web actually works than I learned the previous 20 years—and this is why.

In the early days I started on the job market, I programmed using C# and Windows Forms. I wasn't involved in web development the first decade or so. When many others were using Ruby on Rails, I was building corporate WPF applications. And for a time, this was fine. But I longed for working with what at least I considered to be the future, so I acquired a role as a web developer.

Back then, React was new, and Knockout.js was still a thing. Coming from WPF, I actually liked it.

Throughout my career I have worked with different frontend frameworks:

Razor Pages
Knockout.js
React.js
Angular.js
Vanilla HTML + CSS

A common experience has been that handling state is a pain and most of the hard stuff of programming for the web was hidden in the various frameworks.

So I got a lot of stuff done, but never really got to learn the depths of the decisions the framework creators had made.

Enter Elm!

Over the years, I have tried to use functional programming in a few projects. It was actually when I tried to learn Bolero I was first introduced to Elm.

In order to use Bolero's Elmish, I thought I needed to learn Elm. So I learned Elm, and I haven't looked back!

Now I finally got to understand the way of the web!

When writing Elm, you need to understand how the browser works and why various decisions were made for you by other FE frameworks. It sounds harder, right? But I felt relieved. When writing Elm apps, most decisions are right there in the code. Easy to both use and extend.

I do think I write more code when using Elm, but in the end, the app seems much more clear and easy to return to. Sometimes my apps run for years, and when I sometimes need to update something, it just feels much easier as opposed to other FE frameworks I use.

This leads me to the present: Creating the pinnacle of niche software!

The tech stack of niche software

This is actually not meant as a recommendation nor a deterrent from following this recipe, merely an observation—though I'm still using this stack today.

Elm for the frontend
JavaScript—Actually, not everything for the frontend can be written in Elm—so enter JavaScript
Squidex—Every real-life FE needs a CMS. Enter Squidex
.NET—Custom backend
Nginx
YARP
Docker

Conclusion

Though I think this entire project could have been solved by simply using WordPress, I know this project will grow. Therefore, I need a flexible foundation able to scale and easy to extend.

In the coming articles, I'll go through the entire setup. And believe me - it won't look like anything you have ever seen before.

Using DooD in a devcontainer like a true pro!

Theodor Heiselberg — Sat, 23 Aug 2025 07:04:07 +0000

Yes - It is possible to use DooD in a devcontainer

When setting up a real-world devcontainer, you often need more than just a simple “hello world” example. In practice, most development environments rely on several running containers at once — databases, caches, and supporting services. For that, it’s often easier to use Docker-out-of-Docker (DooD) so your devcontainer can talk to the host’s Docker daemon directly.

In this post, we’ll set up a devcontainer environment that uses:
• A custom Dockerfile for building the development container.
• docker-compose to orchestrate the environment.
• DooD via the mounted Docker socket, allowing us to run other containers from inside the devcontainer.

This gives you a solid foundation for building a “real-life” dev environment instead of the typical examples that don’t scale.

The file system

.devcontainer
   ├── devcontainer.json   # Main devcontainer config
   ├── docker-compose.yml  # Orchestration file
   ├── Dockerfile.debian   # Custom base image for the devcontainer
   └── .env                # Environment variables

devcontainer.json

Here we enable the docker-outside-of-docker feature and configure environment variables:

{
    "name": "Testcontainers Debian dev-environment",
    "dockerComposeFile": "docker-compose.yml",
    "service": "dev",
    "workspaceFolder": "/workspace",
    "remoteUser": "root",
    "features": {"ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}},
    "containerEnv": {
        "TZ": "Europe/Copenhagen",
        "TESTCONTAINERS_HOST_OVERRIDE": "host.docker.internal"
    }
}

docker-compose.yml

The compose file mounts the workspace and the host’s Docker socket:

services:
  dev:
    build:
      context: .
      dockerfile: Dockerfile.debian
    volumes:
      - ..:/workspace:cached
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - internal
    command: ["sleep", "infinity"]

networks:
  internal:
    driver: bridge

Dockerfile.debian

We start from a slim .NET SDK base and install the necessary tooling (and some..):

# Use a base Debian image
FROM mcr.microsoft.com/dotnet/sdk:8.0-bookworm-slim

# Set noninteractive mode to avoid prompts during package installation
ENV DEBIAN_FRONTEND=noninteractive

# Create docker group and add root to it
RUN groupadd -r docker && usermod -aG docker root

# Install dependencies
# Added ca-certificates as it's often needed for https downloads and the dotnet install script might rely on it
RUN apt-get update && \
    apt-get install -y \
        git \
        dos2unix \
        docker.io \ <-- MINIMUM
        stow \
        zsh \
        tree \
        clang \
        jq \
        unzip \
        xclip \
        wget \
        curl \
        ca-certificates \
        apt-transport-https \
        software-properties-common && \
        rm -rf /var/lib/apt/lists/*

RUN dotnet tool install Nuke.GlobalTool --global
ENV PATH="$PATH:~/.dotnet/tools"


# Install .NET Runtime using the official script.
# This script handles architecture detection for you.
RUN curl -L https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh && \
    chmod +x /tmp/dotnet-install.sh && \
    /tmp/dotnet-install.sh --version 9.0.4 --runtime dotnet && \
    rm /tmp/dotnet-install.sh

Now run the container and test that you have access to your host's docer environment:

That's it!

You now have a development environment capable using DooD and eg. running devcontainers like a true pro!

Next steps

Add your own services to the docker-compose.yml and extend the Docker.debian with your own installs :)

Don’t use Alpine as a dev machine when running a devcontainer - trust me bro!

Theodor Heiselberg — Sat, 09 Aug 2025 14:52:17 +0000

Lesson learned the hard way: Don't waste time getting this up an running in an Alpine container.
At least I encountered these errors:
Absolutely no output from csharp-lsp and since alpine uses musl libc which weren't compatible with glibc I gave up on using Alpine as a development machine.

But using Debian (mcr.microsoft.com/dotnet/sdk:8.0-bookworm-slim) got me to the finish line.

Getting started with Squidex - the big picture

Theodor Heiselberg — Fri, 01 Aug 2025 17:54:34 +0000

The Big Picture: The Philosophy Behind Our Setup

Disclaimer: Only tested on Mac Silicon
If you're ready to integrate a headless CMS into your project, you're in the right place. We're going to build a solid foundation for local development, and we'll do it by keeping our environment as close to production as possible.

My projects consistently use NGINX—even for local development. For my reasoning, you can read more here:

Nginx for Local Development: Really?

The Red Pill of Software Delivery: Unmasking Magic Code and Building for Reality

The gist of it is this: I'll be showcasing how to set up a development environment for a Single Page Application (SPA) and a backend running in a devcontainer, using Squidex as our headless CMS.

To keep this environment close to a real-world scenario, we'll be using local domain names. This means we'll have one domain for our main frontend (the SPA) and another for the Squidex administration app, which is also a SPA.

This approach gives us a reliable, consistent, and realistic development setup that will make our transition to production much smoother.

The Development Environment

As you can see overview we will be routing all of our development server endpoints though Nginx.

Let's start building our devcontainer environment!

The devcontainer

Since this post is all about how to get started using Squidex I won't be covering much about how to setup a devcontainer.

.devcontainer/devcontainer.json

{
  "name": "Dotnet 9 and Elm Dev Container (Alpine + Compose)",
  "dockerComposeFile": "docker-compose.yml",
  "service": "dev",
  "workspaceFolder": "/workspace",
  "mounts": [
    "source=my-app-elm-devcontainer,target=/home/container-user/.elm,type=volume"
  ],
  "customizations": {
    "vscode": {
      "settings": {
        "terminal.integrated.defaultProfile.linux": "zsh"
      },
      "extensions": [
        "ms-vscode-remote.remote-containers",
        "Elmtooling.elm-ls-vscode",
        "ms-dotnettools.csharp",
        "william-voyek.vscode-nginx",
        "vscodevim.vim",
        "ms-dotnettools.csdevkit",
        "EditorConfig.EditorConfig",
        "humao.rest-client",
        "esbenp.prettier-vscode",
        "DotJoshJohnson.xml",
        "streetsidesoftware.code-spell-checker",
        "streetsidesoftware.code-spell-checker-danish",
        "bradlc.vscode-tailwindcss",
        "kamikillerto.vscode-colorize",
        "Ionide.Ionide-fsharp",
        "ms-azuretools.vscode-containers",
        "jebbs.plantuml"
      ]
    }
  },
  "remoteUser": "container-user"
}

Dockerfile.omnia

# Use a stable version of Alpine as the base image
FROM alpine:3.21.0

# Set up the working directory
WORKDIR /workspace

# Set environment variables
ENV HOME_DIR="/home/container-user"
# ENV LV_BRANCH="release-1.4/neovim-0.9"
ENV PATH="$PATH:$HOME_DIR/.local/bin"

# Install dependencies
RUN apk update && \
    apk add --no-cache \
    python3 \
    py3-pip \
    gcc \
    musl-dev \
    python3-dev \
    libffi-dev \
    openssl-dev \
    cargo \
    make \
    yarn \
    git \
    openssh \
    neovim \
    neovim-doc \
    xclip \
    ripgrep \
    alpine-sdk \
    dotnet9-sdk \
    bash \
    zsh \
    tree \
    stow \
    unzip \
    nushell \
    tmux \
    grep \
    jq \
    curl \
    nodejs \
    npm \
    sudo \
    libc6-compat  # Install if needed for compatibility with Elm binaries

# Configuring Elm version
ARG ELM_VERSION=latest-0.19.1
ARG ELM_TEST_VERSION=latest-0.19.1
ARG ELM_FORMAT_VERSION=latest-0.19.1

# This Dockerfile adds a non-root user with sudo access.
ARG USERNAME=container-user
ARG USER_UID=1000
ARG USER_GID=$USER_UID

# Add a non-root user and group
RUN addgroup -S $USERNAME && \
    adduser -S $USERNAME -G $USERNAME --shell /bin/sh

# Install Elm using the provided method, elm-test and elm-format via npm
RUN export DEBIAN_FRONTEND=noninteractive && \
    # Install Elm binary
    curl -L -o elm.gz https://github.com/elm/compiler/releases/download/0.19.1/binary-for-linux-64-bit.gz && \
    gunzip elm.gz && \
    chmod +x elm && \
    mv elm /usr/local/bin/elm && \
    # Install elm-test and elm-format via npm
    npm install --global \
        elm-test@${ELM_TEST_VERSION} \
        elm-format@${ELM_FORMAT_VERSION} \
        elm-watch@beta && \
    # [Optional] Update UID/GID if needed
    if [ "$USER_GID" != "1000" ] || [ "$USER_UID" != "1000" ]; then \
        groupmod --gid $USER_GID $USERNAME && \
        usermod --uid $USER_UID --gid $USER_GID $USERNAME && \
        chown -R $USER_UID:$USER_GID /home/$USERNAME; \
    fi && \
    # Create the elm cache directory where we can mount a volume
    mkdir /home/$USERNAME/.elm && \
    chown $USERNAME:$USERNAME /home/$USERNAME/.elm && \
    # Create the .azure directory
    mkdir -p /home/container-user/.azure && \
    chown $USERNAME:$USERNAME /home/$USERNAME/.azure

ENV ENV=/home/$USERNAME/.profile

USER $USERNAME
RUN sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" || true
RUN git clone --depth=1 https://github.com/romkatv/powerlevel10k.git /home/$USERNAME/.oh-my-zsh/custom/themes/powerlevel10k

RUN dotnet tool install --global csharp-ls
ENV PATH="$PATH:~/.dotnet/tools"
USER root

ENV PATH="/opt/venv/bin:$PATH"

docker-compose.yml

services:
  dev:
    build:
      context: .
      dockerfile: Dockerfile.omnia

    volumes:
      # 'cached' optimizes mount performance on macOS/Windows.
      - ../..:/workspace:cached
      - my-app-elm-devcontainer:/home/container-user/.elm
    command: sleep infinity
    networks:
      - internal
  nginx:
    image: nginx:alpine
    container_name: my-app_nginx
    ports:
     - "80:80"
     - "443:443"
     - "8314:80"
    networks:
      - internal
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/nginx/ssl:ro
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      - dev
      - squidex
  mongo:
    image: "mongo:6"
    volumes:
      - my-app_mongo_data:/data/db
    networks:
      - internal
    restart: unless-stopped
  squidex:
    image: "squidex/squidex:7"
    ports:
      - "8376:5000"
    environment:
      - URLS__BASEURL=https://squidex.my-app.dk
      - IDENTITY__ALLOWHTTPSCHEME=false
      - EVENTSTORE__MONGODB__CONFIGURATION=mongodb://mongo
      - STORE__MONGODB__CONFIGURATION=mongodb://mongo
      - IDENTITY__ADMINEMAIL=sukkerfrit@gmail.com
      - IDENTITY__ADMINPASSWORD=Lucas2007!
      - ASPNETCORE_URLS=http://+:5000
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/healthz"]
      start_period: 60s
    depends_on:
      - mongo
    volumes:
      - my-app_squidex_assets:/app/Assets
    networks:
      - internal
    restart: unless-stopped

volumes:
  my-app-elm-devcontainer:
  my-app_squidex_assets:
  my-app_mongo_data:

networks:
  internal:
    driver: bridge

And now for the quite important nginx.conf:

worker_processes 1;
events {
    worker_connections 1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # Define resolver to handle host.docker.internal
    resolver 127.0.0.11;

    server {
        listen 80;
        server_name localhost my-app.dk;

        location /api/ {
            set $backend_upstream host.docker.internal:5130;
            rewrite ^/api/(.*)$ /$1 break;
            proxy_pass http://$backend_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }

        location /cms/ {
          set $backend_upstream host.docker.internal:5140;
          rewrite ^/cms/(.*)$ /$1 break;
          proxy_pass http://$backend_upstream;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection 'upgrade';
          proxy_set_header Host $host;
          proxy_cache_bypass $http_upgrade;
        }
        # Proxy frontend requests to Elm dev server
        location / {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            sub_filter '</head>' '<meta name="environment-name" content="local" /></head>';
            sub_filter_once on;
            # Only apply sub_filter to index.html
            # sub_filter_types text/html;
        }

        location = /robots.txt {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream/robots.txt;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
        }

        location = /humans.txt {
            set $frontend_upstream host.docker.internal:3033;
            proxy_pass http://$frontend_upstream/humans.txt;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
        }
    }
    server {
        listen 80;
        server_name squidex.my-app.dk;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name squidex.my-app.dk;

        ssl_certificate /etc/nginx/ssl/squidex.crt;
        ssl_certificate_key /etc/nginx/ssl/squidex.key;
        ssl_protocols TLSv1.2 TLSv1.3;

        location / {
            proxy_pass http://squidex:5000;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host $host;

            # WebSocket support
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';

            # Authentication flows
            proxy_cookie_path / /;
        }
    }
}

We are not done yet!

You'll need to:

Create your own certs (.devcontainer/ssl/...)
Update your hosts file (/ect/hosts)
Remove or add your own versions of the app's for /api/ and /cms/

This should get you up and running with the basics of Squidex!

Security `/cms/`

I just create a wrapper/proxy for the Squidex api. This is done in order to keep the Client Secret - well secret. In production I use the role Reader for public stuff like Blog's, faq's etc.

If you want the code for the proxy/wrapper do write me.

Testing the setup with custom domain name

From your host machine eg. run:

curl -v http://my-app.xyz/cms/proxy/api/content/my-app/blog

curl -v -k https://squidex.my-app.xyz/squidex/app

Tust me bro!

Make your host machines browsers trust your self-signed cert for the test domain name

On Mac:

Open Keychain Access
I used 'login' as Default Keychain
File -> Import Items
Import the created cert
Set the trust level (Double click on the file)

Preparing for Production

When we have published all our containers we are ready to create yet another docker-compose file. This one is for testing the entire system as production like as possible.
That means we will be setting up:

A completely new docker-compose.my-app.yml
A completely revised nginx.conf
Create new a certificate just for this test (Could be omitted)

Create a Certificate for multiple domain names

.... Coming soon ....

DEV Community: Theodor Heiselberg

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

AI, Cognitive Debt, and Ownership

The dark side

What Is Cognitive Debt?

Shared Theory: The Real Asset

AI-PR Review Framework

1. Review Like a Junior Developer

2. The PR Owner Must Document Decisions

3. Rotate Ownership of Critical Areas

Guardrails for AI Usage

The Debugging Confidence Standard

Conclusion

How to Disable Github Copilot Autocomplete in vs code

Why?

(4)Creating the Pinnacle of Niche Software: Abandoning localhost:1234 - locally!

About

Goals

The moving parts

Reverse Proxy

Enable HTTPS

Method 1 (Not so good)

Method 2 (Better)

Trust the Certificate in macOS Keychain

Update your hostfile

Use a script to add cert

Notes for Linux users

Conclusion

Production Parity: Routing Local Traffic with a Reverse Proxy

The Problem: Port Mismatch

The Solution: A Reverse Proxy

Configuration: The Hosts File

Benefits

(3)Creating the Pinnacle of Niche Software: Using vite-plugin-elm-watch

About

First let's setup vite to handle building Elm

Environment Management with site-config-loader

1. Create Configuration Files

2. Inject the Environment Meta Tag

3. Register the Plugin in Vite

4. Verify the Setup

Adding tailwind

Using Environment Variables in Elm

Conclusion

(2)Creating the Pinnacle of Niche Software: The devcontainer

The Elm development environment

Building the base container

The devcontainer setup

Folder structure

Comments

Conclusion

Creating the Pinnacle of Niche Software: Consume Squidex Headless CMS Api's in ELM!

There is a first time for everything, I guess

Enter Elm!

The tech stack of niche software

Conclusion

Using DooD in a devcontainer like a true pro!

Yes - It is possible to use DooD in a devcontainer

devcontainer.json

docker-compose.yml

Dockerfile.debian

That's it!

Next steps

Don’t use Alpine as a dev machine when running a devcontainer - trust me bro!

Getting started with Squidex - the big picture

The Big Picture: The Philosophy Behind Our Setup

The Development Environment

The devcontainer

We are not done yet!

Security /cms/

Testing the setup with custom domain name

Security `/cms/`