Conventionally in a modern scenario one needs not run any of the djbwares toolset's publicfile services.
Exactly how one runs httpd, gopherd, geminid, and ftpd as services is beyond the scope of this Guide.
The configure utility of the original publicfile is long-since obsolete, and service definitions/bundles for specific service management systems (from daemontools through runit to nosh) have become available elsewhere over the years.
geminid is the only one of the services that requires things that do not come in the box with djbwares.
A GEMINI server is required to use SSL (a.k.a. TLS) rather than speak plaintext, and there are no UCSPI-SSL tools in the djbwares toolkit.
However, one alternative use for geminid is to provide a form of FINGER and NICNAME (a.k.a. WHOIS) services.
The FINGER and NICNAME protocols are flexible enough that a valid unencrypted GEMINI request is a subset of both FINGER and NICNAME requests.
For security and privacy reasons one must not provide either the original or later forms of NICNAME, nor provide the original FINGER.
geminid provides a novelty alternative that can be accessed by old clients:
geminid supports schema-less URLs as a protocol extension, in order to enable this.
The Bernstein convention is for publicfile services to all share a single directory tree, conventionally with its root at the directory /public/file.
However, a convention deployed by the nosh toolset is the existence of a publicfile user, with the publicfile services serving up files from that account's ~publicfile/public directory.
There is nothing stopping /public/file being a symbolic link to this.
All of the publicfile services run as this account.
Every subdirectory of this root is a virtual host.
Another Bernstein convention is that 0 is the default virtual host, stemming both from httpd's default in the face of HTTP/0.9 and HTTP/1.0 and a common choice for tcpserver -l option.
For security reasons this is nowadays not recommended.