> 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/operations/deployment-architecture.md).

# Deployment architecture

SECUREpass runs as a set of Java services behind a reverse proxy, backed by a relational database. This page covers how those services are laid out, which ports they listen on, and what changes when the deployment has to survive the loss of a node or a data centre.

For how to install them, see the *Deployment guide*.

## Deployment shapes

**Docker Compose** runs every service on a single machine. It is the fastest way to stand the platform up and the right choice for development and staging.

**WAR files on application servers** is the production path. Services are deployed onto Tomcat behind a reverse proxy, which is what every prerequisites document describes and what the POC builds use.

Both run the same services and read the same configuration; what differs is how they are packaged and how far they scale.

## Service and port reference

Each service listens on its own internal port and is reached through the reverse proxy at its context path. Confirm these against your own deployment configuration before opening firewall rules — they are the defaults, not a guarantee.

<table data-search="false"><thead><tr><th>Service</th><th>Container</th><th align="right">Internal port</th><th>Context path</th></tr></thead><tbody><tr><td>Nginx (reverse proxy)</td><td><code>sp-nginx</code></td><td align="right">80 → host 8080</td><td><code>/</code></td></tr><tr><td>SPAuth</td><td><code>sp-spauth</code></td><td align="right">8080</td><td><code>/AuthPage</code></td></tr><tr><td>SecurepassAdmin</td><td><code>sp-admin</code></td><td align="right">8082</td><td><code>/SecurepassAdmin</code></td></tr><tr><td>SecurepassSS</td><td><code>sp-ss</code></td><td align="right">8083</td><td><code>/Securepass</code></td></tr><tr><td>SPOTP</td><td><code>sp-otp</code></td><td align="right">8084</td><td><code>/OTP</code></td></tr><tr><td>TenantManager</td><td><code>sp-tm</code></td><td align="right">8085</td><td><code>/SPTManager</code></td></tr><tr><td>SPJDBC</td><td><code>sp-jdbc</code></td><td align="right">8086</td><td><code>/SPJDBC</code></td></tr><tr><td>SPScheduler</td><td><code>sp-scheduler</code></td><td align="right">8088</td><td><code>/SPScheduler</code></td></tr><tr><td>SPRADIUS</td><td><code>sp-radius</code></td><td align="right">1812 / 1813 UDP</td><td>—</td></tr><tr><td>SPSSH</td><td><code>sp-ssh</code></td><td align="right">8881</td><td>—</td></tr></tbody></table>

{% hint style="info" %}
Two of these do not sit behind the proxy. **SPRADIUS** answers RADIUS authentication on the standard UDP ports, so network devices and VPN concentrators reach it directly. **SPSSH** handles privileged SSH sessions, so its port has to be reachable from wherever privileged users connect.
{% endhint %}

### What each service does

| Service         | Role                                                                            |
| --------------- | ------------------------------------------------------------------------------- |
| SPAuth          | The authentication engine and login page — MFA, SAML and OIDC, token issuance   |
| SecurepassAdmin | The administrative console                                                      |
| SecurepassSS    | The Self-Service Portal that end users see                                      |
| SPOTP           | One-time password generation and validation                                     |
| TenantManager   | Tenant creation and isolation                                                   |
| SPJDBC          | Database connectivity for the database connectors and proxy                     |
| SPScheduler     | Scheduled jobs — directory syncs, dormant account handling, campaign automation |
| SPRADIUS        | RADIUS and TACACS+ authentication for network devices and VPNs                  |
| SPSSH           | The SSH gateway for privileged sessions                                         |

Because each service is separately deployed, they can be scaled independently — the authentication path usually needs the headroom long before the console does.

## Properties and the database

Every service reads a properties file holding its datasource, its endpoints and its keys. Those files are where a deployment is actually configured, and they are the first thing to check when a service starts but cannot reach something.

The database uses tenant isolation. Size it against your user volume and, more importantly, against your **audit log retention policy** — audit and session data grow faster and for longer than identity data does, and retention is usually set by a regulation rather than by preference.

## High availability and disaster recovery

A single-instance deployment is a POC deployment. Every requirement figure in the deployment guide is a single-instance minimum; production adds the following.

{% stepper %}
{% step %}

### Cluster the services

Deploy each service across more than one node behind the load balancer, so losing a node degrades capacity rather than availability.
{% endstep %}

{% step %}

### Make the database highly available

The services are stateless enough to restart; the database is not. Its HA arrangement is what determines whether the platform survives a failure.
{% endstep %}

{% step %}

### Choose a DC-DR topology

Active-active or active-passive across data centres, depending on how much you are willing to spend against how quickly you must recover.
{% endstep %}

{% step %}

### Replicate session-recording storage

Recordings are audit evidence and they are large. Losing them to a failed data centre is a compliance problem, not an operational one, so they need to be replicated deliberately rather than assumed to be covered by the database plan.
{% endstep %}

{% step %}

### Define RTO and RPO explicitly

Test against them. A recovery target that has never been rehearsed is an assumption.
{% endstep %}

{% step %}

### Document the inter-DC firewall rules

Cross-site traffic uses the same ports as the table above, and the rules are the part that gets forgotten until a failover is attempted.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Confirm sizing and topology with eMudhra before provisioning for production. The figures in the prerequisites documents are POC minimums for a single instance and do not account for high availability, load balancing or your real user population.
{% endhint %}