# Installation and deployment choices

> Source: https://docs.clonepartner.com/getting-started/installation/

Envoy is distributed as a customer build containing the compiled runtime, web UI, bundled task and job definitions, technical references, and connectors selected for that deployment.

Envoy is not installed from a public package registry. Obtain the deployment bundle or image and its matching configuration through your ClonePartner delivery or support channel.

See [Customer builds and connector catalogs](/deployment/customer-builds-and-catalog) for build-specific packaging and connector availability.

## Choose a topology

### Remote Docker

Use the two-service Docker topology for a dedicated Linux host:

- a **control plane** serves the UI and API;
- an internal **executor** runs task subprocesses;
- host-mounted `state`, `data`, and `dbs` directories hold persistent files;
- a reverse proxy terminates HTTPS in front of the loopback-only control-plane port.

This is the simplest production topology when you operate a virtual machine. Continue with [Remote Docker deployment](/deployment/remote-docker).

### Azure

Use Azure Container Apps when the deployment must live in an Azure subscription:

- the control plane has external HTTPS ingress;
- the executor has internal ingress;
- Azure SQL can hold product state and run logs;
- Azure Key Vault can hold connector and TOTP secrets;
- Azure Blob Storage is available to data pipelines.

Continue with [Azure deployment](/deployment/azure).

### Direct binary

The supplied binary can run a task, a job, the server, or an executor without Docker. Direct-binary mode is useful for development, controlled batch execution, and environments where you provide process supervision yourself.

Examples in this guide assume the executable is available as `envoy`. A customer build may have a different filename; its command syntax is the same.

## Production prerequisites

Prepare these before first boot:

1. A unique encryption key for persisted application secrets.
2. A separate shared key for control-plane-to-executor authentication when using HTTP executors.
3. Durable storage or a managed state database.
4. A browser-facing HTTPS origin.
5. Network routes from the executor to every source and destination.
6. An image or binary built with the connectors your workloads require.

:::callout{type="warning"}
Keep the encryption key with the state backup. Losing it makes encrypted connector and TOTP data unreadable. Replacing it with a new value is not a recovery procedure.
:::

## Persistent state

Do not treat every file in the container as durable. In the standard Docker layout:

| Container path | Purpose |
|---|---|
| `/app/state` | Server YAML and SQLite state database |
| `/app/data` | CSV, YAML, and other data files |
| `/app/dbs` | SQLite databases used by connectors |

The executor image uses a read-only root filesystem in the hardened Docker topology. File connector paths must therefore be absolute paths under a writable mount, such as `/app/data/imports` or `/app/dbs/mapping.db`.

Managed database deployments move application state out of `/app/state`, but may still require durable data or connector databases. See [Backups and upgrades](/deployment/backups-and-upgrades).

## First boot

Docker deployments can generate `envoy-server.yaml` from environment variables when the file does not yet exist and `ENVOY_ENCRYPTION_KEY` is set. Once written to persistent storage, the YAML remains authoritative; changing an environment variable does not necessarily rewrite an existing file.

After the server starts:

1. Open the Envoy URL.
2. Create the first administrator.
3. Complete TOTP enrollment if required.
4. Create and test connectors.
5. Confirm the executor is healthy.

Use [First-time setup](/getting-started/first-time-setup) for the operator walkthrough and [Server configuration](/deployment/server-configuration) for the YAML contract.