> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/getting-started/deployment-guide/properties-and-key-configuration.md).

# Properties and key configuration

Every SECUREpass service reads a properties file at startup. Between them, those files are where a deployment is actually configured — the database it talks to, the addresses of the other services, the gateways it sends through, and the key material it encrypts with.

Get them right before the first start. Most deployment problems that look like a broken service are a properties file pointing somewhere wrong.

## Which services have one

Each service reads its own file, so a setting has to be correct in every service that needs it — a database change is not made in one place.

| Service         | What its file governs                                            |
| --------------- | ---------------------------------------------------------------- |
| SPAuth          | Authentication, token issuance, SAML and OIDC endpoints          |
| SecurepassAdmin | The admin console and its connection to the other services       |
| SecurepassSS    | The Self-Service Portal                                          |
| SPOTP           | OTP generation and validation, and the gateways it sends through |
| TenantManager   | Tenant creation and isolation                                    |
| SPJDBC          | Database connectivity for the connectors and the database proxy  |
| SPScheduler     | Scheduled jobs and their datasource                              |
| SPRADIUS        | RADIUS and TACACS+ listeners, shared secrets and allowed clients |
| SPSSH           | The SSH gateway for privileged sessions                          |

## What is in them

**Datasource.** The database host, name, credentials and connection-pool limits. Where the multi-database performance configuration is used, the reader and writer datasources are set separately.

**Endpoints.** The addresses the service uses to reach the others, and the public hostnames it presents. These have to agree with what the reverse proxy and your DNS records say, or requests resolve internally to somewhere that does not answer.

**Gateway settings.** Mail and SMS gateway details where the service sends messages.

**Encryption keys.** The key material the service uses to protect data at rest, and the configuration for BYOK or an external HSM where one is in use.

## Key material

Cryptographic protection at rest is delegated to an external HSM or key vault rather than held by the application, and the properties file carries the configuration that binds a service to it — not the key itself, where a vault is in use.

{% hint style="warning" %}
**Keys are read at startup and not re-read.** A service that started with placeholder or wrong key material carries on using it until it is restarted, and anything it wrote in the meantime was protected with the wrong key. Set key material before the first start rather than correcting it afterwards.
{% endhint %}

Changing key material on a running deployment is not a configuration edit — data already encrypted under the old key has to be handled. Plan it with eMudhra rather than editing the file and restarting.

## Handling the files

These files contain database credentials, gateway passwords and key configuration in a form the services can read. Treat them as secrets, not as configuration.

* **Restrict filesystem permissions** to the account each service runs as, and no wider.
* **Keep them out of version control.** If a deployment is managed from a repository, the files belong in a secrets store with references in the repository, not the values.
* **Back them up separately** from the application, and to somewhere with access control of its own. A deployment cannot be rebuilt from the database alone.
* **Redact them before sharing.** A properties file attached to a support ticket is a credential leak unless the values have been removed.

## After changing one

A service reads its properties file at startup only. **Restart the service** for a change to take effect — and restart just that service, since a change in one file does not affect the others.

Then confirm the service came back healthy rather than assuming it did. A properties file with a typo usually produces a service that starts and then fails on its first real request, which is a slower failure to notice.

{% hint style="info" %}
File names and locations differ between the container and WAR deployments, and between releases. Take the exact paths and the full property list from the configuration supplied with your deployment package, and confirm anything unclear with eMudhra rather than inferring it.
{% endhint %}