> ## Documentation Index
> Fetch the complete documentation index at: https://docs.d0pam1ne.blackhatethicalhacking.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploying Synapse

> Where Synapse runs, how to move it to a server, and the settings that matter.

Synapse runs inside the same D0pam1ne Pro install, so deploying it is deploying Pro with the module licensed. This page covers the shapes a deployment can take, moving from a local machine to a server, and the few settings that matter when clients reach it over the internet.

## Deployment shapes

* **All-in-one**: one box runs the testing side and the client portal together. Simplest, and the right choice for most teams. Findings you report are in Synapse immediately, no connection needed.
* **Hub and feeders**: a central server runs the portal that clients log in to, and one or more separate boxes test and push their reported findings up to it. Use this when the box you test on is not the box clients should reach. See [Connections](https://docs.d0pam1ne.blackhatethicalhacking.com/synapse/connections.md).

A common path is to start all-in-one on a workstation and later stand up a central Synapse on a server, with the workstation feeding into it.

## Moving to a server

When the destination server is **empty**, the cleanest move is a **backup and restore**, which clones the whole install to the new box.

**1. Back up the source**

On the source box, take a full backup. It is an encrypted snapshot of the database plus the files, including the vault key, so sealed API keys survive the move. (The JWT secret is deliberately not included; a new one is generated on the new box, which simply means everyone signs in again.)

**2. Restore onto the server**

Install D0pam1ne Pro on the server and restore the backup. Restore is a **full replace** of that install, not a merge, which is exactly what you want onto a fresh box: the server comes up as a clone of the source, clients, issues, scope and all.

**3. Point clients at the server**

Set the server's address (below), bring the portal up on it, and clients sign in there.

> [!WARNING]
>
> Because restore is a full replace, never restore onto a box that already has data you want to keep. For ongoing flow of new findings from another box after the move, use [Connections](https://docs.d0pam1ne.blackhatethicalhacking.com/synapse/connections.md), not repeated restores, cloning and then feeding the same project would double issues.

## Settings that matter over the internet

* **Address of Pro in links**: set this to the server's public URL. It is used in invite links and is baked into any Synapse connect string, so it must be correct before you create client invites or connections.
* **Reverse proxy body size**: evidence pushes and attachments can be large. Raise your reverse proxy's maximum request body size to at least match Synapse's upload limit (50 MB by default), or screenshot and file pushes will be rejected at the proxy.
* **Host encryption**: for a self-hosted box holding client findings, full-disk or volume encryption on the host is recommended, since Synapse keeps remediation data in its database and files on that machine.

## Updates and rollback

D0pam1ne Pro updates in place, and the updater protects a live Synapse: if a new build fails to start, it **auto-rolls-back**, restoring the previous version and the database so the portal comes back up on the last good build rather than staying down. This is why a bad update is recoverable without a manual restore.

> [!NOTE]
>
> Synapse's database uses additive auto-migration: a new build adds any missing columns on startup, so updates do not require a manual migration step and your remediation data is carried forward.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.