you will find that there are ways to run Fossil inside a container even
on entry-level cloud VPSes. These are well-suited to running Fossil; you
don’t have to resort to [raw Fossil service](./server/) to succeed,
leaving the benefits of containerization to those with bigger budgets.

For the sake of simple examples in this section, we’ll assume you’re
integrating Fossil into a larger web site, such as with our [Debian +
nginx + TLS][DNT] plan. The Fossil server instance listens on a
high-numbered port, on localhost only, and the front-end web server
reverse-proxies this out to the public.  Containers are a fine addition
to such a system, isolating those elements of the site, thus greatly
reducing the chance that they’ll ever be used to break into the host as
a whole.
nginx + TLS][DNT] plan. This is why all of the examples below create
the container with this option:

```
  --publish 127.0.0.1:9999:8080
```

The assumption is that there’s a reverse proxy running somewhere that
redirects public web hits to localhost port 9999, which in turn goes to
port 8080 inside the container.  This use of Docker/Podman port
publishing effectively replaces the use of the
“`fossil server --localhost`” option.

For the nginx case, you need to add `--scgi` to these commands, and you
might also need to specify `--baseurl`.

Containers are a fine addition to such a scheme as they isolate the
Fossil sections of the site from the rest of the back-end resources,
thus greatly reducing the chance that they’ll ever be used to break into
the host as a whole.

(If you wanted to be double-safe, you could put the web server into
another container, restricting it only to reading from the static web
another container, restricting it to reading from the static web
site directory and connecting across localhost to back-end dynamic
content servers such as Fossil. That’s way outside the scope of this
document, but you can find ready advice for that elsewhere. Seeing how
we do this with Fossil should help you bridge the gap in extending
this idea to the rest of your site.)

[DD]:  https://www.docker.com/products/docker-desktop/

```
  $ patch -p0 < containers/Dockerfile-nojail.patch
  $ make reconfig      # re-generate Dockerfile from the changed .in file
  $ docker build -t fossil:nojail .
  $ docker create \
    --name fossil-nojail \
    --publish 9999:8080 \
    --publish 127.0.0.1:9999:8080 \
    --volume ~/museum/my-project.fossil:/museum/repo.fossil \
    fossil:nojail
```

This shows a new trick: mapping a single file into the container, rather
than mapping a whole directory. That’s only suitable if you aren’t using
WAL mode on that repository, or you aren’t going to use that repository

    --name fossil \
    --cap-drop CHOWN \
    --cap-drop FSETID \
    --cap-drop KILL \
    --cap-drop NET_BIND_SERVICE \
    --cap-drop SETFCAP \
    --cap-drop SETPCAP \
    --publish 9999:8080 \
    --publish 127.0.0.1:9999:8080 \
    localhost/fossil
  $ sudo podman start fossil
```

It’s obvious why we have to start the container as root, but why create
and build it as root, too? Isn’t that a regression from the modern
practice of doing as much as possible with a normal user?

commands:

```
  $ sudo systemd-nspawn \
    --oci-bundle=/var/lib/machines/fossil \
    --machine=fossil \
    --network-veth \
    --port=9999:8080
    --port=127.0.0.1:127.0.0.1:9999:8080
  $ sudo machinectl list
  No machines.
```

This is why I wrote “reportedly” above: it doesn’t work on two different
Linux distributions, and I can’t see why. I’m putting this here to give
someone else a leg up, with the hope that they will work out what’s