SeaTable Website

The Hugo static site behind seatable.com, including the marketing pages, the blog, and the multi-language help center. Everything runs in Docker — you do not need a local Hugo, Node, or Go installation.

Development

Requirements: Docker and Docker Compose.

docker compose up

The first run builds the Hugo image (see Dockerfile) and installs the theme's npm dependencies (via entrypoint.sh). Once it's up, open:

http://localhost:1313

The repository is mounted into the container, so edits to content or the theme trigger a live reload. Inside the container two watchers run concurrently (docker:watch in src/themes/seatable/package.json):

• Hugo — hugo server --source /hugo/src (drafts and future-dated content enabled).
• Tailwind — rebuilds the stylesheet on change.

Optional configuration

Copy .env-example to .env to toggle build features:

• ENABLE_PAGEFIND (default 0) — build the Pagefind search index.
• ENABLE_TAILWIND (default 1) — run the Tailwind watcher.

Editing styles

Edit src/themes/seatable/assets/css/styles.css. The compiled file assets/css/styles.output.css is generated by the Tailwind watcher inside the container and is git-ignored — don't edit it by hand (a local npm run build will typically fail with EACCES because the container owns the file; just let the running container regenerate it).

Production build

./build.sh

This renders the site with the production backend URLs and builds the Pagefind index into src/public — the same output the deployment workflow ships.

Tooling

Versions are pinned in the Dockerfile and src/themes/seatable/package.json:

• Hugo Extended 0.152.2 (downloaded as a prebuilt binary — Hugo Extended bundles its own SCSS compiler, so no Go toolchain is required)
• Node 22, Tailwind CSS 3.4, Pagefind 1.3

Note — Go removed from the image (2026-07): the Dockerfile previously installed a full Go toolchain (~hundreds of MB). Nothing in the build uses it — the site is built by the prebuilt Hugo Extended binary, which does not need Go — so it was removed to keep the image lean and the build faster. If a future dependency ever needs to compile Go, reintroduce it here.

Deployment

The deployment is automated through GitHub Actions: build.yml.

The workflow runs on main and uses rsync to deploy the generated site to the remote machine.

Required Steps

• Install Docker: curl -fsSL get.docker.com | bash

• Install rsync: apt install -y rsync

• Create /opt/seatable.com and a subdirectory for the static files: mkdir -p /opt/seatable.com/public

• Copy deploy/caddy.yml to /opt/compose/caddy.yml

• Create /opt/compose/.env and enter all required environment variables (take a look at deploy/.env-release)

• Start the services: docker compose up -d

• Create a new SSH key pair on the remote machine: ssh-keygen -t rsa -b 4096 -f ~/.ssh/github-actions -C "GitHub Actions"

• Create /opt/compose/ssh-command-runner.sh with the following contents:

  #!/bin/sh
  # You can have only one forced command in ~/.ssh/authorized_keys.
  # This wrapper allows several commands.
  
  case "$SSH_ORIGINAL_COMMAND" in
    rsync*) exec /usr/bin/rrsync -wo /opt/seatable.com/public ;;
    "validate-caddy-config") docker exec caddy caddy validate --config /config/caddy/Caddyfile.autosave --adapter caddyfile ;;
    "reload-caddy-config") docker exec caddy caddy reload --config /config/caddy/Caddyfile.autosave --adapter caddyfile ;;
    *) echo "Command not allowed"; exit 1 ;;
  esac

  The validatew-caddy-config and reload-caddy-config commands are executed as part of the GitHub Actions workflow to validate and reload the Caddy configuration.

• Make the script executable by running chmod +x /opt/compose/ssh-command-runner.sh

• Add the public key of this key pair to ~/.ssh/authorized_keys on the remote machine and prepend the line with command="/opt/compose/ssh-command-runner.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

It looks like this:

# other keys ...

# GitHub Actions
command="/opt/compose/ssh-command-runner.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza... (hier geht der Key weiter...)

This restricts the owner of the private key to only run the wrapper script.

• Add the following variables to this GitHub project:
  • SSH_HOST: IP address of the remote host
  • SSH_USER
  • SSH_PRIVATE_KEY: Private key of the created key pair

Backend Deployment

Please take a look at christophdb/hugo-backend for instructions on how to deploy the backend alongside the frontend.