# Private deployment inputs

Use `requirements.json` for the exact files, roles and required environment keys
in this kit. Evaluation does not require the durable-profile credentials below.
All inputs can be prepared offline. Site credentials, trust roots, an existing
provider and Enterprise identity/fencing services remain deployment inputs;
reading a skill or extracting configuration needs none of them.

## Files and role environment

Copy `.env.example` and each selected role's `.env.example` to the corresponding
filename without `.example`, preserving existing private inputs. Setup uses
Docker/Compose, tar and ordinary file operations; no language runtime is needed.
Use a private `secrets/` directory (0700), role env files (0600), and container
read access for mounted files. The containers run as UID/GID 10001. For a Linux
bind file owned by the operator, an administrator can assign group 10001 and
mode 0640 to policies/private keys; public CA/certificate files can be 0644.
Only the files themselves are mounted, not the host secrets directory.

Role env files contain raw single-line `KEY=value` entries. Dollar signs,
quotes and backslashes are literal; do not add shell quoting or `export`.
Keep credentials out of `.env`, Compose YAML, command arguments and reports.
The required keys are:

| Key | Input |
| --- | --- |
| `NGINZ_IOT_POSTGRES_DSN` | Authority/gateway libpq connection settings. Use the site's actual host/database/role and `sslmode=verify-full sslrootcert=/run/secrets/postgres-ca.crt`. |
| `PGPASSWORD` | That role's private PostgreSQL credential. Bridge env files use the separate bridge role's credential. |
| `NGINZ_IOT_AUDIT_KEY` | Private, deployment-stable audit key of 32–64 bytes, supplied to authority. Preserve it for recovery. A securely generated 64-character hex value fits. |
| `NGINZ_IOT_MQTTSN_PASSWORD` | When selected, the actual credential for the configured MQTT-SN identity (`operator`, tenant `core` in this kit). |

Do not copy one role's env file over another. The selected bridge configuration
contains its own provider role/settings. The supplied SQL grant file documents
its access after store/table provisioning; no database credential is embedded.

For a fresh deployment, use the site's chosen cryptographically secure secret
process to generate a 32-byte random value encoded as 64 hexadecimal characters.
Place it in the authority's raw env entry without printing or sharing it.
Preserve an existing deployment's key; keep it stable and back it up with the
protected inputs. No particular key-generation tool is required.

## MQTT policy

The customer image default and kit template grant no identities or topic
access. Before traffic, supply `secrets/auth.policy` through your private
credential process, preserving an existing deployment's policy and generation.
The native versioned policy form is:

```text
policy 1 generation=1
principal operator ARGON2ID_PHC tenant=core enabled
allow principal:operator publish devices/core/#
allow principal:operator subscribe devices/core/#
```

`ARGON2ID_PHC` is a placeholder; replace it with the actual hash, without quotes.
Use the site's approved offline credential tooling or existing compatible
hashes. The accepted profile is **Argon2id v19, memory 65536 KiB, time cost 3,
parallelism 4, a 16-byte salt and a 32-byte tag**. The PHC prefix is
`$argon2id$v=19$m=65536,t=3,p=4$`; salt and tag use canonical unpadded Base64.
The hash is not the password sent by the client. Legacy source password hashes
need the migration skill's explicit compatibility/reset decision.

Choose the actual principal, tenant and narrow topic grants for the deployment.
The selected MQTT-SN gateway credential must match its policy identity; inspect
the emitted nginx configuration for certificate identity mapping when using
mTLS WebSocket. Preserve/increase the policy generation according to the site's
change process; match Enterprise governance's configured policy generation.

Run the kit's existing native config checks after editing. Config validity is
a local prerequisite; verify successful authentication and denial with the
intended client after startup.

## Trust and external services

Supply the PostgreSQL CA, gateway certificate/private key and client CA listed
in the contract. Use the site's PKI process and matching certificate identities;
the kit never fetches a certificate or provisions a public identity provider.
Enterprise's reviewed SSO edge and external fencing/router must be reachable
on the deployment's local network. No internet access is required for setup,
but selected broker/provider/sink communications must be available.

Load approved provider/client images before disconnecting if those services
are containerized. Retain exact image IDs, service names, trust and ownership
decisions privately. No setup command automatically downloads an image or
creates a database, SSO authority or failover controller.