How publishing works

Publishing puts your finished site where people can visit it. There are two ways to do it, and several places it can go. Here's how to choose.

Your site is built into plain files, in public/. Publishing copies them to a web server: the computer that hands pages to visitors. HotDog doesn't mind which web server or host you use.

Two ways to publish

Push: something sends the site to the server. You, or your git platform's pipeline, run hotdog-cms publish. It builds the site, checks it, and sends it to the places listed in publish.yaml.

Pull: the server fetches the site itself. The pull agent runs on your web server, watches your site's repository, and rebuilds when it changes. Nothing has to connect in to your server, so there are no server passwords or keys for anyone to steal.

Either way, the checks run first. A site with errors is never published.

Which should I use?

If you…	Use
have a web server of your own (a VPS, a home server)	the pull agent: set it up once and forget it
want your git platform to publish every accepted change	your platform's pipeline, with a target below
publish now and then, by hand	`hotdog-cms publish`, with a target below
host on a container platform	a container

Where it can go: targets

Targets are listed in publish.yaml, in your site's folder. The template comes with an example to copy, publish.example.yaml.

Type	For	Page
`dir`	A web server on the same computer	To a folder
`rsync`	A server you reach over SSH	Over SSH
`container`	Docker, Podman, Kubernetes, container hosting	As a container
`command`	Anything else: object storage, a CDN, your own script	Your own command

Publish to one target, or all of them:

hotdog-cms publish server
hotdog-cms publish -all

Your own command

The command type runs any program with the finished site, without a shell. {out} is the folder holding the build:

targets:
  bucket:
    type: command
    command: [aws, s3, sync, "{out}", "s3://example-site", --delete]

Your own steps, before and after

Any target can run steps of yours around publishing: building a search index before, telling a monitoring service after:

targets:
  server:
    type: rsync
    host: deploy@${DEPLOY_HOST}
    path: /var/www/example.org
    before:
      - [pagefind, --site, "{out}"]
    after:
      - [curl, -fsS, "https://hc-ping.com/${HEALTHCHECK_ID}"]

before runs after the build, before publishing; if it fails, nothing is published.
after runs once the site is live; if it fails, the site is still published, and you're told.

These steps run with your rights, so only people who maintain the repository can change publish.yaml from the editor. For the strongest separation, keep the targets file outside the repository and pass it with -targets.

${NAME} reads an environment variable, so server names don't have to be written in the repository.