Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,17 @@ chmod +x ./install-customer.sh

For the Linux deployment-executor service installer and its security requirements, see [Customer-managed deployment executor](CUSTOMER_DEPLOYMENT_EXECUTOR.md).

## Customer-managed deployment executor

The Engine node installer and the deployment executor are separate services:

- **Engine node:** the PowerShell installer `install-customer.ps1` supports Windows hosts using Docker Desktop in Linux-container mode. The Bash installer `install-customer.sh` supports Linux hosts with Docker Engine and Compose v2. Both install the Engine container and establish signed Fleet heartbeats.
- **Deployment executor:** this customer-hosted receiver applies approved Engine version changes after Agata sends a signed `deployment.created` event. It verifies the signature, node identity and version allowlist, performs fixed Compose operations, checks runtime health and reports the observed result to the Control Plane.
- **Linux production service:** the supplied `install-deployment-executor.sh` installs the receiver as a protected systemd service. It requires Node.js 22+, Docker Engine/Compose, systemd and a customer-managed HTTPS reverse proxy.
- **Windows executor host:** the Node.js receiver can run interactively for development or staging. Production requires a customer-managed Windows service wrapper with a protected service account, or a customer-owned orchestrator. The Linux systemd installer is not a Windows service installer.

In Agata Proxima, **Deployments → Set up deployment executor** creates the dedicated organization API key and signed webhook and returns the one-time `deployment-executor.env` file. It does not remotely install software or configure DNS. Install the public executor on the customer host first, configure its HTTPS route, then use the dashboard wizard to provision the credentials. Follow the [complete customer deployment executor guide](docs/CUSTOMER_DEPLOYMENT_EXECUTOR.md) for the installation, configuration, security and rollback procedure.

### Network and security requirements

- The Engine listens on TCP 6432 and binds to host loopback by default. Keep this binding when the application runs on the same host.
Expand Down
6 changes: 3 additions & 3 deletions docs/CUSTOMER_DEPLOYMENT_EXECUTOR.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,12 +52,12 @@ Set PROXIMA_DEPLOYMENT_TARGETS_FILE to this file in the executor environment. Ea

## Install the Engine (customer node)

The dashboard gives the customer a node-specific `.env`, a one-time enrollment-token file and a tenant-signing-key file. The customer does not need to hand-write Docker Compose configuration or paste secrets into shell commands.
The dashboard gives the customer a node-specific `.env` and a separate one-time enrollment-token file. During signed HTTPS enrollment, the Control Plane also delivers the node heartbeat credential and the organization's derived tenant-token verification key; neither is downloaded as a separate file. The Control Plane master signing secret is never sent to the customer host. The customer does not need to hand-write Docker Compose configuration or paste secrets into shell commands.

1. Install Docker Desktop (Windows) or Docker Engine with the Compose v2 plugin (Linux).
2. Download the Engine ZIP from the node setup screen and extract it.
3. In the extracted folder, create a `secrets` directory.
4. Place the downloaded `.env` in the repository root. Place the one-time token at `secrets/node_enrollment_token` and the tenant signing key at `secrets/tenant_signing_key`.
4. Place the downloaded `.env` in the repository root. Place the one-time token at `secrets/node_enrollment_token`. No `tenant_signing_key` file is created or required: the Engine receives the organization's derived verification key during enrollment and persists it in its protected node identity.
5. Run the supplied installer from that folder:

**Windows PowerShell**
Expand All @@ -71,7 +71,7 @@ The dashboard gives the customer a node-specific `.env`, a one-time enrollment-t
./install-customer.sh
```

The installer validates the required files and Docker Compose configuration, builds the Engine image locally, starts the container, and waits for its real Docker health check. It prints the container logs if startup fails. The Engine consumes the one-time enrollment token from the mounted secret, persists its node identity in a Docker volume, and begins signed heartbeats. The token is not needed again after successful enrollment. Keep the `.env` and `secrets` directory private; never commit or email them.
The installer validates the `.env`, one-time enrollment-token file and Docker Compose configuration, builds the Engine image locally, starts the container, and waits for its real Docker health check. It prints the container logs if startup fails. The Engine consumes the one-time enrollment token from the mounted secret, persists its node identity in a Docker volume, and begins signed heartbeats. The token is not needed again after successful enrollment. Keep the `.env` and `secrets` directory private; never commit or email them.

The Engine listens on port 6432 and binds to loopback by default. Keep that binding when the application runs on the same host. If the application is on another host or container network, deliberately configure a private reachable bind address/network and firewall policy; do not expose PostgreSQL proxy traffic to the public internet.

Expand Down
Loading