# Why a published site lives in the configuration

`expose add` used to write a Caddy file straight onto the machine and
reload Caddy. It worked, but it left the only record of the site on the
machine: rebuild from the configuration, and the sites `expose` had
written never came back.

So the record moved. A route is a field of the workspace that owns it:

    workspaces:
      - name: alice
        routes:
          - {host: app.example.com, port: 8080}

`expose add` writes that line. `sync` renders one file per workspace,
`alice-routes.caddy`, into the `sites.d` folder the `caddy` package
provides, and reloads Caddy when the file changed. `expose rm` deletes
the line, and the next `sync` deletes the block. There is one
direction — configuration to machine — devmachine never reads the machine
to learn what should be published, only to check it agrees.

## What `sync` takes away

When the configuration owns a host, `sync` also removes the one-host file
the old `expose` wrote for it, since Caddy refuses to reload with one
host named twice. A workspace whose last route was removed gets its
`<workspace>-routes.caddy` removed, not emptied — an empty file would
still serve.

Nothing else in `sites.d` is touched. A file another package added, or
written by hand, is not the configuration's to delete; `expose list`
reports it as `unmanaged` and says how to adopt it.

A file another package adds to `sites.d` — like the one `caddy-sites`
writes — also reloads Caddy when `sync` changes or removes it. Without that
reload, Caddy would keep serving the old file until something else
reloaded it.

## Why DNS is still pointed by `add`

The DNS record is not in the configuration, and `sync` does not write it.
A name that does not resolve fails minutes later, in Caddy's certificate
log, where nobody is looking — so `add` points the name in the same
breath, printing the record to create by hand if the machine is
unreachable.