peart-portal CLI

peart-portal is the client-facing portal binary, kept separate from peart on purpose: it is a different process with a different entry point, so the internet-facing surface can never reach an internal handler even by accident.

It has one subcommand, and that is the whole surface. Backup, key export and migration all run from peart, because the portal is not the surface that owns the data.

Running the portal

Flag	Default	What it is
-config	/etc/peart/config.yaml	The same file peart serve reads, each binary reading only its own section

peart-portal serve -config /etc/peart/config.yaml

peart-portal help prints the command list and peart-portal version prints the version, the same way they do on the other binary. Flags accept one dash or two, and an invocation that cannot be parsed exits 2.

What it can and cannot reach

The portal's primary database connection is opened read-only through its own connection string, and it holds no master key and no access to the evidence directory. The writing it does goes through a second connection, reached by an interface with a fixed set of methods rather than the whole store: the session, which always existed, and the client's fix declaration. Beyond that it serves what has been published and released, with the renditions, scoped to the client the account belongs to, and nothing else.

Running it as its own system user is what turns that design into something the operating system enforces rather than something the code promises. The file modes that make both binaries able to read one configuration file, each through different bits, are in Configuration.