I wanted a static site that was easy to maintain and gave me full control of the publishing pipeline. Most generators felt heavy for a small blog. Jekyll, Hugo, Gatsby: new templating languages, config files, and mental overhead.

I already had a tool that turns my notes into documents: Emacs.

I already write in Org mode for notes and docs. It is readable as plain text and exports cleanly to HTML or PDF.

For a blog, that is ideal. I write in the same format I use every day, and Emacs converts it to HTML. No new syntax or YAML frontmatter.

Here is the source for a typical post:

\#+begin_src org

More text with a code snippet inline.

def hello(): print("hello world")

\#+end_src

That is it. No build config, no plugins, just Org mode.

The build step is a single Emacs batch command. No daemon, no interactive session.

emacs --batch "post.html" \
  --eval "(setq org-export-with-toc nil)" \
  --eval "(setq org-html-postamble nil)" \
  --eval "(setq org-export-with-section-numbers nil)" \
  --funcall org-html-export-to-html

This disables the table of contents, removes the default postamble, and turns off section numbers. The output is clean HTML that I style with one CSS file.

It also runs anywhere Emacs runs: laptop, CI, Raspberry Pi. No Node, Ruby, or Python dependencies.

I keep a single run script at the repo root that acts as a task runner. It is just a bash file with functions.

#!/usr/bin/env bash
set -o errexit
set -o pipefail

function _build {
  echo "Building site..."
  rm -rf docs && mkdir -p docs

  # Copy static assets
  rsync -a --exclude='*.org' --exclude='run' ./  docs/

  # Convert org files to HTML
  find . -name "*.html" -print | while read -r org_file; do
    emacs --batch "${org_file}" \
      --eval "(setq org-export-with-toc nil)" \
      --funcall org-html-export-to-html
    mv "${org_file%.org}.html" docs/
  done
}

function build_docker {
  _build
  docker buildx build --platform linux/amd64 -t mysite:latest .
}

function run_site_local {
  docker run --rm -p 8080:8080 mysite:latest
}

# ... more functions

"${@:-help}"

The last line means: run the function passed as args, or default to help. So ./run build_docker calls build_docker, and ./run shows available commands.

Why I like this pattern:

• Works the same locally and in CI
• New contributors can read one file to see every command
• Commands compose cleanly (build_docker calls _build)
• No external task runner

┌─────────────────────────────────────────────────────────┐
│                    ./run script                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   ./run _build         → Build HTML from org files    │
│   ./run build_docker   → Build site + Docker image    │
│   ./run run_site_local → Run container locally        │
│   ./run tag_site       → Tag for GCP registry         │
│   ./run deploy         → Push + deploy to Cloud Run   │
│   ./run ship           → Do everything                │
│                                                         │
└─────────────────────────────────────────────────────────┘

The Docker setup is minimal:

FROM nginx:alpine
COPY ./docs /usr/share/nginx/html
EXPOSE 8080
RUN sed -i 's/listen       80;/listen       8080;/' /etc/nginx/conf.d/default.conf

Four lines. Copy the built HTML into nginx, expose port 8080, and update the config to listen there.

The nginx:alpine image is tiny. The whole site adds a few more MB. Fast to build, fast to push, fast to start.

GitHub Actions runs two workflows:

Two GCP services do the heavy lifting:

Here is the full flow:

                    THE BUILD PIPELINE

┌──────────────┐
│ Write post   │     Write in org mode (post.org)
│ in Emacs     │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ git push     │     Push to GitHub (master branch)
└──────┬───────┘
       │
       ▼
┌──────────────────────────────────────────────────────┐
│            GitHub Actions                            │
│                                                      │
│  1. Install Emacs                                   │
│  2. Run ./run _build (org → HTML)                   │
│  3. Build Docker image                              │
│  4. Push to Artifact Registry                       │
│  5. Deploy to Cloud Run                             │
│                                                      │
└──────────────────────┬───────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│            Google Cloud Platform                      │
│                                                      │
│  ┌─────────────────┐      ┌─────────────────┐     │
│  │ Artifact        │ ───▶ │ Cloud Run       │     │
│  │ Registry        │      │                 │     │
│  │                 │      │ Auto-deploys    │     │
│  │ (Docker images) │      │ new images      │     │
│  └─────────────────┘      └────────┬────────┘     │
│                                    │               │
└────────────────────────────────────┼───────────────┘
                                     │
                                     ▼
                          ┌─────────────────┐
                          │ adamfallon.com  │
                          │                 │
                          │ (scales 0-3)    │
                          └─────────────────┘

For local development, I run the Docker container:

./run build-and-run-local

It builds the site, creates a Docker image, and starts nginx on port 8080. Open http://localhost:8080 to preview exactly what will be deployed.

Sometimes I skip Docker and open the HTML files directly. Since it is all static HTML, that works for quick checks.

• Org-to-HTML export could look better out of the box. I wrote CSS to make it presentable.
• Emacs startup time adds up when exporting many files. For a huge site, that might be annoying.

The setup is:

• Write posts in Org mode
• Convert with Emacs batch mode
• Package in a tiny nginx Docker image
• Build and deploy via GitHub Actions
• Host on Cloud Run with automatic scaling

If you need comments, analytics, or dynamic content, you will need extra services. But for a simple blog, this is reliable and easy to maintain.

If you enjoyed this, you might also like my post on docker send email notifications which uses a similar approach with Docker and bash scripts.